Snapshot Standby: Role Transition cycle





Create, test, resynchronize with production, create again




Q&As: Data Guard, Role Transitions (I)



(Q) Which 6 steps must be performed to prepare for a role transition?


(1) Verify that each database is properly configured for the role that it is about to assume

  • Check that necessary initialization parameters are properly configured in each database
    • FAL_SERVER, DB_FILE_NAME_CONVERT, LOG_FILE_NAME_CONVERT
    • LOG_ARCHIVE_DEST_n and LOG_ARVHIVE_DEST_STATE_n
  • Check that ONLINE REDO LOGs and STANDBY REDO LOGs exist and are properly configured on all databases
SQL> select status, type, member, group#
  2* from v$logfile;

STATUS TYPE MEMBER         GROUP#
------- ------- ------------------------------------------------------------ ----------
 ONLINE /u01/app/oracle/oradata/fresno/redo03.log         3
 ONLINE /u01/app/oracle/oradata/fresno/redo02.log         2
 ONLINE /u01/app/oracle/oradata/fresno/redo01.log         1
 STANDBY /u01/app/oracle/oradata/fresno/standby_redo01.log        4
 STANDBY /u01/app/oracle/oradata/fresno/standby_redo02.log        5
 STANDBY /u01/app/oracle/oradata/fresno/standby_redo03.log        6
 STANDBY /u01/app/oracle/oradata/fresno/standby_redo04.log        7

7 rows selected.


(2) Verify that there are no Redo Transport errors or Redo Gaps at the standby database

  • For LOG_ARCHIVE_DEST_2, STATUS should be VALID and GAP_STATUS should be NO GAP
(On the Physical Standby:)
SQL> select dest_name, status, type, gap_status
  2  from v$archive_dest_status;

DEST_NAME            STATUS    TYPE            GAP_STATUS
------------------- --------- --------------- ----------
LOG_ARCHIVE_DEST_1   VALID     LOCAL
LOG_ARCHIVE_DEST_2   VALID     UNKNOWN         NO GAP
...
STANDBY_ARCHIVE_DEST VALID     UNKNOWN         NO GAP

(On the primary database)
SQL> select dest_name, status, type, gap_status
  2* from v$archive_dest_status;

DEST_NAME            STATUS    TYPE           GAP_STATUS
-------------------- --------- -------------- ------------------------
LOG_ARCHIVE_DEST_1   VALID     LOCAL
LOG_ARCHIVE_DEST_2   VALID     PHYSICAL       NO GAP
LOG_ARCHIVE_DEST_3   INACTIVE  LOCAL


(3) Verify that temporary files exist on the Standby that match the temporary files on the primary database



(4) Remove any delay in applying redo that may be in effect on the standby database that will become the new primary database

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY DISCONNECT FROM SESSION;


(5) Before performing a switchover from an Oracle RAC primary databsae to a physical standby, shut down all but one primary db instance



(6) If the physical standby that will become primary on the switchover is in real-time query mode, consider bringing all instances of the standby database to the mounted but not open state. This will allow:

  • (a) the fastest possible role transition and/li>
  • (b) to cleanly terminate any user sessions connected to the physical standby prior to the role transition


Q&As: Fast Recovery Area (III)



(Q) What types of database files can be stored in the FAST RECOVERY AREA?

  • control file, online redo logs, archived redo logs, flashback logs, and RMAN backups


(Q) What two types of files, with respect to their use by the database, are kept in the FAST RECOVERY AREA?

  • Permanent files – Active files used by the database instance (control file, online redo logs)
  • Transient files – backups that may be deleted according to the retention policy



(Q) What happens if the instance cannot write to a multiplexed copy of the control file stored in the fast recovery area?

  • The instance fails.
  • Failure occurs EVEN if accessibel multiplexed copies are accessible outside the recovery area.


(Q) What is the difference between FLASH RECOVERY AREA and FAST RECOVERY AREA?

  • Just the name. FLASH became FAST with 11g


(Q) When configuring the FAST RECOVERY AREA, what happens if you specify DB_RECOVERY_FILE_DEST but DO NOT specify DB_RECOVERY_FILE_DEST_SIZE?

  • Specifying DB_RECOVERY_FILE_DEST without specifying DB_RECOVERY_FILE_DEST_SIZE is not allowed.