Case Study

1. 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 DML does not generte data for 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.

* To avoid these problems, Oracle recommends that you always specify the FORCE LOGGING clause in the CREATE DATABASE or ALTER DATABASE statements.

* To recover after the NOLOGGING clause is specified, you need to copy the data file that contains the missing redo data from the primary site to the physical standby site.

2. Recovering From a Network Failure

we must prevent the primary database from stalling using setting LOG_ARCHIVE_DEST_STATE_2=DEFER;

When the network problem is resolved, you can enable the archive destination again.

On the primary database, archive the current online redo log file:

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

When the network is back up again, log apply services can detect and resolve the archive gaps automatically when the physical standby database resumes Redo Apply.

3. Managing Archive Gaps on Physical Standby We should verify that the last sequence# received and the last sequence# applied to the standby database. If a gap between received and applied, then we copy gap archive logs to physical standby database and register on physical standby database. ALTER DATABASE REGISTER LOGFILE

Using a Physical Standby Database for Read/Write Testing and Reporting We can temporarily open a physical standby database for read/write, reporting. How it’s work:

We must implement Flash back and create a restore point on the Standby database and open the standby database for read write operation.

After completion of the read write operation, we flash back the standby database to a restore point.

When the database is flashed back, Data automatically synchronizes with the primary database, without the need to re-create the physical standby database from a backup copy of the primary database.

While the database is activated, it is not receiving redo data from the primary database and cannot provide disaster protection. It is recommended that there be at least two physical standby databases participating in the configuration so that the primary database remains protected against data loss.

5. Using RMAN Incremental Backups to Roll Forward a Physical Standby Database We can use RMAN incremental backups to synchronize a physical standby database with the primary database. Using the RMAN BACKUP INCREMENTAL FROM SCN command, we can create a backup on the primary database that starts at the standby database’s current SCN, which can then be used to roll the standby database forward in time.