1 Preparing for Logical Standby Database Creation

Preparing for Logical Standby Database Creation



Table 4–1

Reference



Preparing the Primary Database for Logical Standby Database Creation

Task



Section 4.1.1 Determine Support for Datatypes and Storage Attributes for Tables

Section 4.1.2 Ensure Table Rows in the Primary Database Can Be Uniquely Identified



4.1.1 Determine Support for Datatypes and Storage Attributes for Tables

Before setting up a logical standby database, ensure the logical standby database

can maintain the datatypes and tables in your primary database.

The following list shows the various database objects that are supported and

unsupported in logical standby databases.

Supported Datatypes and Storage Attributes for Tables

CHAR

NCHAR

VARCHAR2 and VARCHAR

NVARCHAR2

NUMBER

DATE

TIMESTAMP

TIMESTAMP WITH TIME ZONE

TIMESTAMP WITH LOCAL TIME ZONE

INTERVAL YEAR TO MONTH

INTERVAL DAY TO SECOND

RAW

CLOB (including both fixed-width and variable-width character sets)

NCLOB

BLOB

LONG

LONG RAW

BINARY_FLOAT

BINARY_DOUBLE

Index-organized tables (without overflows and without LOB columns)

Unsupported Datatypes

BFILE

ROWID

UROWID

user-defined types



4-2



Oracle Data Guard Concepts and Administration



Preparing for Logical Standby Database Creation



object types REFs

varrays

nested tables

XMLType

Unsupported Tables, Sequences, and Views

s

Most schemas that ship with the Oracle database are skipped by SQL Apply

s



Tables with unsupported datatypes



s



Tables using table compression



To determine exactly which schemas will be skipped, query the DBA_LOGSTDBY_

SKIP view.

To determine if the primary database contains unsupported objects, query the DBA_

LOGSTDBY_UNSUPPORTED view. See Chapter 14, "Views Relevant to Oracle Data

Guard" for more information about the DBA_LOGSTDBY_UNSUPPORTED view.

It is important to identify unsupported database objects on the primary database

before you create a logical standby database. This is because changes made to

unsupported datatypes, table, sequences, or views on the primary database will not

be propagated to the logical standby database. Moreover, no error message will be

returned.

For example, use the following query on the primary database to list the schema

and table names of primary database tables that are not supported by logical

standby databases:

SQL> SELECT DISTINCT OWNER,TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED

2> ORDER BY OWNER,TABLE_NAME;

OWNER

----------HR

OE

OE

OE



TABLE_NAME

-------------------------COUNTRIES

ORDERS

CUSTOMERS

WAREHOUSES



To view the column names and datatypes for one of the tables listed in the previous

query, use a SELECT statement similar to the following:

SQL> SELECT COLUMN_NAME,DATA_TYPE FROM DBA_LOGSTDBY_UNSUPPORTED

2> WHERE OWNER='OE' AND TABLE_NAME = 'CUSTOMERS';

COLUMN_NAME



DATA_TYPE



Creating a Logical Standby Database



4-3



Preparing for Logical Standby Database Creation



------------------------------CUST_ADDRESS

PHONE_NUMBERS

CUST_GEO_LOCATION



------------------CUST_ADDRESS_TYP

PHONE_LIST_TYP

SDO_GEOMETRY



If the primary database contains unsupported tables, log apply services

automatically exclude these tables when applying redo data to the logical standby

database.

Note: If you determine that the critical tables in your primary



database will not be supported on a logical standby database, then

you might want to consider using a physical standby database.



4.1.1.1 Skipped SQL Statements on a Logical Standby Database

By default, all SQL statements except those in the following list are applied to a

logical standby database if they are executed on a primary database:

ALTER DATABASE

ALTER SESSION

ALTER MATERIALIZED VIEW

ALTER MATERIALIZED VIEW LOG

ALTER SYSTEM

CREATE CONTROL FILE

CREATE DATABASE

CREATE DATABASE LINK

CREATE PFILE FROM SPFILE

