Converting a Failed Primary into a Physical Standby Database Using RMAN Backups
To convert a failed primary database, Oracle recommends that you enable the Flashback Database feature on the primary and follow the procedure described in either Section 13.2.1 or Section 13.2.2. The procedures in those sections describe the fastest ways to convert a failed primary into either a physical or logical standby. 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 sections:
The steps in this section describe how to convert a failed primary into a physical standby by using RMAN backups. This procedure requires that the COMPATIBLE initialization parameter of the old primary be set to at least 11.0.0.
Step 1 Determine the SCN at which the old standby database became the primary database.
On the new primary database, issue the following query to determine the SCN at which the old standby database became the new primary database:
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
Step 2 Restore and recover the entire database.
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). Then, perform a point-in-time recovery to recover the old primary to that same point.
Issue the following RMAN commands:
RMAN> RUN
{
SET UNTIL SCN
RESTORE DATABASE;
RECOVER DATABASE;
}
[ With user-managed recovery, you can first restore the database manually. Typically, a backup taken a couple of hours before the failover would be old enough. You can then recover the failed primary using the following command:
SQL> RECOVER DATABASE USIING BACKUP CONTROLFILE UNTIL CHANGE -
>
Unlike a reinstantiation that uses Flashback Database, this procedure adds one to standby_became_primary_scn. For datafiles, flashing back to an SCN is equivalent to recovering up until that SCN plus one. ]
Step 3 Convert the database to a physical standby database.
Perform the following steps on the old primary database:
1.Issue the following statement on the old primary database:
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
This statement will dismount the database after successfully converting the control file to a standby control file.
2.Shut down and restart the database:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
Step 4 Open the database as read-only.
Issue the following command:
SQL> ALTER DATABASE OPEN READ ONLY;
The goal of this step is to synchronize the control file with the database by using a dictionary check. After this command, check the alert log for any actions suggested by the dictionary check. Typically, no user action is needed if the old primary was not in the middle of adding or dropping datafiles during the failover.
Step 5 (Optional) Mount the standby again, if desired
If you have purchased a license for the Active Data Guard option and would like to operate your physical standby database in active query mode, skip this step. Otherwise, bring your standby database to the mount state.
For example:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
Step 6 Restart transporting redo to the new physical standby database.
Before the new standby database was created, the new primary database probably stopped transmitting redo to the remote destination. To restart redo transport services, perform the following steps on the new primary database:
1.Issue the following query to see the current state of the archive destinations:
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
2.If necessary, enable the destination:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
3.Perform a log switch to ensure the standby database begins receiving redo data from the new primary database, and verify it was sent successfully.
Note: This is an important step in order for the old primary to become a new standby following the new primary. If this step is not done, the old primary may recover to an incorrect database branch. The only way to correct the problem then is to convert the old primary again.
At the SQL prompt, enter the following statements:
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, -
> ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
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. 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). By doing this, the Data Guard configuration operates properly after a role transition.
Step 7 Start Redo Apply.
Start Redo Apply on the new physical standby database, as follows:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
> USING CURRENT LOGFILE DISCONNECT;
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. See Section 8.2.1, "Performing a Switchover to a Physical Standby Database" for more information.
Posts
