Standby Database Checklist

1. Overview
The following document describes the setup of an 11gR2 standby database environment with Data Guard Redo
Apply option and Grid Control. The basic setup consists of creating a standby database using RMAN active
duplication on separate servers. The standby database is then set up in "managed recovery" mode to automate the
process of keeping the standby in sync with the primary database. Both the primary and standby databases are
registered with Oracle Grid Control and the Data Guard configuration can be performed manually or from the Grid
Control console.

1.1 Configuration Steps

To create the standby database with Data Guard Redo Apply option the following basic steps are performed:

• Configure Primary Database

• Configure Standby Database
• Grid Control Setup
• Data Guard Setup

2. Configure Primary Database

2.1 Enable Archiving
The primary database must be running in archivelog mode. If not in archivelog mode then the database must be
stopped, started in mount mode and the following command issued:

SQL> alter database archivelog;

The database can then be opened.

Note that the appropriate log_* initialization parameters need to be set in the pfile/spfile to manage the archive log
files that will now be created.

2.2 Enable Forced Logging

Place the primary database in FORCE LOGGING mode using the following SQL statement:

ALTER DATABASE FORCE LOGGING;

This prevents the use of the "nologging" feature, which would not be replicated in the redo logs, and therefore not
applied on the standby database.

2.3 Insure That a Password File Exists

This is required to enable remote connection as SYSDBA and is used by RMAN and Grid Control. After creating
the password file with the orapwd utility, the following init.ora parameter must be set:

remote_login_passwordfile='EXCLUSIVE'

The password file can be created with the orapwd command:

orapwd file=PWDORADB.ORA entries=10 password=<SYS password>

Standby Database Checklist 8/2/2012, Rev. 1 Page 1

Andy Rivenes, AppsDBA Consulting
2.4 Create Standby Redo Log Files
Standby redo log files are required for higher protection levels where LGWR is used to write redo records. There is
no downside to creating them for both the primary and standby and this allows a switchover back to the primary.
They must be created at least as large as the largest redo log file, and there must be at least one more standby redo
log group than redo log groups on the source database. If created now they will be replicated to the standby when it
is created.

NOTE: The following is an example and must be verified before using.

alter database add standby logfile

'D:\ORACLE_BASE\ORADATA\ONLINELOG\ORADB\SRL01A.RDO' SIZE 50M;
alter database add standby logfile
'D:\ORACLE_BASE\ORADATA\ONLINELOG\ORADB\SRL02A.RDO' SIZE 50M;
alter database add standby logfile
'D:\ORACLE_BASE\ORADATA\ONLINELOG\ORADB\SRL03A.RDO' SIZE 50M;
alter database add standby logfile
'D:\ORACLE_BASE\ORADATA\ONLINELOG\ORADB\SRL04A.RDO' SIZE 50M;

The naming convention is SRL for Standby Redo Log, xx for group number, [a-z] for member number, and RDO
extension for redo log.

2.5 Verify Database spfile Parameters

In order to allow RMAN and OEM to perform backup, restore and configuration changes the database must use an
spfile. The following spfile parameters should be verified. These should match the standby database parameters to
insure symmetric role transitions.

2.5.1 DB_UNIQUE_NAME And Diag/Fast Recovery Area Directories

Data Guard requires that each database have a unique name. This is set using the init.ora parameter
db_unique_name. The diag directory and the Fast Recovery Area both use the db_unique_name in their directory
naming so changing the db_unique_name on a primary database can have the side affect of also changing the diag
and Fast Recovery Area directory names as well.

To avoid this on the primary database the db_unique_name should remain set to what the db_name parameter is set
to (this is the default). The standby database can be set to whatever is appropriate. An example naming scheme
could be:

Current db_name Primary: db_unique_name Standby: db_unique_name

ORADB ORADB ORADB_DG
ORADB ORADB_DG1 ORADB_DG2

2.5.2 Set SPFILE Parameters

NOTE: Some of these parameters are not memory modifiable and will require a restart of the database:

