The procedures in these sections describe the fastest ways to convert a failed primary into either a physical or logical standby. Managed recovery attempts to fetch all such blocks shortly after they are first created and continues attempting to fix them until it succeeds. With user-managed recovery, you can first restore the database manually. During this step, local copies of log files that pose a risk for data divergence are deleted from the local database. It is possible that the RMAN RECOVER command may not be able to recover all the nonlogged blocks. Determine the flashback SCN and the recovery SCN. You can monitor the progress of an on-going block comparison operation by querying the V$SESSION_LONGOPS view. If the failed primary database was isolated from the standby, it could have divergent archive logs that are not consistent with the current primary database. If the value of CURRENT_SCN is less than the value of the resetlogs_change# - 2, skip to Step 4. Use the RMAN DUPLICATE FOR STANDBY command to copy the data files, archived redo log files and standby control file in the backup set to the standby database's storage area. If the backup set is on disk, the backup pieces must be readable by the standby instance, either by making their primary path names available through Network File Storage (NFS), or by copying them to the standby system and using RMAN CATALOG BACKUPPIECE command to catalog the backup pieces before restoring them. Before the new standby database was created, the new primary database probably stopped transmitting redo to the remote destination. These steps demonstrate how to configure a logical standby database to support a new primary database that was a physical standby database before it assumed the primary role. For a detailed description of the steps involved in this process, see My Oracle Support note 1124165.1 at http://support.oracle.com. When a primary lost-write error is detected on the standby, one or more block error messages similar to the following for each stale block are printed in the alert file of the standby database: The alert file then shows that an ORA-00752 error is raised on the standby database and the managed recovery is cancelled: The standby database is then recovered to a consistent state, without any corruption to its data files caused by this error, at the SCN printed in the alert file: This last message may appear significantly later in the alert file and it may have a lower SCN than the block error messages. You can see the current logging mode in the V$DATABASE.FORCE_LOGGING column (for CDBs) or the DBA_PDBS.FORCE_LOGGING column (for PDBs). Start Redo Apply on the new physical standby database, as follows: Once the failed primary database is restored and is running in the standby role, you can optionally perform a switchover to transition the databases to their original (pre-failure) roles. Some SQL statements allow you to specify a NOLOGGING clause so that the operation is not logged in the online redo log file. If SQL Apply detects the occurrence of a resetlogs operation at the primary database, it automatically mines the correct branch of redo, if it is possible to do so without having to flashback the logical standby database. On the SAT database, issue the following statement: If the ORA-16109 message is returned and the 'LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.' You can continue to use your physical standby database with minimal disruption while performing character set conversion of a primary database. Depending on the size of the database and the number of logs needing to be archived, it could take some time before a status of NONE is returned. These steps bring the old primary database back into the Oracle Data Guard configuration as a new logical standby database without having to formally instantiate it from the new primary database. On the standby database, obtain the current SCN with the following query: To start Redo Apply on the physical standby database, issue the following statement: On the primary database, use the following query to obtain the value of the system change number (SCN) that is 2 SCNs before the. It does this by determining if the existing ranges are complete and if not, it scans the necessary data files to identify any invalid blocks and make sure they are captured by an entry in V$NONLOGGED_BLOCK. These are the steps required on a logical standby database after the primary database has failed over to another standby database. Issue the following SQL statements on the new primary database: On the new standby database, you may also need to change the LOG_ARCHIVE_DEST_n initialization parameters so that redo transport services do not transmit redo data to other databases. See Oracle Database Reference for more information about the V$DATAFILE view. In actuality, a redo record is still written to the online redo log file, but there is no data associated with the record. Steps to Failover to a Physical Standby After Lost-Writes Are Detected on the Primary. To convert a failed primary database, Oracle recommends that you enable the Flashback Database feature on the primary and follow one of these procedures, as appropriate. The following is an example of an alert log entry for an execution of the RECOVER command which left some blocks unrecovered: In this case, the command was run on a standby and the primary did not send any blocks but instead reported the following Oracle error: . Issue the following SQL statements to flash back the logical standby database to the specified SCN, and open the logical standby database with the.

