Recovering After the NOLOGGING Clause Is Specified In some SQL statements, the user has the option of specifying

the NOLOGGING clause, which indicates that the database operation is not logged in the online redo log file. This can result in log application or data access errors at the standby site and manual recovery might be required to resume applying log files. Note: To avoid these problems, Oracle recommends that you always specify the FORCE LOGGING clause in the CREATE DATABASE or ALTER DATABASE statements. Workshop: Step for Physical Standby Database Step 1 Create a Table in NOLOGGING mode on Primary Database SQL> create table anup nologging as select * from emp; Table created. Step 2 Switch log on Primary Database Step 3 Cancel recovery in Standby Database. SQL> alter database recover managed standby database cancel; Step 4 Put Standby database in Read Mode. SQL> alter database open read only; Step 5 Submit bellow select statement on Standby Database. SQL> select * from scott.anup; select * from scott.anup * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 4, block # 436) ORA-01110: data file 4: '/DB/PROD/users01.dbf' ORA-26040: Data block was loaded using the NOLOGGING option To recover after the NOLOGGING clause is specified, you need to copy the datafile that contains the missing redo data from the primary site to the physical standby site. Action: Step 1 Determine which datafiles should be copied. 1. Query the primary database: SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE; NAME UNRECOVERABLE_CHANGE# /DB/PROD/system01.dbf 0 /DB/PROD/undotbs01.dbf 0 /DB/PROD/sysaux01.dbf 0 /DB/PROD/users01.dbf 687862 /DB/PROD/example01.dbf 0 /DB/PROD/dims01.dbf 0 6 rows selected.

2. Query the standby database: SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE; NAME UNRECOVERABLE_CHANGE# /DB/PROD/system01.dbf 0 /DB/PROD/undotbs01.dbf 0 /DB/PROD/sysaux01.dbf 0 /DB/PROD/users01.dbf 0 /DB/PROD/example01.dbf 0 /DB/PROD/dims01.dbf 0 6 rows selected. 3. Compare the query results of the primary and standby databases. Compare the value of the UNRECOVERABLE_CHANGE# column in both query results. If the value of the UNRECOVERABLE_CHANGE# column in the primary database is greater than the same column in the standby database, then the datafile needs to be copied from the primary site to the standby site. In this example, the value of the UNRECOVERABLE_CHANGE# in the primary database for the users01.dbf datafile is greater, so you need to copy the users01.dbf datafile to the standby site. Step 2 On the primary site, back up the datafile you need to copy to the standby site. Issue the following SQL statements: SQL> ALTER TABLESPACE users BEGIN BACKUP; SQL> EXIT; % cp users01.dbf /backup SQL> ALTER TABLESPACE system END BACKUP; Step 3 Copy the datafile to the standby database. Copy the datafile that contains the missing redo data from the primary site to location on the physical standby site where files related to recovery are stored. Step 4 On the standby database, restart Redo Apply. Issue the following SQL statement: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; You might get the following error messages (possibly in the alert log) when you try to restart Redo Apply: ORA-00308: cannot open archived log 'standby1' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3 ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf' If you get the ORA-00308 error and Redo Apply does not terminate automatically, you can cancel

recovery by issuing the following statement from another terminal window: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; These error messages are returned when one or more log files in the archive gap have not been successfully applied. If you receive these errors, manually resolve the gaps, and repeat Step 4. Workshop: Step for Logical Standby Database Typically, you use table instantiation to re-create a table after an unrecoverable operation. You can also use the procedure to enable SQL Apply on a table that was formerly skipped. Step 1 Stop SQL Apply: SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; Step 2 Ensure no operations are being skipped for the table in question by querying the DBA_LOGSTDBY_SKIP view: SQL> SELECT * FROM DBA_LOGSTDBY_SKIP; Because you already have skip rules associated with the table that you want to re-create on the logical standby database, you must first delete those rules. You can accomplish that by calling the DBMS_LOGSTDBY.UNSKIP procedure. For example: SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', schema_name => 'HR', object_name => 'EMPLOYEES'); SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'SCHEMA_DDL', schema_name => 'HR', object_name => 'EMPLOYEES'); Step 3 Re-create the table HR.EMPLOYEES with all its data in the logical standby database by using the DBMS_LOGSTDBY.INSTANTIATE_TABLE procedure. For example: SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(shema_name => 'HR', object-+_name => 'EMPLOYEES', dblink => 'BOSTON'); Step 4 Start SQL Apply: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; To ensure a consistent view across the newly instantiated table and the rest of the database, wait for SQL Apply to catch up with the primary database before querying this table. You can do this by performing the following steps:

1. On the primary database, determine the current SCN by querying the V$DATABASE view: SQL> SELECT CURRENT_SCN FROM V$DATABASE@BOSTON; CURRENT_SCN --------------------345162788 2. Make sure SQL Apply has applied all transactions committed before the CURRENT_SCN returned in the previous query: SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS; APPLIED_SCN -------------------------345161345 When the APPLIED_SCN returned in this query is greater than the CURRENT_SCN returned in the first query, it is safe to query the newly re-created tab