|
DataGuard
|
Hello, everyone. In this issue, I will start a new topic DataGuard.
What is DataGuard?
The function of Oracle DataGuard is to increase system availability, in a system equipped with more than one standby database, by transmitting REDO log from the primary database to the standby database and taking backup synchronously.
Types of standby database
DataGuard can be used both in the physical standby database configuration and the logical standby database configuration.
In the physical standby configuration, archive log files are transmitted from the primary database to the standby database, and backup files are taken synchronously as recovery files.
In other words, archive log files are applied on the standby database as backup recovery files.
In the logical standby configuration, the transmitted archive log files are transformed into SQL statements, and backup files of the primary database are taken synchronously by executing the SQL statements.
New functions of Oracle10g
Oracle9i extended the standby database (physical standby) of Oracle8i and made it possible to use the logical standby database configuration and to apply REDO log on the standby database.
Real Time Apply function is available since Oracle10g. This function allows the standby database to receive REDO log which is transmitted by the LGWR process of the primary database. The REDO log can be applied on standby database right away without being transformed into archive log. First, let's try the case of physical standby.
SQL> startup mount
ORACLE instance started.
Total System Global Area 188743680 bytes
Fixed Size 778036 bytes
Variable Size 162537676 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
Database mounted.
SQL> recover managed standby database using current logfile disconnect;
Media recovery complete.
|
Let's check if Real Time Apply is executed or not.
SQL> select dest_name,recovery_mode from v$archive_dest_status;
DEST_NAME RECOVERY_MODE
------------------------------ -----------------------
LOG_ARCHIVE_DEST_1 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_2 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_3 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_4 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_5 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_6 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_7 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_8 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_9 MANAGED REAL TIME APPLY
LOG_ARCHIVE_DEST_10 MANAGED REAL TIME APPLY
STANDBY_ARCHIVE_DEST MANAGED REAL TIME APPLY
11 rows selected.
|
MANAGED REAL TIME APPLY is shown here. For a further test, let's switch the log in primary database.
Primary«
SQL> alter system switch logfile;
|
We want to confirm the alert log in standby database.
---------------------------------------------------------------------------
Mon Jun 21 22:13:48 2004
Media Recovery Log /home/oracle/archive/standby/standby1_32_529269042.arc
Mon Jun 21 22:13:48 2004
Primary database is in MAXIMUM PERFORMANCE mode
Mon Jun 21 22:13:51 2004
Media Recovery Waiting for thread 1 sequence 33 (in transit)
---------------------------------------------------------------------------
|
We also confirm that REDO archive is applied.
SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
---------- ---
9 YES
........
SEQUENCE# APP
---------- ---
26 YES
27 YES
28 YES
29 YES
30 YES
31 YES
32 YES
|
It seems that everything goes well. REDO archive is applied right away and should be able to reduce the down time for recovery.
That's it for today.
Masaru Hayashi
|
|