Perform the following tasks to create the standby database: If the standby database is going to use Oracle ASM, create an Oracle ASM instance if one does not already exist on the standby database system. See Oracle Database Backup and Recovery User's Guide for more information. Recover the nonlogged blocks by connecting RMAN to the standby and issue the following command: If the presence of unrecoverable blocks is only found after a switchover, then you can use these same two steps, but the primary database must be just mounted ( not open) and, RMAN must be connected to the primary. On the SAT database, issue the following statement to configure the FAL_SERVER parameter to enable automatic recovery of log files. In this step, the FLASHBACK_SCN value for PRIMARY_SCN is from Step 1. This step can be skipped if both the primary and standby database roles were set up with the VALID_FOR attribute in one server parameter file (SPFILE). If you performed unrecoverable operations on your primary database, then you need to determine if a new backup operation is required. In this situation, when the DBCOMP procedure is executed from one of the standby databases (for example, dgmainb), the specified data files are compared only between the primary and that particular standby database. Once the failed primary database is restored and is running in the standby role, you can optionally perform a switchover to transition the databases to their original (pre-failure) roles. Blocks corrupted due to conventional nonlogged operations must use the following procedure. Depending on whether you have a logical standby or physical standby, you can avoid these errors by doing the following: Logical standbys specify the FORCE LOGGING clause in the CREATE DATABASE or ALTER DATABASE statements. You must have already enabled Flashback Database on the original primary database before the failover. Close the standby database, if it is still open: Flashback the pluggable database on the standby: The SCN for the FLASHBACK PLUGGABLE DATABASE command is 1437260, not 1437261 as in the following example, because TO SCN and UNTIL SCN have different semantics. After you perform a PDB PITR or PDB Flashback on a primary, you can either restore the PDB or flashback the PDB on the standby to let the standby follow the primary. When you create standby databases, there are additional steps that must be performed if the primary database uses Oracle Managed Files (OMF) or Oracle Automatic Storage Management (Oracle ASM). The RMAN utility is able to use a partial file name to retrieve the files from the correct location. You can use the PL/SQL procedure, DBMS_DBCOMP.DBCOMP, to detect lost writes and also to detect inconsistencies between a primary database and physical standby databases. The following sections describe: Flashing Back a Failed Primary Database into a Physical Standby Database, Flashing Back a Failed Primary Database into a Logical Standby Database. You can do this by using the DBMS_LOGSTDBY.SKIP procedure. Maintenance and future role transitions are simplified if the same disk group names are used for both the primary and standby databases. See "Performing a Switchover to a Physical Standby Database" for more information. For example: A value of NONE must be returned before you attempt to reinstate an old primary database. Such a need can arise when configuring a logical standby database with a new primary database after a failover. The steps to run these procedures are interspersed with the steps performed by the Database Migration Assistant for Unicode (DMU) or other appropriate character set migration tool. Once you have determined the known SCN at the primary (APPLIED_SCN), issue the following query to determine the corresponding SCN at the logical standby database, to use for the flashback operation: Issue the following SQL statements to flash back the logical standby database to the specified SCN, and open the logical standby database with the RESETLOGS option: Issue the following query to confirm SQL Apply has applied less than or up to the, Determine the SCN before the RESETLOGS operation occurred. After you successfully complete these steps, continue with the steps in Verify the Physical Standby Database Is Performing Properly, to verify the configuration of the physical standby database. In this situation, when the DBCOMP procedure is executed from the primary database, the specified data files are compared block by block between the primary and every physical standby database. These steps bring the old primary database back into the Oracle Data Guard configuration as a physical standby database. Flashing Back a Logical Standby Database to a Specific Applied SCN, Oracle Data Guard Broker for information about automatic reinstatement of the failed primary database as a new standby database (as an alternative to using Flashback Database). If OMF parameters are set on the standby, then new files on that standby are always created as OMF, regardless of how they were created on the primary. If only offline data files are to be validated or recovered then the database to which they belong can be open at the time the RMAN command is run. Perform the following tasks to prepare for standby database creation: Enable forced logging on the primary database. Configure Oracle Net, as required, to allow connections to the standby database. However, when managed recovery is running on that standby as part of an Active Data Guard configuration, it automatically fetches a replacement block from the primary. Because the primary database is neither mounted nor open, theDBCOMP procedure cannot find an appropriate pair of primary and physical standby databases to compare. If you have purchased a license for the Oracle Active Data Guard option and would like to operate your physical standby database in active query mode, skip this step. If the ORA-16109 message is returned and the LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required warning is written in the alert.log file, perform the following steps: On the SAT database, issue the following statements to start SQL Apply: This statement must always be issued without the real-time apply option enabled. When you either fail over to the physical standby database, or open the standby database for read-only access, and attempt to read the range of blocks that are marked as UNRECOVERABLE, you see error messages similar to the following: When you use STANDBY NOLOGGING FOR LOAD PERFORMANCE mode it is still possible for a query executed on a physical standby to report a corrupt block due to a nologging operation. Performing a backup immediately is a necessary safety measure, because you cannot recover changes made after the failover without a complete backup copy of the database. Whether you are using a current control file or a backup control file, you must specify the USING BACKUP CONTROLFILE clause to allow you to point to the archive logs being restored. The reasons that this might happen are detailed in the alert log of the database from which the RMAN command was executed. On the new primary database, issue the following query to determine the SCN at which the old standby database became the new primary database: Shut down the old primary database (if necessary), mount it, and flash it back to the value for STANDBY_BECAME_PRIMARY_SCN that was determined in the previous step. The RMAN command VALIDATE NONLOGGED BLOCK can be used to bring the entries in V$NONLOGGED_BLOCK back into synchronization with the data files. Restore the database with a backup taken before the old primary had reached the SCN at which the standby became the new primary (standby_became_primary_scn). If the SCN of the block on the primary database is lower than the SCN on the standby database, then there was a lost-write error on the primary database. This may mean that the block sent to the standby is too old to replace the unrecoverable block on the standby. Issue the following query, looking for a value of NONE to be returned. Example 15-1 Primary and All Standbys Are Mounted or Open and DBCOMP Is Executed From the Primary. Set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO. During this step, local copies of log files which pose a risk for data divergence are deleted from the local database. Oracle recommends that you leverage the current control file. During the execution of these preparatory steps the Oracle Data Guard configuration can operate unchanged and no extra steps are required to maintain the physical standby. Example 15-2 Primary and All Standbys Are Mounted or Open and DBCOMP Is Executed From a Standby. Be aware that a physical standby created using the backup taken from the new primary has the same data files as the old standby. An ORA error message is not returned, but a message similar to the following is printed out in the corresponding output file: Remote database is not in the primary role. This automatic recovery applies only to corrupt blocks caused by redo generated with the STANDBY NOLOGGING FOR LOAD PERFORMANCE mode enabled. To perform this operation, connect only to the standby database, as shown in the following example: Oracle Automatic Storage Management Administrator's Guide, Performing a Switchover to a Physical Standby Database, Adding or Re-Creating Tables On a Logical Standby Database, Verify the Physical Standby Database Is Performing Properly.