ALTER SYSTEM SET db_name = ORADB SCOPE=SPFILE;

ALTER SYSTEM SET db_unique_name = ORADB SCOPE=SPFILE;

ALTER SYSTEM SET log_archive_config='dg_config=(ORADB, ORADB_DG)'

SCOPE=SPFILE;

ALTER SYSTEM SET log_archive_dest_2='SERVICE=ORADB_DG ASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORADB_DG
COMPRESSION=ENABLE' SCOPE=SPFILE;

Standby Database Checklist 8/2/2012, Rev. 1 Page 2

Andy Rivenes, AppsDBA Consulting
ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=SPFILE;

ALTER SYSTEM SET fal_server=ORADB_DG SCOPE=SPFILE;

ALTER SYSTEM SET remote_login_passwordfile=exclusive SCOPE=SPFILE;

ALTER SYSTEM SET standby_file_management=auto SCOPE=SPFILE;

2.6 Oracle Network Files

On the primary and standby database installation there should be network entries that specifiy how to connect to
each database. These are used to transfer archivelog files to the standby database (whichever machine that may be)
and to connect to the databases themselves. There should also be explicit entries in the listener.ora file to register the
database with the listener and optionally a network entry to specify Oracle Networking access to the standby
database.

The following examples create a symmetrical environment such that switching back and forth between primary and
standby database is transparent to the networking files.

2.6.1 sqlnet.ora File

SQLNET.AUTHENTICATION_SERVICES = (NTS)

2.6.2 listener.ora File

On the primary database server the following entries should be in the listener.ora file:

#
# LISTENER.ORA Network Configuration File
#
LISTENER_ORADB =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORADBVM1)(PORT = 1522))
)
)
)

SID_LIST_LISTENER_ORADB =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ORADB)
(ORACLE_HOME = D:\Oracle_Base\Oracle11g)
(SID_NAME = ORADB)
)
)

ADR_BASE_LISTENER_ORADB = D:\Oracle_Base\Oracle11g\log

2.6.3 tnsnames.ora File

The tnsnames.ora file should be updated with information to allow access to the database with either the standard
database name or the database unique name. Since a non-default listener port is being used there also needs to be an
entry for the local listener.
ORADB_DG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORADBVM2)(PORT = 1522))

Standby Database Checklist 8/2/2012, Rev. 1 Page 3

Andy Rivenes, AppsDBA Consulting
 (CONNECT_DATA =
(SERVER=DEDICATED)
(SERVICE_NAME = ORADB)
)
)

ORADB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORADBVM1)(PORT = 1522))
(CONNECT_DATA =
(SERVER=DEDICATED)
(SERVICE_NAME = ORADB)
)
)

