FIRST_NONLOGGED_SCN
column of the V$DATAFILE
view in the standby database:SQL> SELECT MIN(FIRST_NONLOGGED_SCN) FROM V$DATAFILE WHERE FIRST_NONLOGGED_SCN>0; MIN(FIRST_NONLOGGED_SCN) ------------------------ 20606544
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
FROM SCN
keyword. The SCN value will be the output of the execution of the query in the first step. Connect to the primary database as the RMAN target and execute the following RMAN BACKUP
statement:RMAN> BACKUP INCREMENTAL FROM SCN 20606344 DATABASE FORMAT '/data/DB_Inc_%U' TAG 'FOR STANDBY';
scp /data/DB_Inc_* standbyhost:/data/
CATALOG
command:RMAN> CATALOG START WITH '/data/DB_Inc_';
RMAN> RECOVER DATABASE 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;
If the state of a tablespace that includes the affected datafiles is READ ONLY
, those files will not be backed up with the RMAN BACKUP
command. We need to put these tablespaces in the read-write mode before the backup operation. Change the state of a tablespace with the following statements:
SQL> ALTER TABLESPACE <TABLESPACE_NAME> READ WRITE; SQL> ALTER TABLESPACE <TABLESPACE_NAME> READ ONLY;
FORCE LOGGING
mode:SQL> ALTER DATABASE FORCE LOGGING;
We've fixed the adverse affect of executing the NOLOGGING
operation in the primary database in a Data Guard configuration. If this problem is not fixed in the standby database, we'll face the ORA-26040
error when we attempt to open the standby database as read-only or read-write.