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 andGAP_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 specifyingDB_RECOVERY_FILE_DEST_SIZE
is not allowed.
Labels:
Fast Recovery Area,
Oracle,
QandA
Subscribe to:
Posts (Atom)