CREATE SCHEMA AUTHORIZATION

CREATE MATERIALIZED VIEW

CREATE MATERIALIZED VIEW LOG

CREATE SPFILE FROM PFILE

DROP DATABASE LINK

DROP MATERIALIZED VIEW

DROP MATERIALIZED VIEW LOG

EXPLAIN

LOCK TABLE

SET CONSTRAINTS

SET ROLE

SET TRANSACTION



4-4



Oracle Data Guard Concepts and Administration



Preparing for Logical Standby Database Creation



4.1.1.2 Supported Objects and Operations

Oracle PL/SQL supplied packages that do not modify system metadata or user data

leave no footprint in the archived redo log files, and hence are safe to use on the

primary database. Examples of such packages include DBMS_OUTPUT, DBMS_

RANDOM, DBMS_PIPE, DBMS_DESCRIBE, DBMS_OBFUSCATION_TOOLKIT, DBMS_

TRACE, DBMS_METADATA, and so on.

Oracle PL/SQL supplied packages that do not modify system metadata but may

modify user data are supported by SQL Apply, as long as the modified user data is

in the category of supported datatypes. Examples of such packages include DBMS_

LOB, DBMS_SQL, DBMS_TRANSACTION, and so on.

Oracle PL/SQL supplied packages that modify system metadata typically are not

supported by SQL Apply, and therefore their effects are not visible on the logical

standby database. Examples of such packages include DBMS_JAVA, DBMS_

REGISTRY, DBMS_ALERT, DBMS_SPACE_ADMIN, DBMS_REFRESH, DBMS_

SCHEDULER, DBMS_AQ, and so on.

Specific support for DBMS_JOB has been provided. Job execution is suspended on a

logical standby database and jobs cannot be scheduled directly on the standby

database. However, jobs submitted on the primary database are replicated in the

standby database. In the event of a switchover or failover, jobs scheduled on the

original primary database will automatically begin running on the new primary

database.

See PL/SQL Packages and Types Reference for more information about all of the Oracle

PL/SQL supplied packages.



4.1.2 Ensure Table Rows in the Primary Database Can Be Uniquely Identified

Because the ROWIDs on a logical standby database might not be the same as the

ROWIDs on the primary database, a different mechanism must be used to match

the updated row on the primary database to its corresponding row on the logical

standby database. You can use one of the following to match up the corresponding

rows:

s



Primary key



s



Unique index



Oracle recommends that you add a primary key or a unique index to tables on the

primary database, whenever appropriate and possible, to ensure SQL Apply can

efficiently apply data updates to the logical standby database.

Perform the following steps to ensure SQL Apply can uniquely identify table rows.



Creating a Logical Standby Database



4-5



Preparing for Logical Standby Database Creation



Step 1 Find tables without a unique identifier in the primary database.

Query the DBA_LOGSTDBY_NOT_UNIQUE view to identify tables in the primary

database that do not have a primary key or unique index with NOT NULL columns.

The following query displays a list of tables that SQL Apply might not be able to

uniquely identify:

SQL> SELECT OWNER, TABLE_NAME,BAD_COLUMN FROM DBA_LOGSTDBY_NOT_UNIQUE

2> WHERE TABLE_NAME NOT IN (SELECT TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED);



Some of the tables displayed in the DBA_LOGSTDBY_NOT_UNIQUE view can still be

supported because supplemental logging (that you will enable in Section 4.2.2.1)

adds information that uniquely identifies the row containing the redo data. The

presence or absence of a primary key or unique index can affect supplemental

logging as follows:

s



s



If the table has a primary key or a unique index with NOT NULL columns, the

amount of information added to the online redo log file during supplemental

logging is minimal.

If the table does not have a primary key or a unique index, supplemental

logging automatically logs all scalar values for each row to the online redo log

file.



The value of the BAD_COLUMN column will be either Y or N, as described in the

following list:

s



Y

Indicates a table column is defined using an unbounded datatype, such as

CLOB or BLOB. SQL Apply attempts to maintain these tables, but you must

