How can I use the flashback database feature to restore the replicasuard environment after a failover ?, Failoverdataguard

Source: Internet
Author: User

How can I use the flashback database feature to restore the replicasuard environment after a failover ?, Failoverdataguard
The 11g slave uard standby is cut into the master database. After the test is completed, it is restored to the original standby environment.


#######################
Overview:
11204 if a single machine implements dg on a single machine, standby needs to be enabled because of the local requirement (read/write mode). In this case, the original production environment cannot have any impact and the service is still external;
The idea is: standby directly failover is the primary db; in this case, the original dg relationship is damaged and does not affect each other;


#######################
Overview:
1. Are you sure you have enough storage space for archiving logs in the master database? (Do you need to consider the archive retention and deletion policy ?); Disable log transmission from the master database to the slave Database
2. Check whether flashback database is enabled for the slave database and whether there is sufficient storage space for flash logs?
3. Slave database failover to primary (Are you sure you want to delay log transmission before switching? Manual registration)
4. Business Test
5. Restore the failover slave Database
6. Are you sure the dg Environment is normal (Automatic Log transmission and application ?)?



#######################
Specific implementation steps:

------ Defer log transmission in the master database
Alter system set log_archive_dest_2 = defer;

--- Enable log transmission:
Alter system set log_archive_dest_2 = enable;

----- Configure the flashback database in the standby database (mount:
Standby database: Stop redo apply, configure flashback retention,
Start flashback database, open the database and start redo apply (Is active DG ).

--- Check whether flashback database is enabled for the slave database:
Select flashback_on from v $ database;


Note that you need to confirm the standby database opening mode: mount? Readonly with apply?
In the 11g environment, the Standby database may have the ADG feature enabled. The standby database logs are applied in real time, and the database mode is readonly with apply.
Restart the database to the mount State to modify the flashback database mode;


If the standby database is in the mount state, you can cancel the log apply and directly enable the feature of flashing back to the database;


--- Cancel the standby database log application:
Alter database recover managed standby database cancel;


--- You need to configure two parameters to enable the flashback database feature:
Alter system set db_recover_file_dest = '/lixora /';
Alter system set db_recover_file_dest_size = 100G;

Alter system set DB_FLASHBACK_RETENTION_TARGET = 240; --- 4 hours
Alter database flashback on;

-- Manually create restore points (this step has not been tested ):
Creating Restore point in Physical Standby:
Create restore point before_damage GUARANTEE FLASHBACK DATABASE


------- Standby database failover to primary db emergency switchover steps:
(Note: to simulate the failure of the master database, switchover fails. You need to execute failover to prepare the database-> pridb and take over the business)

1. Slave database:
Because it is a failover, the master database cannot be used normally at this time. You only need to switch the slave database to pridb.

[Premise that the master database is still available: Optional] query logs without application:
Select thread #, LOW_SEQUENCE #, HIGH_SEQUENCE # from v $ ARCHIVE_GAP;

Select distinct thread #, max (sequence #) over (partition by thread #) a from v $ archived_log;
This statement obtains the maximum number of files archived by each thread in the current database. If the maximum number of primary and standby is different,
You must copy the archive file corresponding to the serial number to the standby server to be converted.


Cp and register
Alter database register physical logfile 'filespec1'

Stop Application recovery mode
Alter database recover managed standby database finish;
Or
Alter database recover managed standby database finish force;

Convert standbydb to primary db
Alter database commit to switchover to primary;


Restart the database to restore normal services
Alter database open;


View database roles:
Select open_mode, database_role from v $ database;
OPEN_MODE DATABASE_ROLE
--------------------------
OPEN PRIMARY


------ Restore the slave database of failover:
C. Using SQL * PLUS
Step 1 Determine the Standby Became Primary SCN.
Step 2 Flashback the Failed Primary Database.
Step 3 Convert to physical standby database.
Step 4 Restart Redo Transport.
Step 5 Start Redo Apply.


Step 1 Determine the SCN at which the old standby database became the primary database.
SQL> SELECT TO_CHAR (STANDBY_BECAME_PRIMARY_SCN) FROM V $ DATABASE;


Step 2 Flashback the Failed Primary Database to SCN standby_became_primary_scn.
SQL> SHUTDOWN IMMEDIATE;
SQL> startup mount
SQL> FLASHBACK DATABASE TO SCN <standby_became_primary_scn of step 1>;

Step 3 Convert the database to a physical standby database and Restart database in mount stage.
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;


Step 4 Restart Redo Transport to the New Physical Standby Database.
1. If you have not set the remote archive destination on current primary then set remote archive destination:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'service = lixora VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = lixora 'scope = BOTH;

2. Enable the destination
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE;

3. Perform a log switch to ensure that standby database begins restore ing redo data from the new primary database
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, STATUS, ERROR FROM V $ ARCHIVE_DEST WHERE DEST_ID = 2;


-- Are all logs applied?
Select applied from v $ archived_log;

Select message from v $ dataguard_status;


Step 5 Start Redo Apply.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Please see also fallowing docu:


TIPS:
Oracle? Data Guard Concepts and Administration
11g Release 2 (11.2)
13.2 Converting a Failed Primary Into a Standby Database Using Flashback Database

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.