HIGH AVAILABILITY
Lines Description
1, 2 Connects to primary and standby instances as SYSDBA. ( This is why you need to copy the
password file of the primary server to the standby server.)
5, 6 Allocates two channels—p1 and s1—for primary and standby databases, respectively.
8 Oracle RMAN duplicate command creates a clone of the primary database.
9 An spfile must be created from the initialization parameter file (pfile) and updated with the
parameters in lines 10 through 22.
10 If a parameter contains the name of the primary database (pridb), it should be converted to
the name of the standby database (sbydb). This line causes the parameter to be changed in the
standby database.
11 Specifies the unique name of the standby database.
12, 13 The names of the datafiles are changed from the primary to standby naming conventions. For
example, the +DATA1/pridb/system_01.dbf file will be copied and maintained as +DATA1/sbydb/
system_01.dbf. This is not required if the standby database is on a different server (as is the case
now) but may be a good practice to separate the names.
16, 17 Specifies the fetch archived log (FAL) process parameters: the FAL server is the primary database
(pridb), which pushes changes to redo log files to the FAL client—the standby database (sbydb).
19 The Oracle Active Data Guard configuration parameters—the primary and standby databases,
respectively—are defined here.
20 This is where the mode of redo shipping is defined. The changes to redo logs are shipped to the
standby database’s standby redo logs via the log writer (LG WR) process. The process of writing is
asynchronous (as specified by the AS YNC parameter).
32 This starts the managed recovery process. The USING CURRENT LOGFILE clause enables real time
apply. The DISCONNEC T clause returns control to the user and runs the log application process
in the background.
Table 1: Explanation of the standby database creation script (Listing 1)
instead of the primary to reduce the
load on the latter. And, better yet, you
can take the backup even when the
standby database is open in read-only
and managed recovery mode.
codeLISTING 2: Partial output of the standby database’s alert log
2008-05-30 17:46: 22.593000 -04:00
Media Recovery Waiting for thread 1 sequence 628
2008-05-30 17:46: 23.928000 -04:00
Primary database is in MAXIMUM PERFORMANCE mode
kcrrvslf: active RFS archival for log 4 thread 1 sequence 627
RFS[ 1]: Successfully opened standby log 5: ‘+DATA1/sby_log02.rdo’
2008-05-30 17:46: 28.717000 -04:00
Recovery of Online Redo Log: Thread 1 Group 5 Seq 628 Reading mem 0
Mem# 0: +DATA1/sby_log02.rdo
4. To test the “active” part of Oracle
Active Data Guard, create a table in the
primary database:
logs on the primary database, first
switch the log file:
CONCLUSION
The physical standby database is a
physical replica of the primary database, kept in sync by the application of
redo log entries from the primary database. With Oracle Active Data Guard
and real time apply, the log entries are
applied in real time but the primary
database does not wait for the redo
application to complete, thereby protecting itself from failures or slowdowns
in the shipment of log information from
the primary to the standby database.
Using the Oracle Active Data Guard
option, you can open the physical
standby database for read-only operations while the managed recovery
process is going on. You can offload all
reporting applications and the Oracle
RMAN backup to the standby database,
easing the load on the primary database
considerably. And because the standby
database is being recovered continuously with real time apply, the standby
database can be activated and used
immediately in case the primary database fails. This combination of features
makes the investment in Oracle Active
Data Guard very worthwhile. O
SQL> create table test (col1 number);
5. After a few seconds, check the
existence of the table in the standby
database:
SQL> select table_name from user_tables
where table_name = ‘TEST’;
The table will be present. The
standby database is open in read-only
mode, but it is still applying the logs
from the primary database. This feature
enables you to run reports against it
without sacrificing the ability to put
the standby database into the primary
role quickly.
6. To confirm the application of redo
SQL> alter system switch logfile;
7. Now observe the alert log of the
standby database. Use the automatic
diagnostic repository command interpreter (ADRCI) tool, new in Oracle
Database 11g:
adrci
adrci> show alert -tail -f
The output is shown in Listing 2.
The log message confirms that standby
log group 5 was opened. The log was
switched on the standby database
when the log switch occurred on the
primary database.
You can take an Oracle RMAN
backup from the standby database
Arup Nanda ( arup@proligence.com) has been an
Oracle DBA for more than 14 years, handling all
aspects of database administration, from performance
tuning to security and disaster recovery. He was Oracle
Magazine’s DBA of the Year in 2003.
nextSTEPS
READ online-only article content
otn.oracle.com/oramag/oracle/08-nov/o68adg.html
LEARN more about
Oracle Active Data Guard
oracle.com/database/active-data-guard.html
otn.oracle.com/deploy/availability/htdocs/
activedataguard.html
Oracle Data Guard Concepts and Administration
download.oracle.com/docs/cd/B28359_01/server.111/
b28294/ toc.htm
Oracle high-availability solutions
oracle.com/database/high-availability.html
