Oraclew.uardstudy -- zoouardfailover case

OracleDataGuardStudy -- zoouardfailover case example mongoledg (mongouard) is a common database HA Configuration Policy. By implementing PhysicalStandby and LogicalStandby, You can implement data redundancy and fault tolerance mechanisms. Prevents serious faults in the master database and does not support services.

Oracle replica uard Study -- replica uard FailOver case Oracle DG (replica uard) is a common database HA Configuration Policy. By implementing Physical Standby and Logical Standby, You can implement data redundancy and fault tolerance mechanisms. Prevents serious faults in the master database and does not support services.

Oracle slave uard Study -- zoouard FailOver case

Oracle DG (Distributed uard) is a common database HA Configuration Policy. By implementing Physical Standby and Logical Standby, You can implement data redundancy and fault tolerance mechanisms. To prevent serious faults in the master database and the service cannot be supported, there is no quick backup support environment.

Switchover and failover are two important concepts in DG and are also the core of DG implementation. The two have the same thing in common: Primary and Standby role switching. The difference lies in the difference between Planned and UnPlanned. The key aspect of Switchover is Planned, which is the action Planned by the O & M organization. For example, periodic system software and hardware upgrades and equipment maintenance. Failover is a real serious system failure, such as database downtime, software and hardware failure caused by Primary cannot support the service, thus switching action.

Switchover and failover are different based on different DG configurations. Theoretically, Switchover will not cause data loss. Primary also exists as Standby in the DG configuration environment after switching. However, Failover is different. Apart from running in Maximum Protection mode, a certain part of Redo logs cannot be transmitted to the Standby end in time due to a Primary burst fault, data loss may occur after switching. More importantly, after a Failover occurs on the Primary end, it cannot be directly added back to the DG configuration! That is to say, after the Failover, the Primary is actually thrown out of the DG Environment.

So, is there any way to implement Primary back to the original environment? The difficulty of this problem is to keep Primary consistent with Standby. Under normal circumstances, Primary and Standby are associated and synchronized, even if Switchover occurs, it is controllable. There is a lack of data in the Failover process, and there is a Primary fix problem. In the current popular version (11g), there are three methods:

Ü environment reconstruction: the simplest method is to directly Delete the original Primary database, reference the DG reconstruction method, and re-build the Standby end;

Ü RMAN backup and recovery: if the Primary end retains a backup before the Failover, you can force the original Primary end to restore to the time point for Failover, after receiving the redo log of the current Primary as Standby, the application can keep up with the progress;

Ü Flashback Database Restoration: Flashback is a supplement to traditional backup restoration technologies and provides more convenient recovery policies. With flashback, you can restore the database to the time point before the failover. The subsequent process is the same as the RMAN backup recovery policy;

Case Analysis:

1. Simulate unexpected database downtime on the master database

scott@bjdb>conn /as sysdbaConnected.sys@bjdb>alter system switch logfile;System altered.sys@bjdb>shutdown abortORACLE instance shut down.

2. on the slave Database End

1. View switch Information

Sys @ shdb> select name, database_role, switchover_status from v $ database; NAME DATABASE_ROLE SWITCHOVER_STATUS --------- -------------- cannot switch between TESTDB12 physical standby not allowed.

2. Direct Switch