LISTENER_ORADB =
(ADDRESS = ((PROTOCOL = TCP)(HOST = ORADBVM1)(PORT = 1522))

2.7 Fast Recovery Area

Verify that the fast recovery area is configured:

#
# Set fast recovery area
#
db_recovery_file_dest='e:\oracle11g\flash_recovery_area'
db_recovery_file_dest_size=100000M
#
# Set logging parameters – this should not need to be set. log_archive_dest_1 is
# implicitly set in 11gR2 (was log_archive_dest_10)
#
#log_archive_dest_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST valid_for=(ONLINE_LOGFILE,ALL_ROLES)'
#log_archive_dest_state_1='ENABLE'

When using the fast recovery area, normally the log_archive_dest_n parameters should only be set for non-fast
recovery area locations. By default the log_archive_dest_1 location will be used for the fast recovery area (this was
log_archive_dest_10 in previous releases).

2.8 Update Backup Configuration

Since the archivelog files are being managed in the Fast Recovery Area automatic deletion of backed up and applied
archivelog files can be setup by issuing an RMAN configure command. The backup configuration needs to be
modified so that archivelog files are automatically deleted by running the following RMAN CONFIGURE
command on the primary database:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY BACKED UP 5 TIMES

TO DISK;

The highlighted section is the new text.

3. Configure Standby Database

3.1 Software Installation

3.1.1 Database Version

The database version and patch sets should be exactly the same as the primary database.

Standby Database Checklist 8/2/2012, Rev. 1 Page 4

Andy Rivenes, AppsDBA Consulting
3.1.2 Directory Setup
It is much easier if all directories mirror the primary database directories. This includes the datafile and the fast
recovery area directory.

NOTE: It is important to be aware of the differences when using OMF naming and directories versus traditional user
named files and directories.

Because of the way the instance naming occurs the following additional directories should be pre-created.

3.1.3 Oracle Managed Files

• Fast Recovery Area

ORADB_DG\ARCHIVELOG
ONLINELOG

• oradata Directories

ORADB\CONTROLFILE

ORADB_DG\DATAFILE
ONLINELOG

3.1.4 User Defined Files

• Fast Recovery Area

ORADB_DG\ARCHIVELOG
ONLINELOG

• oradata Directories

ORADB

3.2 Oracle Network Files

3.2.1 sqlnet.ora File

SQLNET.AUTHENTICATION_SERVICES = (NTS)

3.2.2 listener.ora File

On the Data Guard server the following entries should be in the listener.ora file:

#
# LISTENER.ORA Network Configuration File
#
LISTENER_ORADBVM2 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORADBVM2)(PORT = 1522))
)
)
)

SID_LIST_LISTENER_ORADBVM2 =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = ORADB_DG)

Standby Database Checklist 8/2/2012, Rev. 1 Page 5

Andy Rivenes, AppsDBA Consulting
 (ORACLE_HOME = D:\Oracle_Base\Oracle11g)
(SID_NAME = ORADB_DG)
)
(SID_DESC =
(GLOBAL_DBNAME = ORADB)
(ORACLE_HOME = D:\Oracle_Base\Oracle11g)
(SID_NAME = ORADB)
)
)

ADR_BASE_LISTENER_ORADBVM2 = D:\Oracle_Base\Oracle11g\log

3.2.3 tnsnames.ora File

The tnsnames.ora file should be updated with information to allow access to the database with either the standard
database name or the database unique name. Since a non-default listener port is being used there also needs to be an
entry for the local listener.
ORADB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORADBVM1)(PORT = 1522))
(CONNECT_DATA =
(SERVER=DEDICATED)
(SERVICE_NAME = ORADB)
)
)

ORADB_DG =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ORADBVM2)(PORT = 1522))
(CONNECT_DATA =
(SERVER=DEDICATED)
(SERVICE_NAME = ORADB_DG)
)
)