ensure the application provides uniqueness in bounded columns only. Note that

if two rows in the table match except for rows in the LOB column, then the table

cannot be maintained properly and SQL Apply will stop.



s



N

Indicates the table contains enough column information to maintain the table in

a logical standby database.



Step 2 Add a disabled primary key rely constraint.

If your application ensures the rows in a table are unique, you can create a disabled

primary key RELY constraint on the table. This avoids the overhead of maintaining

a primary key on the primary database. See Oracle Database SQL Reference for ALTER

TABLE statement syntax and usage information.



4-6



Oracle Data Guard Concepts and Administration



Creating a Logical Standby Database



To create a disabled RELY constraint on a primary database table, use the ALTER

TABLE statement with a RELY DISABLE clause. The following example creates a

disabled RELY constraint on a table named mytab where rows can be uniquely

identified using the id and name columns:

SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;



The RELY constraint tells the system to assume the rows are unique. Be careful to

select columns for the disabled RELY constraint that will uniquely identify a row. If

the columns selected for the RELY constraint do not uniquely identify the row, SQL

Apply fails to apply data from the archived redo log file or standby redo log file to

the logical standby database.

To improve the performance of SQL Apply, add an index to the columns that

uniquely identify the row on the logical standby database. Failure to do this results

in full table scans.

See Oracle Database Reference for more information about the DBA_LOGSTDBY_NOT_

UNIQUE view, Oracle Database SQL Reference for more information about creating

RELY constraints, and Section 9.4 for information about RELY constraints and

actions you can take to increase performance on a logical standby database.



4.2 Creating a Logical Standby Database

This section describes the tasks you perform to create a logical standby database.

Table 4–2 provides a checklist of the tasks that you perform to create a logical

standby database and specifies on which database or databases you perform each

task. There is also a reference to the section that describes the task in more detail.

Table 4–2



Creating a Logical Standby Database



Reference



Task



Database



Section 4.2.1



Create a Physical Standby Database



Primary



Section 4.2.2



Prepare the Primary Database to Support a Logical Standby Database



Primary



Section 4.2.3



Prepare to Transition to a Logical Standby Database



Standby



Section 4.2.4



Start the Logical Standby Database



Standby



Section 4.2.5



Verify the Logical Standby Database Is Performing Properly



Standby



Creating a Logical Standby Database



4-7



Creating a Logical Standby Database



4.2.1 Create a Physical Standby Database

You create a logical standby database by first creating a physical standby database

and then transitioning it into a logical standby database, as follows:

Step 1 Create a physical standby database.

Follow the instructions in Chapter 3 to create a physical standby database.

Step 2 Ensure the physical standby database is caught up to the primary

database.

After you complete the steps in Section 3.2.6 to start the physical standby database

and Redo Apply, allow recovery to continue until the physical standby database is

consistent with the primary database, including all database structural changes

(such as adding or dropping datafiles).



4.2.2 Prepare the Primary Database to Support a Logical Standby Database

This section contains the following topics:

s



Ensure Supplemental Logging Is Enabled



s



Prepare the Primary Database for Role Transitions



4.2.2.1 Ensure Supplemental Logging Is Enabled

Supplemental logging must be enabled on the primary database to support a logical

standby database. Because an Oracle Database only logs the columns that were

modified, this is not always sufficient to uniquely identify the row that changed and

additional (supplemental) information must be put into the stream of redo data.

The supplemental information that is added to the redo data helps SQL Apply to

correctly identify and maintain tables in the logical standby database.

Step 1 Determine if supplemental logging is enabled.

To determine if supplemental logging is enabled on the primary database, query the

V$DATABASE fixed view. For example:

SQL> SELECT SUPPLEMENTAL_LOG_DATA_PK AS PK_LOG,

2> SUPPLEMENTAL_LOG_DATA_UI AS UI_LOG

3> FROM V$DATABASE;

PK_LOG

-----NO



4-8



UI_LOG

-----NO



Oracle Data Guard Concepts and Administration