Professional Documents
Culture Documents
1 INTRODUCTION .............................................................................................................................................................2
2 ASSUMPTIONS ................................................................................................................................................................3
Creating Logical Standby Database (using cold backup and hot backup)
1 INTRODUCTION
A Data Guard configuration can consists of one production database and up to nine standby databases.
Standby databases are the most effective disaster recovery solution for an Oracle database. A standby
database can also be used to remedy problems caused by user errors, data corruption, and other
operational difficulties.
A standby database can be either a physical standby database or a logical standby database:
• Physical standby database - Provides a physically identical copy of the primary database, with on-
disk database structures that are identical to the primary database on a block-for-block basis.
• Logical standby database - Contains the same logical information as the production database,
although the physical organization and structure of the data can be different. The redo logs received
from the primary database are transformed into SQL statements and then applied into the database.
This allows users to access a logical standby database for queries and reporting purposes at any time.
Thus, a logical standby database can be used concurrently for data protection and reporting.
This white paper lists down the steps which can be followed to create a logical standby database (by
taking either a cold backup or a hot backup). Following all of these steps in the order as written down
should result in a clean creation of Logical Standby Database.
Creating Logical Standby Database Page 3 of 16
2 ASSUMPTIONS
This white paper assumes that the Primary database is created and is already running. It also assumes
that the initialization parameters are specified in server parameter file (SPFILE).
Before creating the logical database, some tasks will have to be performed and the primary database will
have to be prepared for the Data Guard setup.
The steps for preparing the Primary Database for Logical Standby Database creation are given below:
1. Enable Forced Logging for the Primary Database mode using the following SQL
Steps:
Some of the database objects like LONG, user-defined types etc. are not supported in logical standby
databases. Use the following Query to check if any of these unsupported data types exists in the
primary database.
To get the list of schema and table names those are not supported by logical standby database-
SQL> SELECT DISTINCT OWNER, TABLENAME FROM DBA_LOGSTDBY_UNSUPPORTED
2> ORDER BY OWNER, TABLE_NAME;
To view the column name and data type for one of the tables listed in the previous query-
SQL> SELECT COLUMN_NAME, DATA_TYPE FROM DBA_LOGSTDBY_UNSUPPORTED
2> WHERE OWNER=<owner name> AND TABLE_NAME=<table name>;
If any of the critical tables in the primary database are unsupported then using a Physical Standby
Database might be a better option.
4. Ensure that the table rows in the Primary Database can be Uniquely Identified.
Creating Logical Standby Database Page 4 of 16
Oracle Corporation recommends that there should be a primary key or a unique index to tables on the
primary database, whenever appropriate and possible, to ensure that SQL apply operations can
efficiently apply data updates to the logical standby database.
Use the following query to display a list of tables that SQL apply operations might not be able to
uniquely identify:
Supplemental logging must be enabled on the primary database before creating the logical standby
database. Because Oracle 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
redo log. The supplemental information that is added to the redo logs helps log apply services to
correctly identify and maintain tables in the logical standby database.
SUP SUP
--- ---
NO NO
The NO values indicate that supplemental logging is not enabled on the primary database.
Switch to a new log file to ensure that the redo logs do not contain both supplemental log data and
nonsupplemental log data.
SUP SUP
--- ----
YES YES
6. Create an Alternate Tablespace
If a switchover operation between the primary database and a logical standby database is expected
in future, an alternate tablespace in the primary database should be created and the logical standby
system tables are moved to that separate tablespace.
2. Startup the Database and create a backup copy of the Control file.
On the primary database, enable restricted session mode to reduce the likelihood of users or
applications performing any DML or DDL operations.
To obtain a starting point for building the logical standby database, query the V$ARCHIVED_LOG
view, identify the latest archived redo log, and record its name for use later in the creation process.
The query below will give the latest archive redo log.
NAME
-----------------------------------------
/opt/oracle/ARC/MYORA/arc0004.001
Note: Remember to record the name of the archived redo log for use later in the creation process.
5. Create the parameter file from spfile in the Primary database. The pfile created will be used to create
the pfile of the standby database.
6. Copy Files from the Primary Database Location to the Standby Location
Creating Logical Standby Database Page 6 of 16
Use an operating system copy utility to copy the following binary files from the primary database site
to the standby site:
• Backup data files and redo logs created in Step 1 above
Note: While copying the control files make sure to rename it according to the parameter in init.ora file.
DB_NAME='MYORA'
INSTANCE_NAME='MYORA_C'
LOG_ARCHIVE_DEST_1='LOCATION=/OPT/ORACLE/ARC/MYORA MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_FORMAT='MYORA_%T_%S.ARC'
REMOTE_ARCHIVE_ENABLE=RECEIVE
LOG_ARCHIVE_START=TRUE
LOG_PARALLELISM=1
PARALLEL_MAX_SERVERS=9
STANDBY_FILE_MANAGEMENT='AUTO'
STANDBY_ARCHIVE_DEST='/OPT/ORACLE/ARC/MYORA/STDBY'
# The following parameter is required only if the primary and standby databases
# are located on the same system.
LOCK_NAME_SPACE=MYORA_C
8. Configure the Listener for Both the Primary and Standby Databases and Restart/reload the listener(s)
On the Logical standby database rename all the data files and the redo logs to update the control file.
Following is an example of renaming files.
SQL> ALTER DATABASE RENAME FILE '/opt/oracle/oradata/MYORA/system01.dbf'
2> TO '/opt/oracle/oradata/MYORA_C/system01.dbf';
To prevent users from updating objects in the logical standby database, turn on the database guard
by issuing the following SQL statements on the standby database:
SQL> ALTER DATABASE GUARD ALL;
SQL> ALTER DATABASE OPEN RESETLOGS;
Run the Oracle DBNEWID (nid) utility to change the database name of the logical standby database.
This will change the database name in the control file. Till now the dbname in the control file is
primary db name.
Modify the init.ora file and set parameter DB_NAME=MYORA_C and if password file is used the
delete and recreate the password file.
15. Create a New Temporary File for the Logical Standby Database
The temporary files are not included as a part of the closed backup operation so the temporary file
will have to be recreated manually.
16. Register the Archived Redo Log and Start SQL Apply Operations
To register the most recently archived redo log and begin applying data from the redo logs to the
standby database, perform the following steps
Creating Logical Standby Database Page 8 of 16
a. Register the most recently archived redo log with log apply services.
Register the archived redo log that was identified in step 4 of Section 3.2 The following example
specifies the file name and location of the most recently archived redo log:
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE
2> '/opt/oracle/ARC/MYORA_C/arc0004.001';
Specify the following SQL statement to begin applying redo logs to the logical standby database.
Note: The INITIAL keyword has to be used only for the first time. To apply redo logs there after, the
following statements should be used.
This step has to be performed in the Primary Database to enable archiving to the Logical Standby
database. Use the following statements to start archiving.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=payroll3 lgwr NO AFFIRM'
2 > SCOPE=BOTH;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE SCOPE=BOTH;
The configuration of Logical database is complete. The logs created in the primary database should be
shifted automatically to the standby location and get applied.
See Section 5 for steps to verify whether the logs are getting shifted and applied.
After completing the Steps 1 thru 5 of Section 3.1 for preparing the Primary database follow the steps
listed below for completing the setup of Primary database.
If a switchover operation between the primary database and a logical standby database is expected
in future , an alternate tablespace in the primary database should be created and the logical standby
system tables are moved to that separate tablespace.
This section lists down the tasks that need to be performed to create the Logical Standby database.
Before building the LogMiner Dictionary the database has to be bought to the Quiesced state.
Execute the command below to bring the Database to a Quiesced state-
SQL> ALTER SYSTEM QUIESCE RESTRICTED;
5. Identify the archived redo log that contains the LogMiner dictionary and the starting SCN.
Creating Logical Standby Database Page 10 of 16
First switch log file to create the archived log and then query from V$ARCHIVED_LOG
NAME
-----------------------------------------------------------
/opt/oracle/ARC/MYORA/MYORA_0001_0000000005.arc
MAX(FIRST_CHANGE#)
------------------
2856516
Note: Remember to record the name of the archived redo log for use later in the creation process.
7. Create the parameter file from spfile in the Primary database. The pfile created will be used to create
the pfile of the standby database.
8. Copy Files from the Primary Database Location to the Standby Location
Use an operating system copy utility to copy the following binary files from the primary database site
to the standby site:
Note: While copying the control files make sure to rename it according to the parameter in init.ora file.
DB_NAME='MYORA'
INSTANCE_NAME='MYORA_H'
LOG_ARCHIVE_DEST_1='LOCATION=/OPT/ORACLE/ARC/MYORA MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_FORMAT='MYORA_%T_%S.ARC'
REMOTE_ARCHIVE_ENABLE=RECEIVE
LOG_ARCHIVE_START=TRUE
LOG_PARALLELISM=1
PARALLEL_MAX_SERVERS=9
STANDBY_FILE_MANAGEMENT='AUTO'
STANDBY_ARCHIVE_DEST='/OPT/ORACLE/ARC/MYORA/STDBY'
# The following parameter is required only if the primary and standby databases
# are located on the same system.
LOCK_NAME_SPACE=MYORA_H
10. Configure the Listener for Both the Primary and Standby Databases and Restart/reload the listener(s)
Because the online logs were not copied from the primary system the redo logs will have to be
cleared. To clear redo logs use the following statement for all the groups
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;
11. Recover the Logical Standby Database until SCN recorded at step 5 above.
If error ‘ORA-279: change %s generated at %s needed for thread %s’ comes the recovery will have to
be canceled and recover it manually using the following command.
Notice that the log file taken here is one less than the one noted in Step 5 of Section 4.2
Run the Oracle DBNEWID (nid) utility to change the database name of the logical standby database.
This will change the database name in the control file. Till now the dbname in the control file is
primary db name.
Modify the init.ora file and set parameter DB_NAME=MYORA_H and if password file is used the
delete and recreate the password file.
17. Create a New Temporary File for the Logical Standby Database
The temporary files, are not included as a part of the closed backup operation so the temporary file
will have to be recreated manually.
18. Register the Archived Redo Log and Start SQL Apply Operations
To register the most recently archived redo log and begin applying data from the redo logs to the
standby database, perform the following steps:
Creating Logical Standby Database Page 13 of 16
a. Register the most recently archived redo log with log apply services.
Register the archived redo log that was identified in step 5 of Section 4.2 The following
example specifies the filename and location of the most recently archived redo log:
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE
2> '/opt/oracle/ARC/MYORA_H/MYORA_0001_0000000005.arc’;
Specify the following SQL statement to begin applying redo logs to the logical standby
database using the SCN number identified in Step 5 Section 4.2.
Note: The INITIAL keyword has to be used only for the first time. To apply redo logs there after, the
following statements should be used.
This step has to be performed in the Primary Database to enable archiving to the Logical Standby
database. Use the following statements to start archiving.
This completes the configuration of Logical Standby Database from Hot Backup. The logs created in the
primary database should be shifted automatically to the standby location and get applied.
See Section 5 for steps to verify whether the logs are getting shifted and applied
Creating Logical Standby Database Page 14 of 16
Following are the procedures which can be used to verify the standby database:
For example
SQL> ALTER SESSION SET NLS_DATE_FORMAT=’DD-MM-YY HH24:MI:SS’;
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
2> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
--------- ---
8 YES
9 YES
10 YES
11 YES
APPLIED_SCN NEWEST_SCN
----------- ----------
2858715 2858715
When the numbers in the APPLIED_SCN and NEWEST_SCN columns are equal, it means that all of the
available data in the redo log was applied.
6 Troubleshooting
6.1 Error ORA-01152 and ORA-01110 when starting the Logical Standby Database
If the above errors are encountered when starting the Logical Standby Database during the Step9 of
Section 3.2 then it might be that the backup of control file in step of Section 3.2 is taken after opening the
primary database or not immediately after taking the cold backup.
6.2 When Logs are not getting shifted to the Logical Standby Location
Some of the causes for logs not getting shifted to the logical standby location might be –
• Listener not running. Check the listener and start the listener.
• Tnsnames not set properly.
• If the databases are on two different locations then the network connection might be lost
• Check the alert log for more information.
• Check the alert log for any ORA errors – take appropriate action after looking at the messages in the
alert log. Some of the action points that can be taken are noted below.
• If the alert log message is – LGWR is actively archiving destination LOG_ARCHIVE_DEST_2 then
wait for some time. The logs are getting applied and it is just taking some time.
• Stop the applying of archived logs and restart-
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
Check whether logs are getting applied or not
• Find out the last archived log which has been applied and register the next archived log using ‘ALTER
DATABASE REGISTER LOGICAL LOGFILE’ statement on the logical standby database and start log
apply services again.
• Do ‘ALTER DATABASE SWITCH LOGFILE’ in the primary database and Check whether the logs are
getting applied or not.
• LOG_ARCHIVE_DEST_2=’SERVICE=..’ parameter not set properly and not applied at the correct
moment. Enable Archiving in Logical standby database must be done after completing the
configuration of the Logical Standby Database. If this is the causes of the error the whole procedure
will have to be done from the beginning by making sure that the parameters LOG_ARCHIVE_DEST_2
and LOG_ARCHIVE_DEST_STATE_2 are unconfigured before starting the logical standby database
creation.
• Check for any archive gaps-
Use the following query to find if there are any archive gaps –
SQL> COLUMN FILE_NAME FORMAT a55
Creating Logical Standby Database Page 16 of 16
6.4 If logs are not getting applied after shutting down and restarting the Logical Standby
Database
When a standby database is restarted the log apply services don’t start automatically. It has to be started
manually. If even after starting the log apply services manually the logs are not getting applied then find
out the last archived log which has been applied and register the next archived log using ‘ALTER
DATABASE REGISTER LOGICAL LOGFILE’ statement on the logical standby database and start log
apply services again.
7 Conclusion
The success in creating a Logical Standby Database depends a lot on how the tasks are executed.
Whether the initialization parameters are set properly. Before starting the creation of Logical standby
Database make sure that all the Initialization Parameters are set correctly. Are all the steps followed in
the correct order and whether the appropriate parameters are used?
If everything is done properly then you should be able to do a clean configuration of the Logical Standby
Database in the first go.
Good Luck.