LISTENER_ORADB =
(ADDRESS = ((PROTOCOL = TCP)(HOST = ORADBVM2)(PORT = 1522))

3.3 Standby Database Creation

The standby database can be created in serveral different ways, but the simplest method involves using the RMAN
active database duplication feature introduced in Oracle 11g. When using the active database duplication feature the
spfile and the password file are duplicated as well as the database so the initial setup for the duplication is a little
different than the Data Guard documentation indicates. The RMAN documentaton does contain examples of active
database duplication. RMAN has to connect to a running instance, but in this case the instance doesn't need anything
more than a dbname to run. The other requirement is that each instance must be available for a network connection
as SYS. This requires a password file. The following example will detail this scenario along with the spfile
parameters that need to be overriden in the actual RMAN duplication script.

3.3.1 Windows Environments

3.3.1.1 Open an Administrator Command Prompt Window

All commands should be run through a command prompt window that has been opened with “Run As
Administrator”.

3.3.1.2 Create a Windows-based Service on the Standby Server

Use oradim to create a Windows service for the standby database to be created:

D:\>oradim -NEW -SID ORADB -SYSPWD UHave2Choose

Standby Database Checklist 8/2/2012, Rev. 1 Page 6

Andy Rivenes, AppsDBA Consulting
In Windows a service is required in order to run an instance of the Oracle database.

3.3.2 Create a minimal init.ora

Create a minimal init.ora in the %ORACLE_HOME%\database directory with the name of the database being
created. This can be tested with the following syntax:

cd D:\Oracle_Base\Oracle11g\database

Create a file called initORADB.ora and add the following line to it:

db_name = ORADB

3.3.3 Start the standby database listener

Set the ORACLE_HOME and start the standby database listener. A service will be automatically created. The
listener will use the listener.ora file created earlier.

set ORACLE_HOME=D:\Oracle_Base\Oracle11g
lsnrctl start listener_oradb

3.3.4 Start the Standby Instance

set ORACLE_SID=ORADB
sqlplus / as sysdba
SQL> startup nomount
SQL> exit

3.3.5 Create the Standby Database with RMAN

rman
RMAN> CONNECT target sys/UHave2Chooose@ORADB
RMAN> CONNECT AUXILIARY sys/UHave2Choose@ORADB_DG
RMAN> run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate auxiliary channel stby1 type disk;
allocate auxiliary channel stby2 type disk;
#
duplicate target database
for standby
from active database
spfile
set db_unique_name = 'ORADB_DG'
set fal_server = 'ORADB'
set log_archive_dest_2 = 'SERVICE=ORADB ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=ORADB COMPRESSION=ENABLE '
set log_archive_dest_state_2='DEFER'
set db_recovery_file_dest='E:\flash_recovery_area'
set memory_target='1G'
set local_listener='LISTENER_ORADB'
dorecover
nofilenamecheck;
}

3.3.6 Enable Standby Recovery

3.3.6.1 Enable Redo Log Shipping On The Primary Database

Standby Database Checklist 8/2/2012, Rev. 1 Page 7

Andy Rivenes, AppsDBA Consulting
SQL> alter system set LOG_ARCHIVE_DEST_state_2=enable scope=both;

System altered.

SQL> alter system switch logfile;

System altered.

3.3.6.2 Verify Archive Destination

select * from v$archive_dest where dest_id=2;

SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

3.3.6.3 Verifying Apply on Standby

SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED

FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

3.4 Configure For Archivelog Deletion

Since the archived log files are being managed in the Fast Recovery Area automatic deletion of applied files can be
setup by issuing an RMAN configure command on the standby database. Note that this command is slightly
different than the one run on the primary database because no backups are being run on the standby database.

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

4. Standby Management
4.1 Start the Standby Instance
The standby instance must be started and placed in standby mount mode. The database should never be "opened"
because this will invalidate the "standby" status. In addition, the database must be mounted in order to access the
controlfile to allow file name changes and subsequent recovery. The following commands are used:

1. Use SQL*Plus to connect to the standby database instance. For example, enter:

SQL> CONNECT / AS SYSDBA

2. Start the Oracle instance at the standby database without mounting the
database. For example, enter:

SQL> STARTUP NOMOUNT;

3. Mount the standby database:

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

4.2 Modes and Recovery

Once the standby database has been recovered up to the last archived redo log file, it must be kept current by the
application of log files once they have been archived from the primary database or by using redo apply. This can be
done in "manual recovery" mode or in "managed recovery" mode. The standby database can also be opened in "read
only" mode which allows query access to the standby database. No recovery can take place while the database is
open in read only mode though, and so time must be arranged for periodic recoveries to take place in order to keep
the standby in sync with the primary database.

Standby Database Checklist 8/2/2012, Rev. 1 Page 8

Andy Rivenes, AppsDBA Consulting
4.2.1 Starting Recovery
The standby database can be "caught up" and run in managed recovery mode. Managed recovery mode allows for
the automatic application of archived redo log files to the standby database. Managed recovery mode should be
initiated with a disconnected session. The following syntax will accomplish this:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

The USING CURRENT LOGFILE clause is specified so that redo can be applied as soon as it has been received.

It is still possible to perform manual recovery with the command:

SQL> RECOVER STANDBY DATABASE;

or

SQL> ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE;

