19C 同步standby Roll Forward 前滚DG 只需要一个命令

APPLIES TO:

Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Cloud Service - Version N/A and later
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Information in this document applies to any platform.

GOAL

NOTE: In the images and/or the document content below, the user information and environment data used represents fictitious data from the
Oracle sample schema(s), Public Documentation delivered with an Oracle database product or other training material.  Any similarity to actual
environments, actual persons, living or dead, is purely coincidental and not intended in any manner.

For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:

Standby Name: SBY180
Primary Name:  PRM180
Directory Name:  /u01/app/oracle and all sub-directories

Note, this procedure is version dependent.  The procedure described in this note is for Oracle 18c and higher. 

For 11g see the following procedure:
11g Steps to perform for Rolling Forward a Physical Standby Database using RMAN Incremental Backup. (Doc ID 836986.1)

For 12.1 and 12.2, see the following procedure:
12c How to Roll Forward a Standby Database Using Recover Database From Service (Doc ID 2850185.1) 

 Typically, when rolling forward a physical standby database using primary incremental backup, multiple steps are required:

1. Identify the Start SCN on Standby for performing incremental backup on primary
2. Perform incremental backup on primary with FROM SCN clause
3. Move the backup-pieces from primary to standby
4. Catalog the backup-piece on Standby
5. Perform recovery on standby using recover database noredo
6. Refresh standby controlfile again from primary

Starting from 12.1, we could use "RECOVER DATABASE FROM SERVICE"command which will automate a few steps like performing incremental backup on primary, transfer the backup-pieces to standby over network and perform recovery on standby. However, we still had to manually refresh the standby controlfile and manually restore newly-added datafiles. These steps required manual efforts and are error prone especially when standby files are physically located in a path different to that of primary.

Starting with 18.1, we can use a single command to refresh the standby with changes made on primary:

RMAN> RECOVER STANDBY DATABASE FROM SERVICE primary_connect_identifier;

This command will internally keep track of standby file locations, refresh standby controlfile from primary, update the new standby controlfile with standby file names, perform incremental backup on primary, transfer the backup-pieces over network to standby and perform recovery on standby

SOLUTION

1. To refresh the standby, ensure that managed recovery is stopped on standby:

SQL> recover managed standby database cancel;

NOTE: If you do not stop managed recovery, you will get RMAN-05150 error during execution:

RMAN> RECOVER STANDBY DATABASE FROM SERVICE PRM180;
RMAN-03090: Starting recover at 03-AUG-18
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/03/2018 12:33:05
RMAN-05150: Managed Recovery Process must be disabled before running RECOVER STANDBY DATABASE.

NOTE: If using dataguard broker, ensure to stop recovery using broker:

DGMGRL> EDIT DATABASE '<standby_db>' SET STATE='APPLY-OFF';

2.If the standby is RAC with more than one instance, make sure only the instance from which recover standby command will be executed is mounted and all other instances are shutdown to avoid RMAN-05157

Starting recover at 22-FEB-21
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/22/2021 15:18:54
RMAN-05157: The database must not be mounted on any other instance for RECOVER STANDBY DATABASE command.

Starting recover at 22-FEB-21
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/22/2021 15:18:54
RMAN-05157: The database must not be mounted on any other instance for RECOVER STANDBY DATABASE command.

3.Ensure that Oracle Net connectivity is established between the physical standby database and the primary database by adding an entry corresponding to the primary database in the tnsnames.ora file of the physical standby database. In below example, PRM180 is the connect identifier for primary.

4. Connect RMAN to standby as target and run "RECOVER STANDBY DATABASE FROM SERVICE" command. Find below an example run for the command:

$ export ORACLE_SID=SBY180
$ rman target / 

RMAN> RECOVER STANDBY DATABASE FROM SERVICE PRM180;

RMAN-03090: Starting recover at 03-AUG-18
RMAN-06009: using target database control file instead of recovery catalog
RMAN-06196: Oracle instance started

Total System Global Area 671086904 bytes

Fixed Size 8661304 bytes
Variable Size 188743680 bytes
Database Buffers 465567744 bytes
Redo Buffers 8114176 bytes

RMAN-08161: contents of Memory Script:
{
restore standby controlfile from service 'PRM180';
alter database mount standby database;
}
RMAN-08162: executing Memory Script

RMAN-03090: Starting restore at 03-AUG-18
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=141 device type=DISK

RMAN-08016: channel ORA_DISK_1: starting datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08021: channel ORA_DISK_1: restoring control file
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
RMAN-08505: output file name=/u01/app/oracle/oradata/SBY180/control01.ctl
RMAN-03091: Finished restore at 03-AUG-18

RMAN-08031: released channel: ORA_DISK_1
RMAN-06986: Statement processed
RMAN-06958: Executing: alter system set standby_file_management=manual

RMAN-08161: contents of Memory Script:
{
recover database from service 'PRM180';
}
RMAN-08162: executing Memory Script

RMAN-03090: Starting recover at 03-AUG-18
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=149 device type=DISK
RMAN-06179: datafile 4 not processed because file is read-only
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00001: /u01/app/oracle/oradata/SBY180/system01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00002: /u01/app/oracle/oradata/SBY180/sysaux01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00003: /u01/app/oracle/oradata/SBY180/undotbs01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:03

RMAN-08054: starting media recovery

RMAN-08181: media recovery complete, elapsed time: 00:00:00
RMAN-03091: Finished recover at 03-AUG-18
RMAN-06958: Executing: alter system set standby_file_management=auto
RMAN-03091: Finished recover at 03-AUG-18

NOTE: 

If you face errors about SBT channels during the process, ensure that below is set on Primary (since the controlfile is automatically refreshed from Primary)

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT CLEAR; 

If your disk channels on primary are configured with CONNECT clause, then, the disk channel allocation won't work on standby. In that case, we need to clear the configuration of DISK channels also on Primary:

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;

5. After the command is successfully completed, we can clear the online / standby redo logs before starting MRP. 

SQL> begin
for log_cur in ( select group# group_no from v$log )
loop
execute immediate 'alter database clear logfile group '||log_cur.group_no;
end loop;
end;
/

SQL> begin
for log_cur in ( select group# group_no from v$standby_log )
loop
execute immediate 'alter database clear logfile group '||log_cur.group_no;
end loop;
end;