DBA Tips Archive For Oracle
DBA Tips Archive For Oracle
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
Contents
Introduction Introduction to Oracle Data Guard Hardware and O/S Configuration Configure the Primary Database Configure Oracle Net Components Configure the Standby Database Start Remote Archiving Verifying the Physical Standby Database Deletion Policy for Archived Redo Log Files In Flash Recovery Area Post-Creation Steps Activating a Physical Standby Database (Role Transition) Further Reading About the Author
Introduction
Oracle Data Guard (known as Oracle Standby Database prior to Oracle9i), forms an extension to the Oracle RDBMS and provides organizations with high availability, data protection, and disaster recovery for enterprise databases. Oracle Data Guard provides the DBA with services for creating, maintaining, managing, and monitoring one or more standby databases. The functionality included with Oracle Data Guard enables enterprise data systems to survive both data corruption as well as major disasters. This article provides instructions for creating and configuring a physical standby database from a primary database using Oracle Database 10g Release 2 (10.2) operating in maximum performance protection mode. It should be noted that several different methods exist to create a physical standby database configuration and that this is just
1 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
one of those ways. The methods outlined in this guide present a simple approach that should be easy to implement in most situations. In fact, if you break down the essential tasks required to build a physical standby database, you will see that it is essentially nothing more than taking a backup of the primary database, creating a standby controlfile, transferring the files to the standby host, mounting the standby database, putting the standby database in managed recovery mode (Redo Apply), and starting remote archiving from the primary database (Redo Transport). Obviously there are a number of smaller steps I am leaving out which will all be discussed in more depth throughout this guide. All configuration parameters related to the Oracle instance and networking will be discussed as well as how to place the standby database in Managed Recovery Mode.
Oracle Database Enterprise Edition Requirement Oracle Data Guard is only available as a bundled feature included within its Enterprise Edition release of the Oracle Database software. It is not available with Oracle Database Standard Edition. With the exception of performing a rolling database upgrade using logical standby database, it is mandatory that the same release of Oracle Database Enterprise Edition be installed on the primary database and all standby databases! While it remains possible to simulate a standby database environment running Oracle Database Standard Edition, it requires the DBA to develop custom scripts that manually transfer archived redo log files and then manually applying them to the standby database. This is similar to the methods used to maintain a standby database with
2 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
Oracle 7. The consequence with this type of configuration is that it does not provide the ease-of-use, manageability, performance, and disaster-recovery capabilities available with Data Guard.
Standby Database Types There are two types of standby databases that can be created with Oracle Data Guard physical or logical. Deciding which of the two types of standby databases to create is critical and depends on the nature of the business needs the organization is trying to satisfy. A physical standby database is an identical, block-for-block copy of the primary database and is kept in sync with the primary using media recovery. As redo gets generated on the primary database, it gets transferred to the standby database where an RFS process receives the primary redo and applies the change vectors directly to the standby database. A physical standby database is an excellent choice for disaster recovery. A logical standby database works in a different manner which keeps in sync with the primary by transforming redo data received from the primary database into logical SQL statements and then executes those SQL statements against the standby database. With a logical standby database, the standby remains open for user access in read/write mode while still receiving and applying logical records from the primary. While a physical standby database is an exact physical replica of the primary, a logical standby database is not. Because Oracle is applying SQL statements to the standby database and not performing media recovery (as is done with a physical standby database), it is possible for the logical standby database to contain the same logical data, but at the same time have a different physical structure. A logical standby database is an excellent solution for a reporting database while at the same time retaining the attributes of a disaster recovery solution. Not only does a logical standby database contain the same logical information as the primary, it can also support the creation of additional objects to support improved reporting requirements.
Data Protection Modes After deciding between a physical or logical standby database, the next major decision is which data protection mode should be used to operate the Data Guard configuration. At the heart of this decision lies the answer to one important question how much data loss is your organization willing to endure in the event of a failover? The obvious answer to expect from management is none. Configuring Data Guard with guaranteed no data loss, however, requires a significant investment in equipment and other resources necessary to provide support for this type of environment. An Oracle Database 10g Data Guard configuration will always run in one of three data protection modes: Maximum Protection Maximum Availability Maximum Performance Each of the three modes provide a high degree of data protection; however they differ with regards to data availability and performance of the primary database. When selecting a protection mode, always consider the one that best meets the needs of your business. Carefully take into account the need to protect the data against any loss vs. availability and performance expectations of the primary database. An in-depth discussion on the three available data protection modes and how redo transport works to support them is beyond the scope of this guide. To keep the article simple, I will be using the default protection mode of Maximum Performance.
3 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
For a detailed discussion on the various Oracle Data Guard protection modes, see my article entitled 'Data Protection Modes'.
4 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
It is assumed that Oracle Database 10g Release 2 and all patchsets have been installed on both nodes in the Oracle Data Guard configuration. Click here for a guide on installing Oracle Database 10g R2 on the Red Hat Linux 5 platform.
5 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
SQL> archive log list Database log mode Automatic archival Archive destination Oldest online log sequence Current log sequence
The output from the above command shows that the primary database is not in archivelog mode. Perform the following steps to place the primary database into archivelog mode:
SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 1241513984 bytes Fixed Size 1273420 bytes Variable Size 318767540 bytes Database Buffers 905969664 bytes Redo Buffers 15503360 bytes Database mounted. SQL> alter database archivelog; Database altered. SQL> alter database open; Database altered. SQL> archive log list Database log mode Automatic archival Archive destination Oldest online log sequence Next log sequence to archive Current log sequence
6 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
Prior to Oracle Database 10g, it was also required to set the log_archive_start initialization parameter to TRUE in order to enable automatic archiving. This is no longer necessary as automatic archiving is enabled by default when the database is placed into archivelog mode with Oracle Database 10g or higher. 2. Create a Password File As part of the new redo transport security and authentication features, it is now mandatory that each database in an Oracle Data Guard configuration utilize a password file. In addition, the SYS password must be identical on every database in order for redo transport to function. If a password file does not exist for the primary database, create one using the following steps:
After creating the password file, set the remote_login_passwordfile initialization parameter to EXCLUSIVE in the spfile on the primary database. Since this parameter cannot be dynamically modified for the current running instance, the change will have to be made to the spfile and bounced in order to take effect:
SQL> alter system set remote_login_passwordfile=exclusive scope=spfile; System altered. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup open ORACLE instance started. Total System Global Area 1241513984 bytes Fixed Size 1273420 bytes Variable Size 318767540 bytes Database Buffers 905969664 bytes Redo Buffers 15503360 bytes Database mounted. Database opened.
3. Enable Force Logging (optional) Any nologging operations performed on the primary database do not get fully logged within the redo stream. As Oracle Data Guard relies on the redo stream to maintain the standby database, this can result in data inconsistencies between the primary and standby along with a massive headache for the DBA to resolve. To prevent this from occurring, one solution is to place the primary database into force logging mode. In this mode, all nologging operations are permitted to run without
7 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
error, however, the changes will be placed in the redo stream anyway. Although this is considered an optional step, I make it mandatory when designing an Oracle Data Guard configuration for my clients. Overlooking this on a production environment can result in the DBA spending considerable time during the implementation of a disaster recovery situation. To place the primary database in forced logging mode, connect as SYS and run the following:
4. Create Standby Redo Logs (optional) Certain data protection modes within Oracle Data Guard, such as maximum availability and maximum protection, mandate the use of standby redo logs. Regardless of the protection mode (even when using maximum performance), it is highly recommended to utilize standby redo logs as generally more data can be recovered during a failover than without them. When creating the standby redo logs, it is recommended to have one more standby redo log file group than the number of online redo log file groups on the primary database. In addition, the standby redo log file groups must be the same size as the online redo log file groups. The recommended number of standby redo log log file groups can be calculated using the following formula: (# of online redo log file groups on primary + 1) * maximum # of threads The example database used in this guide is not configured for Oracle RAC and therefore only contains one thread. The primary database is configured with three online redo log file groups sized at 50MB each:
SQL> select group#, thread#, bytes, members from v$log; GROUP# THREAD# BYTES MEMBERS ---------- ---------- ---------- ---------1 1 52428800 2
8 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
2 3
1 1
52428800 52428800
2 2
The number of standby redo logs required for the physical standby database in this example is (3 + 1) * 1 = 4 at 50MB each. A best practice generally followed is to create the standby redo logs on both the primary and the standby database so as to make role transitions smoother. By creating the standby redo logs at this stage, it is assured that they will exist on both the primary and the newly created standby database. From the primary database, connect as SYS and run the following to create four standby redo log file groups:
SQL> alter database add standby logfile thread 1 group 4 size 50m; Database altered. SQL> alter database add standby logfile thread 1 group 5 size 50m; Database altered. SQL> alter database add standby logfile thread 1 group 6 size 50m; Database altered. SQL> alter database add standby logfile thread 1 group 7 size 50m; Database altered.
SQL> select group#, type, member from v$logfile order by group#, member; GROUP# ---------1 1 2 2 3 3 4 4 TYPE ------ONLINE ONLINE ONLINE ONLINE ONLINE ONLINE STANDBY STANDBY MEMBER ----------------------------------------------------------------/u02/oradata/MODESTO/onlinelog/o1_mf_1_6jjc8hr8_.log /u03/flash_recovery_area/MODESTO/onlinelog/o1_mf_1_6jjc8jxq_.log /u02/oradata/MODESTO/onlinelog/o1_mf_2_6jjc8mvj_.log /u03/flash_recovery_area/MODESTO/onlinelog/o1_mf_2_6jjc8nvv_.log /u02/oradata/MODESTO/onlinelog/o1_mf_3_6jjc8qrw_.log /u03/flash_recovery_area/MODESTO/onlinelog/o1_mf_3_6jjc8ry2_.log /u02/oradata/MODESTO/onlinelog/o1_mf_4_6hvg3qk9_.log /u03/flash_recovery_area/MODESTO/onlinelog/o1_mf_4_6hvg3rnm_.log
9 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
5 5 6 6 7 7
5. Configure the Primary Database Initialization Parameters Most of the configuration options for Data Guard are implemented using initialization parameters for the Oracle instance. When the primary and standby machines are identical (memory, disks, CPU, etc.) the initialization file for both databases should be nearly identical. When configuring the initialization parameters on the primary database, it is important to consider future role transitions. The initialization parameters that control redo transport and redo apply should be configured so that the database will seamlessly operate in either role with no parameter modifications required. When the database is mounted on a primary controlfile, the standby parameters are not read and are not put into effect, so they will not affect the operation of the database while in the primary role. The parameters listed below should be placed in the initialization file for the primary database. Notice that I will initially 'DEFER' log_archive_dest_state_2 until the standby database has been created, mounted, and placed in managed recovery mode. Also note that the db_file_name_convert and log_file_name_convert parameters are only required if the paths will be different between the primary and standby host.
# ---[ Dump Destination Parameters ] --- # audit_file_dest='/u01/app/oracle/admin/modesto/adump' background_dump_dest='/u01/app/oracle/admin/modesto/bdump' core_dump_dest='/u01/app/oracle/admin/modesto/cdump' user_dump_dest='/u01/app/oracle/admin/modesto/udump' # ---[ Role-independent Parameters ] --- # archive_lag_target=900 compatible='10.2.0.5.0' control_files='/u02/oradata/MODESTO/controlfile/o1_mf_6hc6stn9_.ctl', '/u03/flash_recovery_area/MODESTO/controlfile/o1_mf_6hc6styy_.ctl' db_name='modesto' db_domain='idevelopment.info' db_create_file_dest='/u02/oradata' db_recovery_file_dest='/u03/flash_recovery_area' dispatchers='(PROTOCOL=TCP) (SERVICE=modestoXDB)' instance_name='modesto' log_archive_config='dg_config=(modesto,turlock)' log_archive_max_processes=4 remote_login_passwordfile='exclusive'
10 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
# ---[ Primary Role Parameters ] --- # db_unique_name='modesto' log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) db_unique_name=modesto' log_archive_dest_2='service=turlock.idevelopment.info valid_for=(online_logfiles,primary_role) db_unique_name=turlock' log_archive_dest_state_1='enable' log_archive_dest_state_2='defer' service_names='modesto.idevelopment.info, modesto' # ---[ Standby Role Parameters ] --- # db_file_name_convert='/TURLOCK/','/MODESTO/' log_file_name_convert='/TURLOCK/','/MODESTO/' fal_server='modesto','turlock' fal_client='modesto' standby_file_management='auto'
Several of the initialization parameters listed above can not be dynamically modified and therefore will require the primary database to be bounced:
SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 1241513984 bytes Fixed Size 1273420 bytes Variable Size 318767540 bytes Database Buffers 905969664 bytes Redo Buffers 15503360 bytes Database mounted. Database opened.
6. Create a Backup of the Primary Database A physical standby database can be created using either a hot or cold backup of the primary as long as all of the necessary archivelogs are available to bring the standby database to a consistent state. For the purpose of this guide, I will be performing an online (hot) backup of the primary database using RMAN. The RMAN backupsets will be written to a staging directory located outside of the Flash Recovery Area; namely /u04/oracle/dg_staging. I start by creating the staging directory on both the primary and standby hosts:
11 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
From the primary host, perform an RMAN backup of the primary database that places the backupset into the staging directory:
[oracle@vmlinux1 ~]$ rman target sys/MySysPassword@modesto RMAN> backup device type disk format '/u04/oracle/dg_staging/%U' database plus archivelog;
7. Create a Standby Controlfile Using the same process as above, create a standby controlfile in the staging directory using RMAN:
[oracle@vmlinux1 ~]$ rman target sys/MySysPassword@modesto RMAN> backup device type disk format '/u04/oracle/dg_staging/%U' current controlfile for standby;
8. Prepare an Initialization Parameter for the Standby Database Create an initialization parameter for the standby database using the primary as the source. The primary database in this example is using an spfile which will need to be copied to a pfile so it can be modified and used by the standby database. When configuring the standby database later in this guide, I will be converting the modified standby pfile back to an spfile. From the primary database, create a pfile in the staging directory:
Next, modify the necessary parameters in the new pfile to allow the database to operate in the standby role. All modified parameters are indicated in red:
12 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
turlock.__large_pool_size=16777216 turlock.__shared_pool_size=285212672 turlock.__streams_pool_size=0 # ---[ Dump Destination Parameters ] --- # audit_file_dest='/u01/app/oracle/admin/turlock/adump' background_dump_dest='/u01/app/oracle/admin/turlock/bdump' core_dump_dest='/u01/app/oracle/admin/turlock/cdump' user_dump_dest='/u01/app/oracle/admin/turlock/udump' # ---[ Role-independent Parameters ] --- # archive_lag_target=900 compatible='10.2.0.5.0' control_files='/u02/oradata/TURLOCK/controlfile/o1_mf_6hc6stn9_.ctl', '/u03/flash_recovery_area/TURLOCK/controlfile/o1_mf_6hc6styy_.ctl' db_name='modesto' db_domain='idevelopment.info' db_create_file_dest='/u02/oradata' db_recovery_file_dest='/u03/flash_recovery_area' dispatchers='(PROTOCOL=TCP) (SERVICE=turlockXDB)' instance_name='turlock' log_archive_config='dg_config=(modesto,turlock)' log_archive_max_processes=4 remote_login_passwordfile='exclusive' # ---[ Primary Role Parameters ] --- # db_unique_name='turlock' log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) db_unique_name=turlock' log_archive_dest_2='service=modesto.idevelopment.info valid_for=(online_logfiles,primary_role) db_unique_name=modesto' log_archive_dest_state_1='enable' log_archive_dest_state_2='enable' service_names='turlock.idevelopment.info, turlock' # ---[ Standby Role Parameters ] --- # db_file_name_convert='/MODESTO/','/TURLOCK/' log_file_name_convert='/MODESTO/','/TURLOCK/' fal_server='modesto','turlock' fal_client='turlock' standby_file_management='auto'
9. Transfer Files to the Standby Host Using an OS remote copy utility, transfer the backup of the primary database, standby controlfile, and standby initialization parameter file to the standby host (vmlinux2):
13 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
[oracle@vmlinux1 ~]$ scp /u04/oracle/dg_staging/* vmlinux2:/u04/oracle/dg_staging/ 0blv2spa_1_1 100% 124KB 124.0KB/s 00:00 0clv2spd_1_1 100% 664MB 9.1MB/s 01:13 0dlv2sqg_1_1 100% 7936KB 7.8MB/s 00:01 0elv2sqj_1_1 100% 3072 3.0KB/s 00:00 0flv2ss4_1_1 100% 7904KB 7.7MB/s 00:01 initturlock.ora 100% 1705 1.7KB/s 00:00
Oracle Net Listener Although not mandatory, create a named static listener entry in the listener.ora file for each database in the Data Guard configuration:
Primary Host
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1) (PROGRAM = extproc) ) (SID_DESC = (GLOBAL_DBNAME = MODESTO.IDEVELOPMENT.INFO) (SID_NAME = modesto)
14 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1) ) ) INBOUND_CONNECT_TIMEOUT_LISTENER = 0 LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = vmlinux1.idevelopment.info)(PORT = 1521)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) )
Standby Host
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1) (PROGRAM = extproc) ) (SID_DESC = (GLOBAL_DBNAME = TURLOCK.IDEVELOPMENT.INFO) (SID_NAME = turlock) (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1) ) ) INBOUND_CONNECT_TIMEOUT_LISTENER = 0 LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = vmlinux2.idevelopment.info)(PORT = 1521)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) )
15 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
After making changes to the listener.ora, restart the Oracle Net listener service on the primary and standby host:
[oracle@vmlinux1 ~]$ lsnrctl services | grep '^Service' Services Summary... Service "MODESTO.IDEVELOPMENT.INFO" has 2 instance(s). Service "PLSExtProc" has 1 instance(s). Service "modestoXDB.idevelopment.info" has 1 instance(s). Service "modesto_XPT.idevelopment.info" has 1 instance(s). [oracle@vmlinux2 ~]$ lsnrctl services | grep '^Service' Services Summary... Service "PLSExtProc" has 1 instance(s). Service "TURLOCK.IDEVELOPMENT.INFO" has 1 instance(s).
Oracle Net Aliases The primary and standby host should contain an Oracle Net alias in the tnsnames.ora file for all primary and standby net service names:
MODESTO.IDEVELOPMENT.INFO = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = vmlinux1.idevelopment.info)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = modesto.idevelopment.info) ) ) TURLOCK.IDEVELOPMENT.INFO =
16 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = vmlinux2.idevelopment.info)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = turlock.idevelopment.info) ) )
Note that each of the Oracle Net alias entries above contain the domain IDEVELOPMENT.INFO. In my Oracle network configuration, I defined the default domain in the sqlnet.ora file on every host which provides name resolution for Oracle Net clients. When this parameter is set, the default domain name is automatically appended to any unqualified net service name or alias:
NAMES.DEFAULT_DOMAIN = IDEVELOPMENT.INFO
2. Create an spfile for the Standby Instance Using the prepared standby initialization parameter file created and copied from the primary host, convert the pfile to an spfile by entering the following command on the standby instance:
[oracle@vmlinux2 ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.5.0 - Production on Tue Dec 7 22:14:02 2010
17 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
SQL> create spfile from pfile='/u04/oracle/dg_staging/initturlock.ora'; File created. SQL> !ls -l $ORACLE_HOME/dbs total 12 -rw-r----- 1 oracle oinstall 1536 Dec -rw-r----- 1 oracle oinstall 4608 Dec
The above command assumes that the standby initialization parameter file copied from the primary host is located in the staging directory /u04/oracle /dg_staging. 3. Create and Start the Standby Instance Start by creating the "dump directories" on the standby host as referenced in the standby initialization parameter file:
-p -p -p -p -p -p -p
Next, create and verify all directories on the standby host that will be used for database files and the Flash Recovery Area:
[oracle@vmlinux2 ~]$ mkdir -p /u02/oradata/TURLOCK/controlfile [oracle@vmlinux2 ~]$ mkdir -p /u02/oradata/TURLOCK/datafile [oracle@vmlinux2 ~]$ mkdir -p /u02/oradata/TURLOCK/onlinelog [oracle@vmlinux2 [oracle@vmlinux2 [oracle@vmlinux2 [oracle@vmlinux2 [oracle@vmlinux2 ~]$ ~]$ ~]$ ~]$ ~]$ mkdir mkdir mkdir mkdir mkdir -p -p -p -p -p /u03/flash_recovery_area/TURLOCK/archivelog /u03/flash_recovery_area/TURLOCK/autobackup /u03/flash_recovery_area/TURLOCK/backupset /u03/flash_recovery_area/TURLOCK/controlfile /u03/flash_recovery_area/TURLOCK/onlinelog
18 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
After verifying the appropriate environment variables are set on the standby host ($ORACLE_SID, $ORACLE_HOME, $PATH, $LD_LIBRARY_PATH), start the physical standby instance:
[oracle@vmlinux2 ~]$ echo $ORACLE_SID turlock [oracle@vmlinux2 ~]$ sqlplus / as sysdba SQL*Plus: Release 10.2.0.5.0 - Production on Tue Dec 7 22:35:34 2010 Copyright (c) 1982, 2010, Oracle. Connected to an idle instance. SQL> startup nomount ORACLE instance started. Total System Global Area 1241513984 bytes Fixed Size 1273420 bytes Variable Size 318767540 bytes Database Buffers 905969664 bytes Redo Buffers 15503360 bytes All Rights Reserved.
4. Create the Physical Standby Database From the standby host where the standby instance was just started, duplicate the primary database as a standby using RMAN:
[oracle@vmlinux2 ~]$ rman target sys/MySysPassword@modesto auxiliary sys/MySysPassword@turlock Recovery Manager: Release 10.2.0.5.0 - Production on Tue Dec 7 22:51:22 2010 Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: MODESTO (DBID=2026707242) connected to auxiliary database: MODESTO (not mounted) RMAN> duplicate target database for standby; Starting Duplicate Db at 08-DEC-2010 22:24:52 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1
19 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
channel ORA_AUX_DISK_1: sid=156 devtype=DISK contents of Memory Script: { restore clone standby controlfile; sql clone 'alter database mount standby database'; } executing Memory Script Starting restore at 08-DEC-2010 22:24:53 using channel ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: starting datafile backupset restore channel ORA_AUX_DISK_1: restoring control file channel ORA_AUX_DISK_1: reading from backup piece /u04/oracle/dg_staging/0flv2ss4_1_1 channel ORA_AUX_DISK_1: restored backup piece 1 piece handle=/u04/oracle/dg_staging/0flv2ss4_1_1 tag=TAG20101208T220036 channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01 output filename=/u02/oradata/TURLOCK/controlfile/o1_mf_6j0m05vj_.ctl output filename=/u03/flash_recovery_area/TURLOCK/controlfile/o1_mf_6j0m068b_.ctl Finished restore at 08-DEC-2010 22:24:54 sql statement: alter database mount standby database contents of Memory Script: { set newname for tempfile 1 to "/u02/oradata/TURLOCK/datafile/o1_mf_temp_6hc6v3jd_.tmp"; switch clone tempfile all; set newname for datafile 1 to "/u02/oradata/TURLOCK/datafile/o1_mf_system_6hc6t6l0_.dbf"; set newname for datafile 2 to "/u02/oradata/TURLOCK/datafile/o1_mf_undotbs1_6hc6trl0_.dbf"; set newname for datafile 3 to "/u02/oradata/TURLOCK/datafile/o1_mf_sysaux_6hc6tyvd_.dbf"; set newname for datafile 4 to "/u02/oradata/TURLOCK/datafile/o1_mf_example_6hc6vf79_.dbf"; set newname for datafile 5 to "/u02/oradata/TURLOCK/datafile/o1_mf_users_6hc6vlf0_.dbf"; restore check readonly clone database ; }
20 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
executing Memory Script executing command: SET NEWNAME renamed temporary file 1 to /u02/oradata/TURLOCK/datafile/o1_mf_temp_6hc6v3jd_.tmp in control file executing command: SET NEWNAME executing command: SET NEWNAME executing command: SET NEWNAME executing command: SET NEWNAME executing command: SET NEWNAME Starting restore at 08-DEC-2010 22:25:01 using channel ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: starting datafile backupset restore channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to /u02/oradata/TURLOCK/datafile/o1_mf_system_6hc6t6l0_.dbf restoring datafile 00002 to /u02/oradata/TURLOCK/datafile/o1_mf_undotbs1_6hc6trl0_.dbf restoring datafile 00003 to /u02/oradata/TURLOCK/datafile/o1_mf_sysaux_6hc6tyvd_.dbf restoring datafile 00004 to /u02/oradata/TURLOCK/datafile/o1_mf_example_6hc6vf79_.dbf restoring datafile 00005 to /u02/oradata/TURLOCK/datafile/o1_mf_users_6hc6vlf0_.dbf channel ORA_AUX_DISK_1: reading from backup piece /u04/oracle/dg_staging/0clv2spd_1_1 channel ORA_AUX_DISK_1: restored backup piece 1 piece handle=/u04/oracle/dg_staging/0clv2spd_1_1 tag=TAG20101208T215908 channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:45 Finished restore at 08-DEC-2010 22:25:47 contents of Memory Script: { switch clone datafile all; } executing Memory Script datafile 1 switched input datafile copy datafile 2 switched input datafile copy datafile 3 switched input datafile copy to datafile copy recid=6 stamp=737245547 filename=/u02/oradata/TURLOCK/datafile/o1_mf_system_6j0m0gkf_.dbf to datafile copy recid=7 stamp=737245547 filename=/u02/oradata/TURLOCK/datafile/o1_mf_undotbs1_6j0m0gmf_.dbf to datafile copy recid=8 stamp=737245547 filename=/u02/oradata/TURLOCK/datafile/o1_mf_sysaux_6j0m0glf_.dbf
21 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
datafile 4 switched to datafile copy input datafile copy recid=9 stamp=737245547 filename=/u02/oradata/TURLOCK/datafile/o1_mf_example_6j0m0gnn_.dbf datafile 5 switched to datafile copy input datafile copy recid=10 stamp=737245547 filename=/u02/oradata/TURLOCK/datafile/o1_mf_users_6j0m0gol_.dbf Finished Duplicate Db at 08-DEC-2010 22:25:48 RMAN> exit
The RMAN duplicate process above will read the backupset that was transferred to the staging directory, clone the standby controlfile, mount the database on the new standby controlfile, and restore the physical database files. 5. Start Redo Apply on the Standby Database Now that the standby is in place, start Redo Apply on the standby database by putting it in managed recovery mode. This instructs the standby database to begin applying changes from archived redo logs transferred from the primary database:
SQL> alter database recover managed standby database disconnect; Database altered.
To use Real Time Apply, run the following alternate version of the alter database command to place the standby database in managed recovery mode:
SQL> alter database recover managed standby database using current logfile disconnect; Database altered.
22 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
mode. This is the destination defined that will transfer redo data to the standby database. From the primary database, enable SQL Transport Services by issuing the following statement:
With the protection mode used in this guide (maximum performance), archiving of redo data to the remote standby does not occur until after a log switch. By default, a log switch occurs when an online redo log becomes full which means the standby database does not get updated until then. To force the current redo logs to be archived immediately, use the following statement on the primary database:
At this point, the standby database will continue to apply changes from archive redo logs being transferred from the primary.
Redo Transport From the primary database, perform a log switch and then verify the transmissions of the archive redo log file was successful:
23 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
If the transmission was successful, the status of the destination will be VALID as shown above. If for any reason the transmission was unsuccessful, the status will be INVALID and the full text of the error message will be populated in the ERROR column which can be used to investigate and correct the issue.
Redo Apply To verify Redo Apply, identify the existing archived redo logs on the standby, archive a log or two from the primary, and then check the standby database again. This test will ensure that redo data was shipped from the primary and then successfully received, archived, and applied to the standby. First, identify the existing archived redo redo logs on the standby database:
SQL> select sequence#, first_time, next_time, archived, applied from v$archived_log order by sequence#; SEQUENCE# ---------320 321 322 323 324 325 326 327 328 FIRST_TIME -------------------10-DEC-2010 08:34:06 10-DEC-2010 08:49:39 10-DEC-2010 09:05:15 10-DEC-2010 09:20:48 10-DEC-2010 09:36:20 10-DEC-2010 09:51:52 10-DEC-2010 10:07:27 10-DEC-2010 10:14:23 10-DEC-2010 10:14:49 NEXT_TIME -------------------10-DEC-2010 08:49:39 10-DEC-2010 09:05:15 10-DEC-2010 09:20:48 10-DEC-2010 09:36:20 10-DEC-2010 09:51:52 10-DEC-2010 10:07:27 10-DEC-2010 10:14:23 10-DEC-2010 10:14:49 10-DEC-2010 10:30:23 ARCHIVED -------YES YES YES YES YES YES YES YES YES APPLIED ------YES YES YES YES YES YES YES YES YES
From the primary database, archive the current log using the following SQL statement:
24 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
Go back to the standby database and re-query the V$ARCHIVED_LOG view to verify redo data was shipped, received, archived, and applied:
SQL> select sequence#, first_time, next_time, archived, applied from v$archived_log order by sequence#; SEQUENCE# ---------320 321 322 323 324 325 326 327 328 329 FIRST_TIME -------------------10-DEC-2010 08:34:06 10-DEC-2010 08:49:39 10-DEC-2010 09:05:15 10-DEC-2010 09:20:48 10-DEC-2010 09:36:20 10-DEC-2010 09:51:52 10-DEC-2010 10:07:27 10-DEC-2010 10:14:23 10-DEC-2010 10:14:49 10-DEC-2010 10:30:23 NEXT_TIME -------------------10-DEC-2010 08:49:39 10-DEC-2010 09:05:15 10-DEC-2010 09:20:48 10-DEC-2010 09:36:20 10-DEC-2010 09:51:52 10-DEC-2010 10:07:27 10-DEC-2010 10:14:23 10-DEC-2010 10:14:49 10-DEC-2010 10:30:23 10-DEC-2010 10:39:56 ARCHIVED -------YES YES YES YES YES YES YES YES YES YES APPLIED ------YES YES YES YES YES YES YES YES YES YES
Monitoring the alert.log of the Standby Database Querying the V$ARCHIVED_LOG view from the standby database is a good way to ensure Redo Transport and Redo Apply is doing their job correctly. In addition, I also like to tail the alert.log file of the standby database as a double check. From the standby database, perform a tail -f against the alert.log while issuing the "alter system archive log current" statement from the primary:
[oracle@vmlinux2 ~]$ cd /u01/app/oracle/admin/turlock/bdump [oracle@vmlinux2 bdump]$ tail -f alert_turlock.log RFS[2]: Successfully opened standby log 5: '/u02/oradata/TURLOCK/onlinelog/o1_mf_5_6j0ml7nw_.log' Fri Dec 10 10:14:51 EST 2010 Media Recovery Log /u03/flash_recovery_area/TURLOCK/archivelog/2010_12_10/o1_mf_1_326_6j4jzbpc_.arc Media Recovery Log /u03/flash_recovery_area/TURLOCK/archivelog/2010_12_10/o1_mf_1_327_6j4jzcbm_.arc Media Recovery Waiting for thread 1 sequence 328 Fri Dec 10 10:30:24 EST 2010 RFS[1]: Successfully opened standby log 4: '/u02/oradata/TURLOCK/onlinelog/o1_mf_4_6j0mkynk_.log'
25 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
Fri Dec 10 10:30:26 EST 2010 Media Recovery Log /u03/flash_recovery_area/TURLOCK/archivelog/2010_12_10/o1_mf_1_328_6j4kwjb5_.arc Media Recovery Waiting for thread 1 sequence 329 Fri Dec 10 10:39:57 EST 2010 RFS[2]: Successfully opened standby log 4: '/u02/oradata/TURLOCK/onlinelog/o1_mf_4_6j0mkynk_.log' Fri Dec 10 10:39:58 EST 2010 Media Recovery Log /u03/flash_recovery_area/TURLOCK/archivelog/2010_12_10/o1_mf_1_329_6j4lgfsr_.arc Media Recovery Waiting for thread 1 sequence 330
Deletion Policy for Archived Redo Log Files In Flash Recovery Area
By default, archived redo log files in a flash recovery area that were backed up to a tertiary device or made obsolete (as defined by the RMAN retention policy) are eligible for deletion. The archived redo log files that are backed up or obsolete can eventually be deleted automatically to make space if the disk space in the flash recovery area becomes full. However, you can change this default deletion policy on either the primary or standby database using the following RMAN command.
This section describes the command qualifiers and provides examples for setting up a deletion policy for archived redo log files which are already applied on standby database in Oracle Database 10g and above.
Using the APPLIED ON STANDBY Clause Use the APPLIED ON STANDBY clause so that archived redo log files that have been applied on all mandatory standby destinations will be deleted. The actions taken when you specify this clause are described in the following table.
APPLIED ON STANDBY Clause
When the APPLIED ON STANDBY clause is configured on ... The primary database A standby database that has one or more mandatory cascading standby databases. A standby database that has no cascading standby databases. Then, these files are eligible for deletion ... Archived redo log files in the flash recovery area that were applied on all mandatory standby databases. Archived redo log files in the flash recovery area that were applied on all mandatory cascading standby databases. Archived redo log files in the flash recovery area that were applied on the standby database.
26 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
Use the CLEAR clause to disable the deletion policy that was previously set up with the RMAN CONFIGURE ARCHIVELOG DELETION POLICY command. The Oracle database will resume the default deletion policy behavior, which is to delete archived redo log files that are backed up or obsolete to make space if disk space in the flash recovery area becomes full.
Using the NONE Clause
Use the NONE clause so that archived redo logs in flash recovery area that were backed up or obsolete as per the RMAN retention policy are eligible for deletion. This is the default configuration. Archived redo log files that are backed up or obsolete are deleted to make space if the disk space in the flash recovery area becomes full.
Using the CONFIGURE ARCHIVELOG DELETION POLICY Command
As described in the above table, the APPLIED ON STANDBY setting can be configured on both the primary and standby database. In most cases, the APPLIED ON STANDBY setting should not be set on the database that is performing and maintaining RMAN backups for the purpose of recovery. For example. When backups of archived redo log files are taken on the primary database: 1. Issue the following command on the standby database:
When backups of archived redo log files are taken on the standby database: 1. Issue the following command on the primary database:
27 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
Post-Creation Steps
At this point, the physical standby database is running and can provide the maximum performance level of data protection (the default). The following list describes additional preparations you can take on the physical standby database: Upgrade the data protection mode The Data Guard configuration is initially set up in the maximum performance mode (the default). See "Setting the Data Protection Mode of a Data Guard Configuration" for information about the data protection modes and how to upgrade or downgrade the current protection mode. Enable Flashback Database Flashback Database removes the need to re-create the primary database after a failover. Flashback Database enables you to return a database to its state at a time in the recent past much faster than traditional point-in-time recovery, because it does not require restoring datafiles from backup nor the extensive application of redo data. You can enable Flashback Database on the primary database, the standby database, or both. See "Using Flashback Database After a Failover" and "Using Flashback Database After Issuing an Open Resetlogs Statement" for scenarios showing how to use Flashback Database in a Data Guard environment. Also, see Oracle Database Backup and Recovery Advanced User's Guide for more information about Flashback Database.
Further Reading
Additional information on Oracle 10g Release 2 Data Guard can be found in the Data Guard Concepts and Administration. This guide is available from the Oracle Documentation Library website located at the following address http://download.oracle.com/docs/cd/B19306_01/server.102/b14239.pdf.
28 of 29
13/02/2013 12:11 PM
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_40.shtml
high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX, Linux, and Windows server environment. Jeff's other interests include mathematical encryption theory, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 18 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science.
29 of 29
13/02/2013 12:11 PM