This will invoke standard cancel based recovery. Once all available archived log files have been applied then cancel
the recovery. At this point managed recovery can be resumed.

4.2.2 Canceling Recovery

Cancel managed recovery with the command:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

or cancel manual or automatic recovery with:

SQL> RECOVER CANCEL;

4.3 Startup and Shutdown

In order to maintain managed recovery of the standby database, the following guidelines must be followed:

"To avoid creating gap sequences, follow these rules:

 Start the standby databases and listeners before starting the primary database.
 Shut down the primary database before shutting down the standby database.

If you violate either of these two rules, then the standby database is down while the
primary database is open and archiving. Consequently, Oracle can create a gap
sequence. When you restart the standby database later, you must synchronize the
standby database manually with the primary database before you can initiate
managed recovery."

Once Data Guard is implemented this is typically not a problem since Data Guard will take care of re-
synchronization.

4.4 Troubleshooting

4.4.1 Archiver Errors

If archived redo log files are not being transferred to the standby database then check the "state" of the archive
destination in the v$archive_dest view on the primary database. If this state is in error then the standby listener
service may have failed. Once that is corrected, you must force the listener to begin re-transmission with the
command:

Standby Database Checklist 8/2/2012, Rev. 1 Page 9

Andy Rivenes, AppsDBA Consulting
SQL> alter system set log_archive_dest_2='service=oradb_dg ARCH SYNC NOAFFIRM delay=0
OPTIONAL max_failure=0 reopen=300 register';

If Data Guard is enabled then this should be issued automatically.

If the primary archive destination has stopped, possibly due to a full disk, fix the problem and issue:
archive log start

5. Grid Control Setup

These instructions assume that the primary database is already registered and being monitored in Grid Control.

5.1 Initial Agent Setup on Standby Server

Grid Control requires that an agent be running on the host machine in order to provide monitoring and status
information. The easiest way to do this is to create a silent installer bundle and a modified response file.

The commands to run the installer are the following:

H:\>g:

G:\

G:\>cd G:\DBA\Grid_Control_Agent\windows_x64\agent

NOTE: The response file has been modified with Grid Control/OMS specific information! Copy the response
file to D:\oracle_base.

G:\>cp additional_agent.rsp D:\Oracle_Base

G:\DBA\Grid_Control_Agent\windows_x64\agent>setup.exe -silent -responseFile

D:\Oracle_Base\additional_agent.rsp

5.2 Grid Control Setup

5.2.1 Register the Standby Database

Once the agent is running the host and its targets should be visible in the Grid Control console. Each database must
then be configured to add the dbsnmp password and the proper listener port number. The standby database itself
does not need to be discovered. That will happen as part of adding the standby database in the screens for the
corresponding primary database.

5.2.2 Reconfigure The Primary Database

If the primary database name does not match the db_unique_name then Grid Control may not report on the
standby/Data Guard status properly. This can be fixed by removing the database in Grid Control and then
“rediscovering” it manually using the db_unique_name.

1. In the Databases screen select the primary database and click “Remove”.
2. Once complete, click the “Add” button. Choose the appropriate host and then manually add the database
using the db_unique_name.

6. DataGuard Setup
DataGuard can be set up manually (e.g. with Data Guard Broker commands) or it can be set up through Enterprise
Manager (i.e. OEM) Grid Control.

Standby Database Checklist 8/2/2012, Rev. 1 Page 10

Andy Rivenes, AppsDBA Consulting
6.1 init.ora Parameters
Verify that the “dg_broker_start” init.ora parameter has been set to TRUE.

Note: We discovered that the Data Guard broker config files are not created until a configuration has been created.
This is different than what the documentation and My Oracle Support notes imply but Grid Control may have
already set the “dg_broker_start” parameter to TRUE.

6.2 Manual Setup

6.2.1 Database Parameters

Note: In 10g the database parameters “remote_archive_enable” and “log_archive_config” are mutually exclusive
and if set on the standby instance the instance will not start.

6.2.1.1 Primary Database Parameters