Sys @ shdb> alter database commit to switchover to primary; alert_log :( Alert Log) Fatal NI connect error 12514, connecting to: (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = shsrv) (PORT = 1521) (CONNECT_DATA = (SERVICE_NAME = shdb) (CID = (PROGRAM = oracle) (HOST = bjsrv) (USER = oracle) version information: TNS for Linux: Version 11.2.0.3.0-Production TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.3.0-Production Time: 04-MAR-2015 21:25:13 Tracing not turned on. tns error struct: ns main err code: 12564 TNS-12564: TNS: connection refused ns secondary err code: 0 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 Error 12514 received logging on to the standbyFAL [client, MRP0]: error 12514 connecting to shdb for fetching gap sequenceWed Mar 04 21:26:00 2015 alter database commit to switchover to primaryALTER database switchover to primary (TestDB12) Maximum wait for role transition is 15 minutes. switchover: media recovery is still activeDatabase not available for switchover End-Of-REDO archived log file has not been recoveredDatabase not available switchover

3. Disable the standby flat process.

sys@shdb>ALTER DATABASE RECOVER  managed standby database finish;ALTER DATABASE RECOVER  managed standby database finish  Terminal Recovery: request posted (TestDB12)Wed Mar 04 21:34:34 2015Begin: Standby Redo Logfile archivalEnd: Standby Redo Logfile archivalTerminal Recovery timestamp is '03/04/2015 21:34:34'Terminal Recovery: applying standby redo logs.Terminal Recovery: thread 1 seq# 34 redo requiredMedia Recovery Waiting for thread 1 sequence 34Terminal Recovery: End-Of-Redo log allocationTerminal Recovery: standby redo logfile 4 created '/dsk4/arch_bj/arch_1_0_820054583.log'This standby redo logfile is being created as part of thefailover operation.  This standby redo logfile should bedeleted after the switchover to primary operation completes.Media Recovery Log /dsk4/arch_bj/arch_1_0_820054583.logTerminal Recovery: log 4 reserved for thread 1 sequence 34Recovery of Online Redo Log: Thread 1 Group 4 Seq 34 Reading mem 0  Mem# 0: /dsk4/arch_bj/arch_1_0_820054583.logIdentified End-Of-Redo (failover) for thread 1 sequence 34 at SCN 0xffff.ffffffffIncomplete Recovery applied until change 1234252 time 03/04/2015 21:23:43MRP0: Media Recovery Complete (TestDB12)Terminal Recovery: successful completionWed Mar 04 21:34:35 2015ARCH: Archival stopped, error occurred. Will continue retryingORACLE Instance TestDB12 - Archival ErrorORA-16014: log 4 sequence# 34 not archived, no available destinationsORA-00312: online log 4 thread 1: '/dsk4/arch_bj/arch_1_0_820054583.log'Forcing ARSCN to IRSCN for TR 0:1234252Attempt to set limbo arscn 0:1234252 irscn 0:1234252 Resetting standby activation ID 2865247982 (0xaac836ee)MRP0: Background Media Recovery process shutdown (TestDB12)Terminal Recovery: completion detected (TestDB12)Completed: ALTER DATABASE RECOVER  managed standby database finish

4. Switch the database to Primary

Sys @ shdb> select status from v $ instance; STATUS ------------ OPENsys @ shdb> select name, database_role, switchover_status from v $ database; NAME DATABASE_ROLE SWITCHOVER_STATUS --------- -------------- ------------------------ TESTDB12 physical standby to PRIMARYsys @ shdb> alter database commit to switchover to primary; Database altered. sys @ shdb> alter database open; Database altered. alert Log: alter database commit to switchover to primaryALTER database switchover to primary (TestDB12) Maximum wait for role transition is 15 minutes. all dispatchers and shared servers shutdownCLOSE: killing server sessions. CLOSE: all sessions shutdown successfully. wed Mar 04 21:35:47 2015 SMON: disabling cache recoveryBackup controlfile written to trace file/u01/app/oracle/diag/rdbms/bjdb/TestDB12/trace/TestDB12_ora_3146.trcStandby terminal recovery start SCN: 1234251 RESETLOGS after incomplete recovery until change 1234252 Online log/dsk2/oradata/bjdb/redo01b. log: Thread 1 Group 1 was previusly clearedOnline log/dsk1/oradata/bjdb/redo01a. log: Thread 1 Group 1 was previusly clearedOnline log/dsk2/oradata/bjdb/redo02b. log: Thread 1 Group 2 was previusly clearedOnline log/dsk1/oradata/bjdb/redo02a. log: Thread 1 Group 2 was previusly clearedOnline log/dsk2/oradata/bjdb/redo03b. log: Thread 1 Group 3 was previusly clearedOnline log/dsk1/oradata/bjdb/redo03a. log: Thread 1 Group 3 was previusly clearedStandby became primary SCN: 1234250Wed Mar 04 21:35:47 2015 Setting recovery target incarnation to 3AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file. switchover: Complete-Database mounted as primaryCompleted: alter database commit to switchover to primary

3. After the original master database is repaired, it will start up

sys@bjdb>startupORACLE instance started.Total System Global Area  442601472 bytesFixed Size                  2229184 bytesVariable Size             281021504 bytesDatabase Buffers          155189248 bytesRedo Buffers                4161536 bytesDatabase mounted.Database opened.sys@bjdb>select name,database_role,switchover_status from v$database;NAME      DATABASE_ROLE    SWITCHOVER_STATUS--------- ---------------- --------------------TESTDB12  PRIMARY          FAILED DESTINATION

After the original primary database is repaired, the entire replicuara architecture has been damaged. Therefore, you must build the original primary database into a new standby database and restore the replicuard environment.

4. re-build the DataGuard

sys@bjdb>select name,database_role from v$database;

NAME DATABASE_ROLE

------------------------------------------------------------------

TESTDB12 PHYSICAL STANDBY