Rolling Forward a Physical Standby Database Using the RECOVER Command. A standby database is a transactionally-consistent copy of the production database. Dataguard : Recover from Service. Rolling Forward a Physical Standby Database Using the RECOVER Command A standby database is a transactionally- consistent copy of the production database. It enables production Oracle database to survive disasters and data corruption. ![]()
If the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch a standby database to the production role, minimizing the downtime associated… Continue Reading →Rolling Forward a Physical Standby Database Using the RECOVER Command. A standby database is a transactionally- consistent copy of the production database. It enables production Oracle database to survive disasters and data corruption. ![]() Dgmgrl Edit Database Set State Transport Corporation ContactDgmgrl Edit Database Set State Transport Corporation Of GujaratIf the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch a standby database to the production role, minimizing the downtime associated with the outage. Moreover, performance of production database can be improved by offloading resource- intensive backup and reporting operations to standby systems. As you can see, it’s always desirable to have standby database synchronized with the primary database. A standby database might lag behind the primary for various reasons like: Unavailability of or insufficient network bandwidth between primary and standby database. Unavailability of Standby database. Corruption / Accidental deletion of Archive Redo Data on primary. If standby database lags behind the primary database: Switchover will take more time. Failover will result in data loss. An attempt to issue Real Time Query against the standby database will result in error. ORA- 0. 31. 72 : STANDBY_MAX_DATA_DELAY of n seconds exceeded. Synchronizing the standby and primary databases can be done by copying and applying the archived logs from the primary database but this process is quite time consuming as it will first apply both the COMMITED and the NON COMMITED transactions followed by rolling back uncommitted transactions. Employing incremental backups of the primary database containing changes since the standby database was last refreshed is a faster alternative which will recover the standby database much faster as it will apply only the COMMITED transactions on the standby database. Moreover, incremental backups are also useful in cases when there are missing archived logs on Primary which have not been applied to the standby database. Prior to 1. 2c, in order to roll forward the standby database using incremental backups you would need to: Create a control file for the standby database on the primary database. Take an incremental backup on the primary starting from the SCN# of the standby database. Copy the incremental backup to the standby host and catalog it with RMAN. Mount the standby database with newly created standby control file. Cancel managed recovery of the standby database and apply incremental backup to the standby database. Start managed recovery of standby database. In 1. 2c, this procedure has been dramatically simplified. Now you can use the RECOVER … FROM SERVICE command to synchronize the physical standby database with the primary database. This command does the following: Creates an incremental backup containing the changes to the primary database. All changes to data files on the primary database, beginning with the SCN in the standby data file header, are included in the incremental backup. Transfers the incremental backup over the network to the physical standby database. Applies the incremental backup to the physical standby database. This results in rolling forward the standby data files to the same point- in- time as the primary. However, the standby control file still contains old SCN values which are lower than the SCN values in the standby data files. Therefore, to complete the synchronization of the physical standby database, the standby control file needs to be refreshed to update the SCN#. Now I will demonstrate the steps to refresh the physical standby database with changes made to the primary database using the RECOVER…FROM SERVICE command. Overview: View current configuration and verify that primary database, far sync for primary and standby database are in sync. Simulate loss of archived logs on the primary database. Refresh the physical standby using the RECOVER…FROM SERVICE command. Setting up the example. View Current configuration. ![]() DGMGRL> show configuration. Configuration - drsolution. Protection Mode: Max. Performance. boston - Primary database. FS - Far Sync. london - Physical standby database. Logical standby database (disabled). Far Sync (inactive). Fast- Start Failover: DISABLED. Configuration Status. SUCCESSIt can be verified that primary database (boston), far sync for primary (boston. FS) and physical standby (london) are in sync.- - Primary (boston) - -. BOSTON> select max(sequence#) from v$archived_log. Far Sync for primary (boston. FS) - -. BOSTONFS> select max(sequence#) from v$archived_log. Physical standby (london) - -. LONDON> select max(sequence#) from v$archived_log. Simulate loss of archived logs on primary database (boston)Let’s stop redo transport from primary (boston) and switch logs on primary so that far sync (boston. FS ) and physical standby (london) lag behind primary (boston). DGMGRL> show database boston. Database - boston. Role: PRIMARY. Intended State: TRANSPORT- ON. Instance(s). Database Status. DGMGRL> edit database boston set state='TRANSPORT- OFF'. BOSTON> alter system switch logfile. System altered. We can verify that logs are not being transported to far sync boston. FS and standby london. Although sequence# of the latest archived log is 1. BOSTON> select max(sequence#) from v$archived_log. BOSTONFS> select max(sequence#) from v$archived_log. LONDON> select max(sequence#) from v$archived_log. Next we’ll find out the names of archived logs generated on primary which have not been transported to standby: BOSTON> select sequence#, name from v$archived_log where sequence# > 1. BOSTON/archivelog/2. BOSTON/archivelog/2. BOSTON/archivelog/2. In a real- time environment, archived logs on primary could be lost due to: their deletion if archivelog deletion policy has not configured properlytheir corruption. In our experimental setup, I’ll simulate loss of archived logs on primary by renaming them: BOSTON> ho mv /u. BOSTON/archivelog/2. BOSTON> ho mv /u. BOSTON/archivelog/2. BOSTON> ho mv /u. BOSTON/archivelog/2. Now even if we restart redo transport from primary, gap in redo logs on far_sync / standby cannot be resolved as some logs are missing on primary. DGMGRL> edit database boston set state='Transport- on'. DGMGRL> show configuration. Configuration - drsolution. Protection Mode: Max. Performance. boston - Primary database. Error: ORA- 1. 67. Far Sync. london - Physical standby database. Logical standby database (disabled). Far Sync (inactive. Fast- Start Failover: DISABLED. Configuration Status. DGMGRL> show far_sync boston. FS. Far Sync - bostonfs. Transport Lag: 3 minutes 4. Instance(s). Far Sync Status. DGMGRL> show database london. Database - london. Role: PHYSICAL STANDBY. Intended State: APPLY- ON. Transport Lag: 3 minutes 5. Apply Lag: 3 minutes 5. Apply Rate: 7. KByte/s. Real Time Query: OFF. Instance(s). Database Status. SUCCESSIt can be verified that SCN# (3. BOSTON> select current_scn from v$database. LONDON> select current_scn from v$database. Refresh the physical standby using the RECOVER…FROM SERVICE command. First of all let us identify the datafiles on standby database which are out of sync with respect to primary. On checking checkpoint_change# in datafile headers on primary (boston) and standby (london), we note that whereas checkpoint_change# of datafiles 5,7,8,9,1. BOSTON> select file#, checkpoint_change# from v$datafile. FILE# CHECKPOINT_CHANGE#. LONDON> select file#, checkpoint_change# from v$datafile. FILE# CHECKPOINT_CHANGE#. In order to synchronize the standby we will stop the managed recovery processes on the physical standby database and place the physical standby database in MOUNT mode. LONDON> recover managed standby database cancel. Start RMAN and connect as target to the physical standby database. Refresh the data files on the physical standby database by using an incremental backup of the data files on the primary database.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
October 2017
Categories |