SQL> show parameter db_unique_name;

NAME TYPE VALUE

------------------------------------ --------------------------------- -------------------
db_unique_name string ORADB
SQL>

SQL> alter system set dg_broker_start=true scope=both;

System altered.

SQL> show parameter dg

NAME TYPE VALUE

------------------------------------ --------------------------------- --------------------------
----
dg_broker_config_file1 string /u01/app/oracle/product/11.2.0.2
/db_1/dbs/dr1ORADB.dat

dg_broker_config_file2 string
/u01/app/oracle/product/11.2.0.2
/db_1/dbs/dr2ORADB.dat

dg_broker_start boolean TRUE

6.2.1.2 Standby Database Parameters

SQL> show parameters db_unique_name

NAME TYPE VALUE

------------------------------------ --------------------------------- -------------------
db_unique_name string ORADB_DG
SQL> show parameters dg

NAME TYPE VALUE

------------------------------------ ---------------- --------------------------------
dg_broker_config_file1 string /u01/app/oracle/product/11.2.0.2
/db_1/dbs/dr1ORADB_DG.dat

dg_broker_config_file2 string /u01/app/oracle/product/11.2.0.2

/db_1/dbs/dr2ORADB_DG.dat

dg_broker_start boolean TRUE

6.2.2 Data Guard Conventions

The initialization of the Data Guard broker environment requires several configuration settings. The following are
recommended conventions for these settings:

Standby Database Checklist 8/2/2012, Rev. 1 Page 11

Andy Rivenes, AppsDBA Consulting
 1. Data Guard configuration name – make this the unqualified database name.
2. Data Guard primary database – This should be the db_unique_name, which will be the database name with a
"_dg<n>" appended to it where n is a unique number starting with 1.
3. Data Guard physical standby database(s) – There should also be unique name for each of the standby
databases (typically there will only be one). Again this should be the database name with a "_dg<n>"
appended to it where n is a unique number starting with 1 greater than the primary database (in this case this
would be a 2).
4. The connect identifiers should match the db_unique_names. This is the way the Oracle Networking
parameters were set up in the Networking Section.

6.2.3 Data Guard Configuration

$ dgmgrl

Welcome to DGMGRL, type "help" for information.

DGMGRL> connect /
Connected.
DGMGRL> show configuration
Error: ORA-16532: Data Guard broker configuration does not exist.

unable to describe configuration

DGMGRL> create configuration 'ORADB' AS
> primary database is 'ORADB'
> connect identifier is ORADB;
Configuration "ORADB" created with primary database "ORADB".
DGMGRL> show configuration

Configuration
Name: ORADB
Enabled: NO
Protection Mode: MaxPerformance
Databases:
ORADB - Primary database

Current status for "ORADB":

DISABLED

DGMGRL> add database 'ORADB_DG' as

> connect identifier is ORADB_DG
> maintained as physical;
Database "ORADB_DG" added.
DGMGRL> show configuration

Configuration
Name: ORADB
Enabled: NO
Protection Mode: MaxPerformance
Databases:
ORATST_DG1 - Primary database
ORATST_DG2 - Physical standby database

Current status for "ORADB":

DISABLED

DGMGRL> enable configuration;

Enabled.
DGMGRL> show configuration

Configuration

Standby Database Checklist 8/2/2012, Rev. 1 Page 12

Andy Rivenes, AppsDBA Consulting
 Name: ORADB
Enabled: YES
Protection Mode: MaxPerformance
Databases:
ORADB - Primary database
ORADB_DG - Physical standby database

Current status for "ORADB":

SUCCESS

DGMGRL>

7. References

Oracle® Data Guard Concepts and Administration 11g Release 2 (11.2)

Oracle® Data Guard Broker 11g Release 2 (11.2)

Oracle® Database Backup and Recovery User's Guide, 11g Release 2 (11.2)

Standby Database Checklist 8/2/2012, Rev. 1 Page 13

Andy Rivenes, AppsDBA Consulting