{"id":73175,"date":"2015-02-17T11:27:55","date_gmt":"2015-02-17T11:27:55","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/uncategorized\/rolling-forward-a-physical-standby-database-using-the-recover-command\/"},"modified":"2026-04-15T18:45:50","modified_gmt":"2026-04-15T18:45:50","slug":"rolling-forward-a-physical-standby-database-using-the-recover-command","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/oracle-databases\/rolling-forward-a-physical-standby-database-using-the-recover-command\/","title":{"rendered":"Oracle 12c DataGuard: Roll Forward a Physical Standby with RECOVER FROM SERVICE"},"content":{"rendered":"\n

Executive Summary<\/h2>\n\n\n\n

When a physical standby database in Oracle DataGuard falls behind the primary – because archived logs were lost or redo transport was interrupted – it can be rolled forward without a full resynchronisation using the RECOVER…FROM SERVICE command. This is faster than rebuilding the standby from scratch and avoids the overhead of shipping all diverged archived logs. The command uses an incremental backup approach to close the gap between the standby’s current SCN and the primary’s current SCN. This article demonstrates the complete procedure: verifying the configuration with the primary (boston), far sync (bostonFS), and standby (london); simulating archived log loss; identifying out-of-sync datafiles on the standby; and executing and verifying the RECOVER FROM SERVICE recovery.<\/strong><\/p>\n\n\n\n

Rolling Forward a Physical Standby Database Using the RECOVER Command<\/b><\/h2>\n\n\n\n

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 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\u2019s always desirable to have standby database synchronized with the primary database.<\/p>\n\n\n\n

A standby database might lag behind the primary for various reasons like:<\/p>\n\n\n

\n
    \n
  • Unavailability of or insufficient \u00a0network bandwidth between primary and standby database<\/li>\n\n\n\n
  • Unavailability of Standby database<\/li>\n\n\n\n
  • Corruption \/ Accidental deletion of \u00a0Archive Redo Data on primary<\/li>\n<\/ul>\n<\/div>\n\n\n

    If standby database lags behind the primary database:<\/p>\n\n\n

    \n
      \n
    • Switchover will take more time.<\/li>\n\n\n\n
    • Failover will result in data loss.<\/li>\n\n\n\n
    • An attempt to issue Real Time Query against the standby database will result in error
      ORA-03172 : STANDBY_MAX_DATA_DELAY of n seconds exceeded.<\/code><\/li>\n<\/ul>\n<\/div>\n\n\n

      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<\/p>\n\n\n\n

      Prior to 12c, in order to roll forward the standby database using incremental backups you would need to:<\/p>\n\n\n

      \n
        \n
      • Create a control file for the standby database on the primary database.<\/li>\n\n\n\n
      • Take an incremental backup on the primary starting from the SCN# of the standby database.<\/li>\n\n\n\n
      • Copy the incremental backup to the standby host and catalog it with RMAN.<\/li>\n\n\n\n
      • Mount the standby database with newly created standby control file.<\/li>\n\n\n\n
      • Cancel managed recovery of the standby database and apply incremental backup to the standby database.<\/li>\n\n\n\n
      • Start managed recovery of standby database.<\/li>\n<\/ul>\n<\/div>\n\n\n

        In 12c, this procedure has been dramatically simplified. Now you can use the RECOVER \u2026 FROM SERVICE command to synchronize the physical standby database with the primary database.  This command does the following:<\/p>\n\n\n

        \n
          \n
        • 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.<\/li>\n\n\n\n
        • Transfers the incremental backup over the network to the physical standby database.<\/li>\n\n\n\n
        • Applies the incremental backup to the physical standby database.<\/li>\n<\/ul>\n<\/div>\n\n\n

          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#.<\/p>\n\n\n\n

          Now I will demonstrate the steps to refresh the physical standby database with changes made to the primary database using the RECOVER\u2026FROM SERVICE command.<\/b><\/p>\n\n\n\n

          Overview:<\/b><\/p>\n\n\n

          \n
            \n
          • View current configuration and verify that primary database, far sync for primary and standby database are in sync<\/li>\n\n\n\n
          • Simulate loss of archived logs on the primary database<\/li>\n\n\n\n
          • Refresh the physical standby using the RECOVER\u2026FROM SERVICE command<\/li>\n<\/ul>\n<\/div>\n\n\n

            Setting up the example<\/h2>\n\n\n\n

            View Current configuration<\/h3>\n\n\n\n
            DGMGRL> show configuration;\nConfiguration - drsolution\n\nProtection Mode: MaxPerformance\nDatabases:\n   boston   - Primary database\n   bostonFS - Far Sync\n   london   - Physical standby database\n   london2  - Logical standby database (disabled)\n   londonfs - Far Sync (inactive)\n\nFast-Start Failover: DISABLED\n\nConfiguration Status:\n\nSUCCESS<\/pre>\n\n\n\n
            It can be verified that primary database (boston), far sync for primary (bostonFS) and physical standby (london) are in sync.<\/p>\n\n\n\n
            -- Primary (boston) --<\/span>\n\nBOSTON>select max(sequence#) from v$archived_log;\n\nMAX(SEQUENCE#)\n\n--------------\n\n        190<\/b>\n\n-- Far Sync for primary (bostonFS) --<\/span>\n\nBOSTONFS>select max(sequence#) from v$archived_log;\n\nMAX(SEQUENCE#)\n\n--------------\n\n        190<\/b>\n\n-- Physical standby (london) --<\/span>\n\nLONDON>select max(sequence#) from v$archived_log;\n\nMAX(SEQUENCE#)\n\n--------------\n\n         190<\/b><\/pre>\n\n\n\n
            Simulate loss of archived logs on primary database (boston)<\/h3>\n\n\n\n
            Let\u2019s stop redo transport from primary (boston) and switch logs on primary so that far sync (bostonFS ) and physical standby (london) lag behind primary (boston).<\/p>\n\n\n\n
            DGMGRL> show database boston\nDatabase - boston\n   Role:              PRIMARY\n   Intended State:    TRANSPORT-ON\n   Instance(s):\n      boston\nDatabase Status:\nSUCCESS\n\nDGMGRL> edit database boston set state='TRANSPORT-OFF';\n\nSucceeded.\n\nBOSTON>alter system switch logfile;\n         alter system switch logfile;\n         alter system switch logfile;\n\nSystem altered.<\/pre>\n\n\n\n
            We can verify that logs are not being transported to far sync bostonFS and standby london. Although sequence# of the latest archived log is 194 on primary, archived logs up to sequence# 191 only have reached far sync and physical standby.<\/p>\n\n\n\n
            BOSTON>select max(sequence#) from v$archived_log;\nMAX(SEQUENCE#)\n--------------\n           194\n\nBOSTONFS>select max(sequence#) from v$archived_log;\nMAX(SEQUENCE#)\n--------------\n           191\n\nLONDON>select max(sequence#) from v$archived_log;\nMAX(SEQUENCE#)\n--------------\n           191<\/pre>\n\n\n\n
            Next we\u2019ll find out the names of archived logs generated on primary which have not been transported to standby:<\/p>\n\n\n\n
            BOSTON>select sequence#, name from v$archived_log where sequence# >191;\n\nSEQUENCE# NAME\n\n---------- ----------------------------------------------------------------\n\n192 \/u01\/app\/oracle\/fast_recovery_area\/BOSTON\/archivelog\/2015_02_09\/o1_mf_1_192_bfjgx50j_.arc\n193 \/u01\/app\/oracle\/fast_recovery_area\/BOSTON\/archivelog\/2015_02_09\/o1_mf_1_193_bfjgx6tb_.arc\n194 \/u01\/app\/oracle\/fast_recovery_area\/BOSTON\/archivelog\/2015_02_09\/o1_mf_1_194_bfjgx6yh_.arc<\/pre>\n\n\n\n
            In a real-time environment, archived logs on primary could be lost due to:<\/p>\n\n\n
            \n
              \n
            • their deletion if archivelog deletion policy has not configured \u00a0properly<\/li>\n\n\n\n
            • their corruption<\/li>\n<\/ul>\n<\/div>\n\n\n
              In our experimental setup, I\u2019ll  simulate loss of archived logs on primary by renaming them:<\/p>\n\n\n\n
              BOSTON>ho mv \/u01\/app\/oracle\/fast_recovery_area\/BOSTON\/archivelog\/2015_02_09\/o1_mf_1_192_bfjgx50j_.arc\n\/home\/oracle\/arch_192.log\nBOSTON>ho mv \/u01\/app\/oracle\/fast_recovery_area\/BOSTON\/archivelog\/2015_02_09\/o1_mf_1_193_bfjgx6tb_.arc\n\/home\/oracle\/arch_193.log\nBOSTON>ho mv \/u01\/app\/oracle\/fast_recovery_area\/BOSTON\/archivelog\/2015_02_09\/o1_mf_1_194_bfjgx6yh_.arc\n\/home\/oracle\/arch_194.log<\/pre>\n\n\n\n
              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.<\/p>\n\n\n\n
              DGMGRL>  edit database boston set state='Transport-on'<\/b>;\nDGMGRL> show configuration;\nConfiguration - drsolution\n   Protection Mode: MaxPerformance\n   Databases:\n   boston   - Primary database\n      Error: ORA-16724: cannot resolve gap for one or more standby databases\n      bostonfs - Far Sync\n        london   - Physical standby database\n        london2  - Logical standby database (disabled)\n      londonfs - Far Sync (inactive\nFast-Start Failover: DISABLED\nConfiguration Status:\nERROR<\/span>\n\nDGMGRL> show far_sync bostonFS\nFar Sync - bostonfs\n   Transport Lag:     3 minutes 43 seconds (computed 1 second ago)\n   Instance(s):\n      bostonFS\nFar Sync Status:\nSUCCESS\n\nDGMGRL> show database london\nDatabase - london\n   Role:              PHYSICAL STANDBY\n   Intended State:    APPLY-ON\n   Transport Lag:     3 minutes 53 seconds (computed 0 seconds ago)\n   Apply Lag:         3 minutes 53 seconds (computed 0 seconds ago)\n   Apply Rate:        759.00 KByte\/s\n   Real Time Query:   OFF\n   Instance(s):\n      london\nDatabase Status:\nSUCCESS<\/pre>\n\n\n\n
              It can be verified that SCN# (3717618) of standby (london) is lagging behind that (3718999) of the primary (boston)<\/p>\n\n\n\n
              BOSTON>select current_scn from v$database;\nCURRENT_SCN\n          -----------\n            3718999\n\nLONDON>select current_scn from v$database;\nCURRENT_SCN\n          ----------\n           3717618<\/pre>\n\n\n\n
              Refresh the physical standby using the RECOVER\u2026FROM SERVICE command<\/h3>\n\n\n\n
              First of all let us identify the datafiles on standby database which are out of sync with respect to primary.<\/p>\n\n\n\n
              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,10,11 match on primary and standby, for rest of the  datafiles (1,3,4,6) standby is lagging behind  primary.<\/p>\n\n\n\n
              BOSTON>select file#, checkpoint_change# from v$datafile;\n\n     FILE# CHECKPOINT_CHANGE#\n---------- ------------------\n         1            3717658\n         3            3717658\n         4            3717658\n         5            1910129<\/span>\n         6            3717658\n         7            1910129<\/span>\n         8            3690127<\/span>\n         9            3690127<\/span>\n         10           3690127<\/span>\n         11           3690127<\/span>\n\n10 rows selected.\n\nLONDON>select file#, checkpoint_change# from v$datafile;\n\n     FILE# CHECKPOINT_CHANGE#\n---------- ------------------\n         1            3717619\n         3            3717619\n         4            3717619\n         5            1910129<\/span>\n         6            3717619\n         7            1910129<\/span>\n         8            3690127<\/span>\n         9            3690127<\/span>\n        10            3690127<\/span>\n        11            3690127<\/span>\n\n10 rows selected.<\/pre>\n\n\n\n
              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.<\/p>\n\n\n\n
              LONDON>recover managed standby database cancel;\n\n            shutdown immediate;\n\n            startup mount;<\/pre>\n\n\n\n
              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.<\/p>\n\n\n\n
              The following command creates a compressed multi-section incremental backup on the primary database that is then used to refresh the standby data files. boston<\/b> is the net service name of the primary database that is used to refresh the standby database. The NOREDO<\/b> clause specifies that the archived redo log files must not be applied during recovery.<\/p>\n\n\n\n
              [oracle@host03 ~]$ . oraenv\n\nORACLE_SID = [london] ?\n\n[oracle@host03 ~]$ rman target \/\n\nRMAN> recover database from service boston noredo using compressed backupset section size 100m;\n\nStarting recover at 09-FEB-15\n\nStarting implicit crosscheck backup<\/span> at 09-FEB-15\n\nallocated channel: ORA_DISK_1\nchannel ORA_DISK_1: SID=41 device type=DISK\nCrosschecked 9 objects\nFinished implicit crosscheck backup at 09-FEB-15\n\nStarting implicit crosscheck copy<\/span> at 09-FEB-15\nusing channel ORA_DISK_1\nCrosschecked 2 objects\nFinished implicit crosscheck copy at 09-FEB-15<\/pre>\n\n\n\n
              \u2014 Catalogues all the existing backups and archivelogs available on standby \u2014<\/span><\/p>\n\n\n\n
              searching for all files in the recovery area\n\ncataloging files...\n\ncataloging done\n\nList of Cataloged Files\n\n=======================<\/pre>\n\n\n\n
              \u2014 Backups \u2014<\/span><\/p>\n\n\n\n
              File Name: \/u01\/app\/oracle\/fast_recovery_area\/LONDON\/autobackup\/2015_01_23\/o1_mf_s_869760430_bd492tm3_.bkp\nFile Name: \/u01\/app\/oracle\/fast_recovery_area\/LONDON\/autobackup\/2015_01_23\/o1_mf_s_869760892_bd4b06ws_.bkp\n...\nFile Name: \/u01\/app\/oracle\/fast_recovery_area\/LONDON\/autobackup\/2015_01_22\/o1_mf_s_869676552_bd1qongl_.bkp<\/pre>\n\n\n\n
              \u2014 Archived logs \u2014<\/span><\/p>\n\n\n\n
              File Name: \/u01\/app\/oracle\/fast_recovery_area\/LONDON\/archivelog\/2015_02_06\/o1_mf_1_175_bf919zvx_.arc\nFile Name: \/u01\/app\/oracle\/fast_recovery_area\/LONDON\/archivelog\/2015_02_06\/o1_mf_1_172_bf8pvrhn_.arc\n...\n...\nFile Name: \/u01\/app\/oracle\/fast_recovery_area\/LONDON\/archivelog\/2015_01_21\/o1_mf_1_54_bcyn59o8_.arc\nFile Name: \/u01\/app\/oracle\/fast_recovery_area\/LONDON\/archivelog\/2015_01_21\/o1_mf_1_60_bczt9p7o_.arc<\/pre>\n\n\n\n
              \u2014 Skips all the datafiles (5, 7, 8, 9, 10, 11) whose checkpoint_change# on standby match that of primary are skipped for restore operation \u2014<\/span><\/p>\n\n\n\n
              using channel ORA_DISK_1\nskipping datafile 5<\/b>; already restored to SCN 1910129\nskipping datafile 7<\/b>; already restored to SCN 1910129\nskipping datafile 8<\/b>; already restored to SCN 3690127\nskipping datafile 9<\/b>; already restored to SCN 3690127\nskipping datafile 10<\/b>; already restored to SCN 3690127\nskipping datafile 11<\/b>; already restored to SCN 3690127<\/pre>\n\n\n\n
              \u2014 Restores multi-section compressed backupsets    with section size of 100m of all the data files (1, 3, 4, 6) whose checkpoint_change# on standby is behind  primary  over network. \u2014<\/span><\/p>\n\n\n\n
              channel ORA_DISK_1: starting incremental datafile backup set restore\nchannel ORA_DISK_1: using compressed network backup set from service boston\ndestination for restore of datafile 00001<\/b>: \/u01\/app\/oracle\/oradata\/london\/system01.dbf\nchannel ORA_DISK_1: restoring section 1<\/span> of 9\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:03\nchannel ORA_DISK_1: starting incremental datafile backup set restore\nchannel ORA_DISK_1: using compressed network backup set from service boston\ndestination for restore of datafile 00001: \/u01\/app\/oracle\/oradata\/london\/system01.dbf\nchannel ORA_DISK_1: restoring section 2<\/span> of 9\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:01\nchannel ORA_DISK_1: starting incremental datafile backup set restore\nchannel ORA_DISK_1: using compressed network backup set from service boston\ndestination for restore of datafile 00001: \/u01\/app\/oracle\/oradata\/london\/system01.dbf\n...\n...\nchannel ORA_DISK_1: restoring section 9<\/span> of 9\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:01\nchannel ORA_DISK_1: starting incremental datafile backup set restore\nchannel ORA_DISK_1: using compressed network backup set from service boston\n\ndestination for restore of datafile 00003<\/span>: \/u01\/app\/oracle\/oradata\/london\/sysaux01.dbf\nchannel ORA_DISK_1: restoring section 1<\/b> of 10\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:03\nchannel ORA_DISK_1: starting incremental datafile backup set restore\nchannel ORA_DISK_1: using compressed network backup set from service boston\ndestination for restore of datafile 00003: \/u01\/app\/oracle\/oradata\/london\/sysaux01.dbf\n...\n...\nchannel ORA_DISK_1: restoring section 10<\/b> of 10\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:01\nchannel ORA_DISK_1: starting incremental datafile backup set restore\nchannel ORA_DISK_1: using compressed network backup set from service boston\n\ndestination for restore of datafile 00004<\/span>: \/u01\/app\/oracle\/oradata\/london\/undotbs01.dbf\nchannel ORA_DISK_1: restoring section 1<\/b> of 3\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:01\nchannel ORA_DISK_1: starting incremental datafile backup set restore\nchannel ORA_DISK_1: using compressed network backup set from service boston\n\ndestination for restore of datafile 00004: \/u01\/app\/oracle\/oradata\/london\/undotbs01.dbf\n...\n...\nchannel ORA_DISK_1: restoring section 3<\/b> of 3\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:01\nchannel ORA_DISK_1: starting incremental datafile backup set restore\nchannel ORA_DISK_1: using compressed network backup set from service boston\n\ndestination for restore of datafile 00006<\/span>: \/u01\/app\/oracle\/oradata\/london\/users01.dbf\nchannel ORA_DISK_1: restoring section 1<\/b> of 1\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:01\n\nFinished recover at 09-FEB-15<\/pre>\n\n\n\n
              As soon as standby is recovered, redo transport to far sync (bostonFS) and standby (london) is resumed.<\/p>\n\n\n\n
              BOSTON>select max(sequence#) from v$archived_log;\nMAX(SEQUENCE#)\n--------------\n          197<\/b>\n\nBOSTONFS>select max(sequence#) from v$archived_log;\nMAX(SEQUENCE#)\n--------------\n          197<\/b>\n\nLONDON>select max(sequence#) from v$archived_log;\nMAX(SEQUENCE#)\n--------------\n          197<\/b><\/pre>\n\n\n\n
              The RECOVER \u2026 FROM SERVICE command refreshes the standby data files and rolls them forward 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, we must refresh the standby control file to update the SCN#.<\/p>\n\n\n\n
              Hence place the physical standby database in NOMOUNT mode and restore controlfile to standby by using the control file on the primary database.<\/p>\n\n\n\n
              LONDON>SHUTDOWN IMMEDIATE;\nSTARTUP NOMOUNT;\n\nRMAN> RESTORE STANDBY CONTROLFILE FROM SERVICE boston;\n\nStarting restore at 09-FEB-15\nusing target database control file instead of recovery catalog\nallocated channel: ORA_DISK_1\nchannel ORA_DISK_1: SID=22 device type=DISK\n\nchannel ORA_DISK_1: starting datafile backup set restore\nchannel ORA_DISK_1: using network backup set from service boston\nchannel ORA_DISK_1: restoring control file\nchannel ORA_DISK_1: restore complete, elapsed time: 00:00:07\noutput file name=\/u01\/app\/oracle\/oradata\/london\/control01.ctl\noutput file name=\/u01\/app\/oracle\/fast_recovery_area\/london\/control02.ctl\nFinished restore at 09-FEB-15<\/pre>\n\n\n\n
              Mount the standby database.<\/p>\n\n\n\n
              LONDON>ALTER DATABASE MOUNT;<\/pre>\n\n\n\n
              Now the standby database has been rolled forward successfully as can be verified using DGMGRL.<\/p>\n\n\n\n
              DGMGRL> show configuration;\nConfiguration - drsolution\n\n   Protection Mode: MaxPerformance\n   Databases:\n   boston   - Primary database\n     bostonfs - Far Sync\n       london   - Physical standby database\n       london2  - Logical standby database (disabled)\n     londonfs - Far Sync (inactive)\n\nFast-Start Failover: DISABLED\n\nConfiguration Status:\nSUCCESS<\/pre>\n\n\n\n
              Note<\/b>: If network resources are a constraint, then you can still use the Pre-12c BACKUP INCREMENTAL command to create incremental backups on the primary database, and then use the incremental backups to roll forward the physical standby database.<\/p>\n\n\n\n
              Conclusion:<\/h2>\n\n\n\n
              In case standby database lags behind the primary, it can be rolled forward using incremental backups from primary database. It is a faster alternative to copying archived logs from primary and applying them on standby database. When an archive log gap is unrecoverable  this procedure is a much faster alternative to  rebuilding the standby database. This  used to be a long manual process till 11g. In 12c, datafiles from primary database can be restored over the network as backupset and they can be optionally compressed and encrypted as well.<\/p>\n\n\n\n
              References:<\/b><\/p>\n\n\n\n
              \nhttps:\/\/docs.oracle.com\/database\/121\/BRADV\/rcmadvre.htm#BRADV685\n<\/div><\/figure>\n\n\n\n
              \n    
              FAQs:12c Dataguard : Recover from Service<\/h2>\n\n                        
              1. What is RECOVER FROM SERVICE in Oracle DataGuard?<\/h3>\n            
              \n                
              RECOVER…FROM SERVICE is an Oracle DataGuard command that rolls a physical standby database forward by fetching the missing archived redo logs directly from the primary database (or a registered service name) over the network, rather than requiring the logs to be shipped manually. It is an alternative to a full rebuild when the standby has only fallen partially behind. The command calculates the difference in SCN (System Change Number) between the primary and standby and fetches only the changes needed to bring the standby up to date.<\/p>\n            <\/div>\n                    
              2. When should I use RECOVER FROM SERVICE instead of rebuilding the standby?<\/h3>\n            
              \n                
              Use RECOVER FROM SERVICE when the standby has fallen behind but the divergence is manageable – the primary’s archived logs are still available and the SCN gap is not too large to fetch over the network. Use a full rebuild (duplication from backup) when the standby is severely out of date, the required archived logs are no longer available on the primary, or the standby database has physical corruption that makes it unsuitable as a base for recovery. RECOVER FROM SERVICE is faster for moderate gaps; a full rebuild is more reliable for large or complex divergences.<\/p>\n            <\/div>\n                    
              3. How do I identify which datafiles on the standby are out of sync with the primary?<\/h3>\n            
              \n                
              Query the V$DATAFILE view on both the primary and standby, comparing CHECKPOINT_CHANGE# values. Datafiles on the standby where CHECKPOINT_CHANGE# is lower than on the primary are out of sync. Query: SELECT file#, name, checkpoint_change# FROM v$datafile ORDER BY file#; Run this on both primary and standby and compare. The RECOVER FROM SERVICE command will identify and recover all out-of-sync datafiles automatically.<\/p>\n            <\/div>\n                    
              4. What is the difference between a physical standby and a logical standby in Oracle DataGuard?<\/h3>\n            
              \n                
              A physical standby is a byte-for-byte copy of the primary database, maintained by applying redo log records. It is typically kept in MANAGED RECOVERY MODE (not open for user access, or open READ ONLY with Active DataGuard). A logical standby maintains the same data but potentially in a different physical form – it applies LogMiner-processed SQL to the standby, allowing it to have different indexes, additional objects, and to be fully open for queries. Physical standbys are simpler to manage and are the standard choice for high availability. Logical standbys are used for reporting scenarios requiring full read-write access.<\/p>\n            <\/div>\n            <\/section>\n","protected":false},"excerpt":{"rendered":"
              Roll forward an Oracle 12c DataGuard physical standby database that has fallen behind the primary using the RECOVER…FROM SERVICE command. Covers simulating archived log loss, identifying out-of-sync datafiles, and the recovery procedure.…<\/p>\n","protected":false},"author":316217,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":true,"footnotes":""},"categories":[143533],"tags":[48459,48472,48486,4598,48514],"coauthors":[48555],"class_list":["post-73175","post","type-post","status-publish","format-standard","hentry","category-oracle-databases","tag-oracle-data-guard","tag-physical-standby","tag-recover-command","tag-recovery","tag-standby"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/73175","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/316217"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=73175"}],"version-history":[{"count":4,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/73175\/revisions"}],"predecessor-version":[{"id":109819,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/73175\/revisions\/109819"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=73175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=73175"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=73175"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=73175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}