利用flashback将DG中failover之后的主库变为备库,不必重新搭建DG

oracle官方文档

Data Guard Concepts and Administration

3 Creating a Physical Standby Database

3.3 Post-Creation Steps

3.3 Post-Creation Steps

At this point, the physical standby database is running and can provide the maximum performance level of data protection. The following list describes additional actions you can take on the physical standby database:

  • Upgrade the data protection mode

    The Data Guard configuration is initially set up in the maximum performance mode (the default).

  • Enable Flashback Database

    Flashback Database removes the need to re-create the primary database after a failover. Flashback Database enables you to return a database to its state at a time in the recent past much faster than traditional point-in-time recovery, because it does not require restoring datafiles from backup nor the extensive application of redo data. You can enable Flashback Database on the primary database, the standby database, or both. SeeSection 13.2 and Section 13.3 for scenarios showing how to use Flashback Database in a Data Guard environment. Also, see Oracle Database Backup and Recovery User's Guide for more information about Flashback Database.


译:闪回数据库功能使主库failover后可以不必重建。闪回功能可以使数据库恢复到最近的时间(相对于传统方式的基于时间的恢复),因为这不需要
从备份中恢复数据文件也不需要应用日志。可以在主库或备库启用闪回数据库功能,或同时启用。


failover之后的主备库恢复操作基本如下:
将Failover 之后的老的主库  flashback成新primary 的standby 库:
1.   在新主库查出failover 时的SCN:
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
TO_CHAR(STANDBY_BECAME_PRIMARY_SCN)
----------------------------------------
2332465
2.  在old primary库上:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN 2332465;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;


13.2.1 Flashing Back a Failed Primary Database into a Physical Standby Database

The following steps assume that a failover has been performed to a physical standby database and that Flashback Database was enabled on the old primary database at the time of the failover. This procedure brings the old primary database back into the Data Guard configuration as a physical standby database.

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   Flash back the failed 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 inStep 1.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;
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   Start transporting redo to the new physical standby database.

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. Issue the following SQL statements on the new primary database:

    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.

Step 5   Start Redo Apply on the new physical standby database.

Issue the following SQL statement on the new physical standby database:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE -
> USING CURRENT LOGFILE DISCONNECT;

Redo Apply automatically stops each time it encounters a redo record that is generated as the result of a role transition, so Redo Apply will need to be restarted one or more times until it has applied beyond the SCN at which the new primary database became the primary 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. See Section 8.2.1, "Performing a Switchover to a Physical Standby Database" for more information.


你可能感兴趣的:(利用flashback将DG中failover之后的主库变为备库,不必重新搭建DG)