As a prerequisite for this exercise, first put the primary database in the no-force logging mode using the ALTER DATABASE NO FORCE LOGGING
statement. Then perform some DML operations in the primary database using the NOLOGGING
clause so that we can fix the issue in the standby database with the following steps:
NOLOGGING
changes:SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN > 0; FILE# FIRST_NONLOGGED_SCN ---------- ------------------- 4 20606544
OFFLINE
state in the standby database. For this purpose, stop Redo Apply in the standby database, execute the ALTER DATABASE DATAFILE ... OFFLINE
statement, and start Redo Apply again:SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> ALTER DATABASE DATAFILE 4 OFFLINE FOR DROP; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
FROM SCN
keyword. SCN values will be the output of the execution of the queries in the first step. Connect to the primary database as an RMAN target and execute the following RMAN BACKUP
statements:RMAN> BACKUP INCREMENTAL FROM SCN 20606544 DATAFILE 4 FORMAT '/data/Dbf_inc_%U' TAG 'FOR STANDBY';
scp /data/Dbf_inc_* standbyhost:/data/
CATALOG
command:RMAN> CATALOG START WITH '/data/Dbf_inc_';
ONLINE
state, stop Redo Apply on the standby database, and run the ALTER DATABASE DATAFILE ... ONLINE
statement:SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> ALTER DATABASE DATAFILE 4 ONLINE;
RMAN> RECOVER DATAFILE 4 NOREDO;
NOLOGGING
changes:SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN > 0;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
We've successfully recovered the standby database that didn't include the NOLOGGING
changes performed in the primary database. We used the datafile incremental backup method because the number of affected datafiles was small. For a high number of affected datafiles, the method explained in the next section will be more suitable.