To enable real-time apply on the logical standby database, wait for the above statement to complete successfully, and then issue the following statements: After a failover occurs, the original primary database can no longer participate in the Oracle Data Guard configuration until it is repaired and established as a standby database in the new configuration. An optional step is to recreate the failed primary as a physical standby. However, not all ORA-600 [3020] errors are due to lost writes at the primary. The FIRST_NONLOGGED_SCN column in the V$DATAFILE view can still be used to see that there is at least one invalid block in a data file even when there are no V$NONLOGGED_BLOCK entries for a data file. 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).
The standby database is now ready to receive and apply redo from the primary database. Typically, a backup taken a couple of hours before the failover would be old enough. Maintenance and future role transitions are simplified if the same disk group names are used for both the primary and standby databases. See Oracle Database Reference for more information about the V$DATAFILE view.
Otherwise the new primary database has not completed the work required to enable support for logical standby databases. 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. The UNTIL SCN syntax allows RMAN to automatically choose a suitable backup to restore from. See Oracle Database Backup and Recovery User's Guide for more information. These are the steps required on a logical standby database after the primary database has failed over to another standby 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. One of the benefits of a standby database is that Flashback Database can be performed on the standby database without affecting the primary database service. The RMAN utility is able to use a partial file name to retrieve the files from the correct location. 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). The most common reason is that a block has been modified recently at the primary and not yet written to its corresponding data file. Otherwise, SQL Apply stops with an error ORA-1346: LogMiner processed redo beyond specified reset log scn. This is done by comparing SCNs of blocks stored in the redo log on the primary database to SCNs of blocks on the physical standby database. Such a need can arise when configuring a logical standby database with a new primary database after a failover. For those standby databases that are neither mounted nor open, no action is taken. 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. Start Redo Apply on the new physical standby database: Redo Apply automatically stops each time it encounters a redo record that is generated as the result of a role transition, so Redo Apply needs to be restarted one or more times until it has applied beyond the SCN at which the new primary database became the primary database. In this case, flashing back the database is unnecessary because apply services do not stop upon reaching the OPEN RESETLOGS statement in the redo data. Perform point-in-time recovery to RECOVERY_SCN +1 in SQL*Plus. 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. Turn off flashback database, if it is enabled (necessary for the USING BACKUP CONTROLFILE clause). 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. Example 15-3 Primary Is Mounted or Open, But Not All Standbys Are, and DBCOMP is Executed From the Primary. 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. 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 query on the standby database: If one or more rows are returned, it confirms that there are registered logfiles from the primary's new branch. The next time media recovery is run, the stale entries are removed and any newly invalidated blocks are recorded but any prior invalid blocks do not have entries in V$NONLOGGED_BLOCK. 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 following is an example of the messages that may appear in the alert log: Before media recovery on the standby can continue any further, you must restore all data files for that PDB. 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. 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. However, there are times when the information is not complete. 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. 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. Start up the database in restricted mode to protect it from rogue transactions until the GUARD ALL command can be issued after the database has been opened.
If the primary database is configured to use OMF, then Oracle recommends that the standby database be configured to use OMF, too. Example 15-4 Primary Is Mounted or Open, But Not All Standbys Are, and DBCOMP is Executed From a Standby. 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. You must have already enabled Flashback Database on the original primary database before the failover. The RMAN RECOVER NONLOGGED BLOCK command can be used to recover blocks that belong to a set of data files or a set of tablespaces or just a single pluggable database (PDB) as well as the multitenant container database (CDB). You can use the following RMAN command to delete the relevant archive logs from the fast recovery area: On the new primary database, issue the following query to determine the minimum set of log files that must be copied to the failed primary database before recovering from a backup: Retrieve the required standby logs, copy the backup set to the new standby and restore it to the new standby fast recovery area. 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. In actuality, a redo record is still written to the online redo log file, but there is no data associated with the record.
Configure redo transport authentication as described in Configure Redo Transport Authentication. Example 15-6 Primary Is Mounted or Open, But No Standbys Are Mounted or Open. To convert the database to a physical standby database, issue the following statement on the old primary database: To start transporting redo to the new physical standby database, perform the following steps on the new primary database: Issue the following query to see the current state of the archive destinations: Perform a log switch to ensure the standby database begins receiving redo data from the new primary database, and verify it was sent successfully. This is an important step in order for the old primary to become a new standby following the new primary. This procedure requires that the COMPATIBLE initialization parameter of the old primary be set to at least 11.0.0. If this step is not done, the old primary may recover to an incorrect database branch. You can do this by using the DBMS_LOGSTDBY.SKIP procedure. To ensure these divergent archive logs are never applied, they must be deleted from backups and the fast recovery area. Other standby databases are not considered. 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. Whenever managed recovery is started, it again begins fixing any outstanding blocks from earlier recovery sessions. All data at or after the SCN printed in the block error messages is lost. Each of them can be adapted to your specific environment. An examination of the alert logs would reveal that the primary had performed FLASHBACK DATABASE and OPEN RESETLOGS commands, but the standby had not been flashed back. Oracle Database Backup and Recovery User's Guide for more information about performing point-in-time recovery of PDBs. These steps bring the old primary database back into the Oracle Data Guard configuration as a physical standby database. However, if Flashback Database was not enabled on the failed primary, you can still convert the failed primary into either a physical or logical standby using a local backup of the failed primary, as described in the following topics: Converting a Failed Primary into a Physical Standby Using RMAN Backups, Converting a Failed Primary into a Logical Standby Using RMAN Backups. Configure Oracle Net, as required, to allow connections to the standby database. As a result of the failover, the original primary database can no longer participate in the Oracle Data Guard configuration, and all other standby databases now receive and apply redo data from the new primary database.
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). The character set migration process consists of preparatory steps such as scanning for possible issues and identifying methods to solve them. If an error occurrs on the primary database in an Oracle Data Guard configuration in which the standby database is using real-time apply, then the same error is applied on the standby database. Example 15-2 Primary and All Standbys Are Mounted or Open and DBCOMP Is Executed From a Standby. This may mean that the block sent to the standby is too old to replace the unrecoverable block on the standby. Any new lost writes that happen on either the primary or the standby are detected. 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. These steps describe a simple approach that recovers all nonlogged blocks. After the data files have been restored at the standby, restart MRP to continue applying the redo logs. warning is written in the alert.log, perform the following steps: Flash back the database to the SCN as stated in the warning and then.
(You cannot use flashback database or the Oracle Data Guard broker to reinstantiate the old primary database in this situation.) 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).
On the SAT database, issue the following statement to start SQL Apply: These steps demonstrate how to configure a logical standby database to support a new primary database that was a logical standby database before it assumed the primary role. This means the standby would now be on an orphaned branch of redo and therefore the primary could not supply data blocks that would be known to be the correct version. Call the PREPARE_FOR_NEW_PRIMARY routine to verify that the logical standby database is capable of serving as a standby database to the new primary database. After the preparatory steps are completed, the actual conversion is performed which may involve changes to both system data (metadata) and user data. Ensure the new primary database is ready to support logical standby databases. 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. To restart redo transport services, perform the following steps on the new primary database: Perform a log switch to ensure the standby database begins receiving redo data from the new primary database, and verify it was sent successfully.
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). For example, suppose that you perform the following query: The generated output file is BlockCompare_dgmain_1. Use the backup to restore the data files of the failed primary database. 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. These scenarios present different situations you might encounter while administering your Oracle Data Guard configuration. To create a logical standby database, continue with the standby database creation process described in Creating a Logical Standby Database , but with the following modifications: After you successfully complete these steps, continue with the steps in Open the Logical Standby Database to start, recover, and verify the logical standby database. If flashback is enabled on the standby, you can flashback the PDB on the standby and then restart standby managed recovery. 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. 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 VALIDATE NONLOGGED BLOCK command has the same options as the RECOVER NONLOGGED BLOCK command to validate just a set of data files or a set of tablespaces or a PDB, as well as the CDB. See "Performing a Switchover to a Physical Standby Database" for more information. Oracle Database Backup and Recovery User's Guide for more information about enabling lost-write detection. 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.
In the following example situations, assume that there is a primary database with a unique name of dgmain, and that physical standby databases are named dgmainb, dgmainc, dgmaind, and so on. Configuring Logical Standby Databases After a Failover, Converting a Failed Primary Into a Standby Database Using Flashback Database, Using Flashback Database After Issuing an Open Resetlogs Statement, Recovering After the NOLOGGING Clause Is Specified, Creating a Standby Database That Uses OMF or Oracle ASM, Recovering From Lost-Write Errors on a Primary Database, Using the DBCOMP Procedure to Detect Lost Writes and Other Inconsistencies, Converting a Failed Primary into a Standby Database Using RMAN Backups, Changing the Character Set of a Primary Without Re-Creating Physical Standbys, Actions Needed On a Standby After a PDB PITR or PDB Flashback On a Primary. (If Flashback Database is not enabled, you need to re-create the standby database, as described in Creating a Physical Standby Database and Creating a Logical Standby Database , after the point-in-time recovery was performed on the primary database.). See Performing Recovery When Flashback is Not Enabled below. To ensure these divergent archive logs are never applied, they must be deleted from backups and the fast recovery area. In this section, it is assumed that SQL Apply has already stopped with such an error. On the SAT database, issue the following statement to configure the FAL_SERVER parameter to enable automatic recovery of log files. These steps describe how to convert a failed primary into a physical standby by using RMAN backups. If flashback in not enabled on the standby, then recovery can be done from a backup taken at a time prior to the point-in-time the PDB was recovered on the primary. Issue the following SQL statements to flash back the logical standby database to the specified SCN, and open the logical standby database with the. 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. Oracle Database Backup and Recovery User's Guide. Issue the following SQL statement on the standby database to convert it to a primary: Back up the new primary. Typically this is after upgrading from a release prior to Oracle Database 12c Release 1 (12.1) or after restoring an operating system backup of a data file. In this scenario, SAT is the logical standby database and NYC is the primary database. Therefore, any undetected lost writes that the old standby had before it was activated are not detected by the new standby, since the new standby compares the same blocks. For example: A value of NONE must be returned before you attempt to reinstate an old primary database. Because no appropriate pair of primary and physical standby databases are found, a message is printed out in the corresponding output file, but no ORA error is returned. (Managed recovery is started with the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT statement.) Perform the following tasks to prepare for standby database creation: Enable forced logging on the primary database.
If the primary database uses OMF files, use RMAN to update the standby database control file to use the new OMF files created on the standby database. Flashing back a database to a specific point in time is a straightforward task, however on a logical standby database, you may want to flash back to a time just before a known transaction was committed. With either method, a PDB that has undergone PDB PITR or flashback on the primary cannot be opened on a standby until it has caught up with the primary. The following is a sample use of the RMAN BACKUP command: The following is a sample use of the RMAN RESTORE command: Restore a backup of all the original primary's data files and recover to RECOVERY_SCN + 1. See Performing Recovery When Flashback is Enabled below. On the NYC database, ensure the following query returns a value of NONE. This automatic recovery applies only to corrupt blocks caused by redo generated with the STANDBY NOLOGGING FOR LOAD PERFORMANCE mode enabled. Because lost-write errors are detected only when a block is read into the cache by a primary and the corresponding redo is later compared to the block on the standby, there may be undetected stale blocks on both the primary and the standby that have not yet been read and verified. 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. These stale blocks do not affect operation of the current database because until those blocks are read, all blocks that have been used up to the SCN of the currently applied redo on the standby to do queries or updates were verified by the standby. Start the standby database instance without mounting the control file. Determine the flashback SCN and the recovery SCN.
These steps describe how to avoid re-creating a physical standby database after you issue the OPEN RESETLOGS statement on the primary database. The only way to correct the problem then is to convert the old primary again.
Set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO. After a failover has occurred, a logical standby database cannot act as a standby database for the new primary database until it has applied the final redo from the original primary database. You can continue to use your physical standby database with minimal disruption while performing character set conversion of a primary database. To resolve this, issue the RECOVER command again at a later time after the block has been written out to the data file. 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. To do this, you can use the Flashback Database feature to recover the failed primary database to a point in time before the failover occurred, and then convert it into a physical or logical standby database in the new configuration. Before the new standby database was created, the new primary database probably stopped transmitting redo to the remote destination. For a detailed description of the steps involved in this process, see My Oracle Support note 1124165.1 at http://support.oracle.com. Otherwise, the recovery process could attempt to access online redo logs instead of the logs retrieved in Step 3. When a PDB PITR or PDB flashback is performed on the primary, and redo for the start of the operation is encountered for the first time, the MRP at the standby terminates with error ORA-39874, followed by the supplemental error ORA-39873.
During media recovery in an Oracle Data Guard configuration, a physical standby database can be used to detect lost-write data corruption errors on the primary database. When the redo is applied to the physical standby database, a portion of the data file is marked as being unrecoverable. For example, on the primary database, use the following query to obtain the value of the system change number (SCN) that is 2 SCNs before the. On the SAT database, issue the following statement to configure the FAL_SERVER parameter to enable automatic recover of log files: Call the PREPARE_FOR_NEW_PRIMARY routine to verify the logical standby database is capable of being a standby to the new primary. The view V$NONLOGGED_BLOCK usually lists the ranges of known invalid blocks for each data file and the entries are maintained as part of media recovery. For example, suppose that you perform the following query: The generated output files are BlockCompare_dgmainb_1 and BlockCompare_dgmainc_d_1.
The standby database is now ready to receive and apply redo from the primary database. Typically, a backup taken a couple of hours before the failover would be old enough. Maintenance and future role transitions are simplified if the same disk group names are used for both the primary and standby databases. See Oracle Database Reference for more information about the V$DATAFILE view.
Otherwise the new primary database has not completed the work required to enable support for logical standby databases. 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. The UNTIL SCN syntax allows RMAN to automatically choose a suitable backup to restore from. See Oracle Database Backup and Recovery User's Guide for more information. These are the steps required on a logical standby database after the primary database has failed over to another standby 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. One of the benefits of a standby database is that Flashback Database can be performed on the standby database without affecting the primary database service. The RMAN utility is able to use a partial file name to retrieve the files from the correct location. 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). The most common reason is that a block has been modified recently at the primary and not yet written to its corresponding data file. Otherwise, SQL Apply stops with an error ORA-1346: LogMiner processed redo beyond specified reset log scn. This is done by comparing SCNs of blocks stored in the redo log on the primary database to SCNs of blocks on the physical standby database. Such a need can arise when configuring a logical standby database with a new primary database after a failover. For those standby databases that are neither mounted nor open, no action is taken. 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. Start Redo Apply on the new physical standby database: Redo Apply automatically stops each time it encounters a redo record that is generated as the result of a role transition, so Redo Apply needs to be restarted one or more times until it has applied beyond the SCN at which the new primary database became the primary database. In this case, flashing back the database is unnecessary because apply services do not stop upon reaching the OPEN RESETLOGS statement in the redo data. Perform point-in-time recovery to RECOVERY_SCN +1 in SQL*Plus. 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. Turn off flashback database, if it is enabled (necessary for the USING BACKUP CONTROLFILE clause). 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. Example 15-3 Primary Is Mounted or Open, But Not All Standbys Are, and DBCOMP is Executed From the Primary. 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. 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 query on the standby database: If one or more rows are returned, it confirms that there are registered logfiles from the primary's new branch. The next time media recovery is run, the stale entries are removed and any newly invalidated blocks are recorded but any prior invalid blocks do not have entries in V$NONLOGGED_BLOCK. 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 following is an example of the messages that may appear in the alert log: Before media recovery on the standby can continue any further, you must restore all data files for that PDB. 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. 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. However, there are times when the information is not complete. 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. 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. Start up the database in restricted mode to protect it from rogue transactions until the GUARD ALL command can be issued after the database has been opened.
If the primary database is configured to use OMF, then Oracle recommends that the standby database be configured to use OMF, too. Example 15-4 Primary Is Mounted or Open, But Not All Standbys Are, and DBCOMP is Executed From a Standby. 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. You must have already enabled Flashback Database on the original primary database before the failover. The RMAN RECOVER NONLOGGED BLOCK command can be used to recover blocks that belong to a set of data files or a set of tablespaces or just a single pluggable database (PDB) as well as the multitenant container database (CDB). You can use the following RMAN command to delete the relevant archive logs from the fast recovery area: On the new primary database, issue the following query to determine the minimum set of log files that must be copied to the failed primary database before recovering from a backup: Retrieve the required standby logs, copy the backup set to the new standby and restore it to the new standby fast recovery area. 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. In actuality, a redo record is still written to the online redo log file, but there is no data associated with the record.
Configure redo transport authentication as described in Configure Redo Transport Authentication. Example 15-6 Primary Is Mounted or Open, But No Standbys Are Mounted or Open. To convert the database to a physical standby database, issue the following statement on the old primary database: To start transporting redo to the new physical standby database, perform the following steps on the new primary database: Issue the following query to see the current state of the archive destinations: Perform a log switch to ensure the standby database begins receiving redo data from the new primary database, and verify it was sent successfully. This is an important step in order for the old primary to become a new standby following the new primary. This procedure requires that the COMPATIBLE initialization parameter of the old primary be set to at least 11.0.0. If this step is not done, the old primary may recover to an incorrect database branch. You can do this by using the DBMS_LOGSTDBY.SKIP procedure. To ensure these divergent archive logs are never applied, they must be deleted from backups and the fast recovery area. Other standby databases are not considered. 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. Whenever managed recovery is started, it again begins fixing any outstanding blocks from earlier recovery sessions. All data at or after the SCN printed in the block error messages is lost. Each of them can be adapted to your specific environment. An examination of the alert logs would reveal that the primary had performed FLASHBACK DATABASE and OPEN RESETLOGS commands, but the standby had not been flashed back. Oracle Database Backup and Recovery User's Guide for more information about performing point-in-time recovery of PDBs. These steps bring the old primary database back into the Oracle Data Guard configuration as a physical standby database. However, if Flashback Database was not enabled on the failed primary, you can still convert the failed primary into either a physical or logical standby using a local backup of the failed primary, as described in the following topics: Converting a Failed Primary into a Physical Standby Using RMAN Backups, Converting a Failed Primary into a Logical Standby Using RMAN Backups. Configure Oracle Net, as required, to allow connections to the standby database. As a result of the failover, the original primary database can no longer participate in the Oracle Data Guard configuration, and all other standby databases now receive and apply redo data from the new primary database.
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). The character set migration process consists of preparatory steps such as scanning for possible issues and identifying methods to solve them. If an error occurrs on the primary database in an Oracle Data Guard configuration in which the standby database is using real-time apply, then the same error is applied on the standby database. Example 15-2 Primary and All Standbys Are Mounted or Open and DBCOMP Is Executed From a Standby. This may mean that the block sent to the standby is too old to replace the unrecoverable block on the standby. Any new lost writes that happen on either the primary or the standby are detected. 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. These steps describe a simple approach that recovers all nonlogged blocks. After the data files have been restored at the standby, restart MRP to continue applying the redo logs. warning is written in the alert.log, perform the following steps: Flash back the database to the SCN as stated in the warning and then.
(You cannot use flashback database or the Oracle Data Guard broker to reinstantiate the old primary database in this situation.) 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).
On the SAT database, issue the following statement to start SQL Apply: These steps demonstrate how to configure a logical standby database to support a new primary database that was a logical standby database before it assumed the primary role. This means the standby would now be on an orphaned branch of redo and therefore the primary could not supply data blocks that would be known to be the correct version. Call the PREPARE_FOR_NEW_PRIMARY routine to verify that the logical standby database is capable of serving as a standby database to the new primary database. After the preparatory steps are completed, the actual conversion is performed which may involve changes to both system data (metadata) and user data. Ensure the new primary database is ready to support logical standby databases. 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. To restart redo transport services, perform the following steps on the new primary database: Perform a log switch to ensure the standby database begins receiving redo data from the new primary database, and verify it was sent successfully.
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). For example, suppose that you perform the following query: The generated output file is BlockCompare_dgmain_1. Use the backup to restore the data files of the failed primary database. 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. These scenarios present different situations you might encounter while administering your Oracle Data Guard configuration. To create a logical standby database, continue with the standby database creation process described in Creating a Logical Standby Database , but with the following modifications: After you successfully complete these steps, continue with the steps in Open the Logical Standby Database to start, recover, and verify the logical standby database. If flashback is enabled on the standby, you can flashback the PDB on the standby and then restart standby managed recovery. 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. 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 VALIDATE NONLOGGED BLOCK command has the same options as the RECOVER NONLOGGED BLOCK command to validate just a set of data files or a set of tablespaces or a PDB, as well as the CDB. See "Performing a Switchover to a Physical Standby Database" for more information. Oracle Database Backup and Recovery User's Guide for more information about enabling lost-write detection. 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.
In the following example situations, assume that there is a primary database with a unique name of dgmain, and that physical standby databases are named dgmainb, dgmainc, dgmaind, and so on. Configuring Logical Standby Databases After a Failover, Converting a Failed Primary Into a Standby Database Using Flashback Database, Using Flashback Database After Issuing an Open Resetlogs Statement, Recovering After the NOLOGGING Clause Is Specified, Creating a Standby Database That Uses OMF or Oracle ASM, Recovering From Lost-Write Errors on a Primary Database, Using the DBCOMP Procedure to Detect Lost Writes and Other Inconsistencies, Converting a Failed Primary into a Standby Database Using RMAN Backups, Changing the Character Set of a Primary Without Re-Creating Physical Standbys, Actions Needed On a Standby After a PDB PITR or PDB Flashback On a Primary. (If Flashback Database is not enabled, you need to re-create the standby database, as described in Creating a Physical Standby Database and Creating a Logical Standby Database , after the point-in-time recovery was performed on the primary database.). See Performing Recovery When Flashback is Not Enabled below. To ensure these divergent archive logs are never applied, they must be deleted from backups and the fast recovery area. In this section, it is assumed that SQL Apply has already stopped with such an error. On the SAT database, issue the following statement to configure the FAL_SERVER parameter to enable automatic recovery of log files. These steps describe how to convert a failed primary into a physical standby by using RMAN backups. If flashback in not enabled on the standby, then recovery can be done from a backup taken at a time prior to the point-in-time the PDB was recovered on the primary. Issue the following SQL statements to flash back the logical standby database to the specified SCN, and open the logical standby database with the. 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. Oracle Database Backup and Recovery User's Guide. Issue the following SQL statement on the standby database to convert it to a primary: Back up the new primary. Typically this is after upgrading from a release prior to Oracle Database 12c Release 1 (12.1) or after restoring an operating system backup of a data file. In this scenario, SAT is the logical standby database and NYC is the primary database. Therefore, any undetected lost writes that the old standby had before it was activated are not detected by the new standby, since the new standby compares the same blocks. For example: A value of NONE must be returned before you attempt to reinstate an old primary database. Because no appropriate pair of primary and physical standby databases are found, a message is printed out in the corresponding output file, but no ORA error is returned. (Managed recovery is started with the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT statement.) Perform the following tasks to prepare for standby database creation: Enable forced logging on the primary database.
If the primary database uses OMF files, use RMAN to update the standby database control file to use the new OMF files created on the standby database. Flashing back a database to a specific point in time is a straightforward task, however on a logical standby database, you may want to flash back to a time just before a known transaction was committed. With either method, a PDB that has undergone PDB PITR or flashback on the primary cannot be opened on a standby until it has caught up with the primary. The following is a sample use of the RMAN BACKUP command: The following is a sample use of the RMAN RESTORE command: Restore a backup of all the original primary's data files and recover to RECOVERY_SCN + 1. See Performing Recovery When Flashback is Enabled below. On the NYC database, ensure the following query returns a value of NONE. This automatic recovery applies only to corrupt blocks caused by redo generated with the STANDBY NOLOGGING FOR LOAD PERFORMANCE mode enabled. Because lost-write errors are detected only when a block is read into the cache by a primary and the corresponding redo is later compared to the block on the standby, there may be undetected stale blocks on both the primary and the standby that have not yet been read and verified. 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. These stale blocks do not affect operation of the current database because until those blocks are read, all blocks that have been used up to the SCN of the currently applied redo on the standby to do queries or updates were verified by the standby. Start the standby database instance without mounting the control file. Determine the flashback SCN and the recovery SCN.
These steps describe how to avoid re-creating a physical standby database after you issue the OPEN RESETLOGS statement on the primary database. The only way to correct the problem then is to convert the old primary again.
Set the STANDBY_FILE_MANAGEMENT initialization parameter to AUTO. After a failover has occurred, a logical standby database cannot act as a standby database for the new primary database until it has applied the final redo from the original primary database. You can continue to use your physical standby database with minimal disruption while performing character set conversion of a primary database. To resolve this, issue the RECOVER command again at a later time after the block has been written out to the data file. 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. To do this, you can use the Flashback Database feature to recover the failed primary database to a point in time before the failover occurred, and then convert it into a physical or logical standby database in the new configuration. Before the new standby database was created, the new primary database probably stopped transmitting redo to the remote destination. For a detailed description of the steps involved in this process, see My Oracle Support note 1124165.1 at http://support.oracle.com. Otherwise, the recovery process could attempt to access online redo logs instead of the logs retrieved in Step 3. When a PDB PITR or PDB flashback is performed on the primary, and redo for the start of the operation is encountered for the first time, the MRP at the standby terminates with error ORA-39874, followed by the supplemental error ORA-39873. During media recovery in an Oracle Data Guard configuration, a physical standby database can be used to detect lost-write data corruption errors on the primary database. When the redo is applied to the physical standby database, a portion of the data file is marked as being unrecoverable. For example, on the primary database, use the following query to obtain the value of the system change number (SCN) that is 2 SCNs before the. On the SAT database, issue the following statement to configure the FAL_SERVER parameter to enable automatic recover of log files: Call the PREPARE_FOR_NEW_PRIMARY routine to verify the logical standby database is capable of being a standby to the new primary. The view V$NONLOGGED_BLOCK usually lists the ranges of known invalid blocks for each data file and the entries are maintained as part of media recovery. For example, suppose that you perform the following query: The generated output files are BlockCompare_dgmainb_1 and BlockCompare_dgmainc_d_1.