Testing a Physical Standby Database in Oracle 10g Jan 21, 2009 / By Marcelo Lopes Tags: Oracle If you don

t want to deal with missteps, I recommend that you test your standby da tabase to facilitate the failover or switchover process. This procedure is very useful when you have physical standby databases for testi ng and other purposes that require read-write access to the standby database. Al so, it improves your checklist in the event of an error or disaster. By using Snapshot standby databases, redo data is not applied until you convert the snapshot standby database back into a physical standby database, and after a ll local updates to the snapshot standby database are discarded. Requirements The following requirements need to be met in order to create a snapshot standby. The Data Guard environment (a primary and a physical standby) needs to be Or acle 10.2.0.1 version or higher. The Primary and Standby databases need to be in archivelog mode (this is a d efault requirement for Data Guard). Force logging should be set to TRUE (to avoid no-logging operations). Flash Recovery Area (FRA) is required on the standby database to implement a Flashback database. The Primary and standby are in sync at the time of the test, or the gap betw een primary and physical standby is nominal. Activation of the standby On the standby database Stop dataguard brokers on standby: SQL> alter system set dg_broker_start=FALSE; Get the SCN SQL> select current_scn from v$database; Cancel the managed recovery: SQL> alter database recover managed standby database cancel; Create the restore point.A restore point can be specified such that it guara ntees the database can be recovered to a particular point-in-time and eliminates the need to manually record an SCN or timestamp to use with the Flashback datab ase and Flashback table operations: SQL> create restore point TEST_NEW_FEATURE guarantee flashback database; Now confirm the scn from restore point: SQL> col name form a40; SQL> select scn, time, name from v$restore_point where name = 'TEST_NEW_FEAT URE'; Prepare the primary

Archive logsWhen using the standby redo logs, this step is essential to ensu re that the database can be properly flashed back to the restore point. SQL> alter system archive log current; SQL> alter system switch logfile; SQL> alter system switch logfile; Stop shipment of logs SQL> alter system set log_archive_dest_state_2=DEFER Activate the Physical Standby Activation of the standby: SQL> alter database activate standby database; SQL> startup mount force; SQL> alter database set standby database to maximize performance; (This is used in case you have not set it before) SQL> alter database open; disable log_archive_dest_2 (this will prevent archive logs being sent to pri mary): SQL> alter system set log_archive_dest_state_2=DISABLE; Time for testing Once the standby database has been activated, it is a full-blown production syst em. You may run reports, test new code, or create objects. Remember that any res ults stored in the activated database will be lost when the database is flashed back to before activation time.. If you need to save the results, they must be c opied or exported out of the activated database before flashing it back. Revert the snapshot database to physical standby After testing is completed, you need to resynchronize the activated database wit h the primary database. Flashback to the restore point: SQL> SQL> SQL> SQL> SQL> STARTUP MOUNT FORCE; FLASHBACK DATABASE TO RESTORE POINT TEST_NEW_FEATURE; ALTER DATABASE CONVERT TO PHYSICAL STANDBY; ALTER SYSTEM SET DG_BROKER_START=TRUE; STARTUP MOUNT FORCE;

Re-enable log shipping on the primaryEnable shipment: SQL> alter system set log_archive_dest_state_2=ENABLE To re-enable log shipping on the standby, enable this parameter: SQL> alter system set log_archive_dest_state_2=ENABLE Check dgmgrl configurationDGMGRL> show configuration verbose; Current status for xxx : SUCCESS DGMGRL> enable configuration (if not success)

A status of data guard configuration successful indicates the success of the pro cedures. On Oracle Database 11g, you can use the Data Guard command-line interface (DGMGR L), Oracle Active Data Guard, and the OEM interface. In my next blog I ll describe the equivalent procedures on 11g.