Oracle DataGuard Study--dataguard failover case
Oracle DG (Dataguard) is now a common database ha configuration policy. By implementing physical Standby and logical Standby, the data redundancy tolerance mechanism can be realized. There is no fast backup support environment when there is a major failure in the main library and no support for the service.
in Dg switchover and failover dg The core of implementation. The two common points are primary and standby and Unplanned planned Primary can not support the service, thus the switching action.
according to the differentDgconfiguration,Switchoverand theFailoverthere are also differences. Theoretically,Switchoverdoes not result in data loss,PrimaryAfter the switch is also in theDgin the configuration environment, asStandbyexist. ButFailoveris different, except that it runs at maximum protection (Maximum Protection) mode,Primarysudden failure can cause a partRedo Logcannot be delivered in a timely manner toStandbydata loss is likely to occur after switching. More importantly,Primaryend in the HappeningFailoverafter that, is not able to directly join backDgconfigured! In other words,Failoverlater,Primaryis actually being "thrown".Dgenvironment.
So, what's the way to achieve Primary back to the original environment? The difficulty of this problem is to keep Primary and Standby consistent. Under normal circumstances,Primary and Standby are associated with synchronization, even if a switchover occurs , butalso in a controlled situation. There is a lack of data in the Failover process, and there are Primary repair problems. In the current popular version (11g), there are three methods:
ü environment Reconstruction: one of the simplest ways is to delete the original Primary library, referring to dg Reconstruction method, rebuild standby
ü rman Backup recovery: If primary end has retained a copy failover primary The end reverts to the failover standby primary redo Log pass, after application can keep up with the progress;
ü Flashback Database Recovery:Flashback Technology is a complement to traditional backup and restore technology, providing a more convenient recovery strategy. With Flashback, you can restore a database to a point in time before failover. The subsequent process is the same as the RMAN backup recovery strategy;
Case Analysis:
One, the main library end of the simulation database unplanned downtime
[Email Protected]>conn/as sysdbaconnected. [Email protected]>alter system switch logfile; System altered. [Email protected]>shutdown abortoracle instance shut down.
Second, in the standby library side
1. View toggle Information
[Email protected]>select name,database_role,switchover_status from V$database;name database_role SWITCHOVER_STA TUS---------------------------------------------TESTDB12 physical STANDBY not allowed you can see that the standby is not in a switchable state at this time
[Email protected]>alter database commit to switchover to primary;alert_ LOG: (alarm 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&Nbsp;code: 0 nt main err code: 0 nt secondary err code: 0 nt os err code: 0error 12514 received logging on to the standbyfal[client, mrp0]: error 12514 connecting to shdb for fetching gap sequenceWed Mar 04 21:26:00 2015alter 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 for switchover end-of-redo arChived log file has not been recovereddatabase not available for switchover
3, Close standby MPR process
[email protected]>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&NBsp;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 database to primary
[email protected]>select status from v$instance; STATUS------------Open[email protected]>select name,database_role,switchover_status from v$database;name database_role switchover_ STATUS--------- ---------------- --------------------testdb12 physical standby to primary[email protected]>alter database commit to switchover to Primary;database altered. [email protected]>alter database open;database altered. Alarm 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 2015smon: disabling cache recoverybackup controlfile written to trace file /u01/app/oracle/diag/rdbms/bjdb/testdb12/trace/ Testdb12_ora_3146.trcstandby terminal recovery start scn: 1234251resetlogs after incomplete recovery until change 1234252online log /dsk2/oradata/bjdb/ redo01b.log: thread 1 group 1 was previously clearedonline log / dsk1/oradata/bjdb/redo01a.log: thread 1 group 1 was previously Clearedonline log /dsk2/oradata/bjdb/redo02b.log: thread 1 group 2 was previously clearedOnline log /dsk1/oradata/bjdb/redo02a.log: Thread 1 group 2 was previously clearedonline log /dsk2/oradata/bjdb/redo03b.log: thread 1 group 3 was previously clearedonline log /dsk1/oradata/bjdb/redo03a.log: thread 1 Group 3 was previously clearedStandby became primary SCN: 1234250wed mar 04 21:35:47 2015setting 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
three, after the original library is repaired, the boot
[Email protected]>startuporacle instance started. total system global area 442601472 bytesfixed size 2229184 bytesvariable Size 281021504 Bytesdatabase buffers 155189248 bytesredo Buffers 4161536 bytesdatabase mounted. database opened. [Email protected]>select name,database_role,switchover_status from v$database;name database_role switchover_status--------- ----- ----------- --------------------testdb12 primary &nbSp; failed destination
Now that the original main library has been repaired, the entire Dataguara architecture has been destroyed, so the original main library must be built into a new repository to restore the Dataguard environment.
Iv. Rebuilding the Dataguard
[Email protected]>select name,database_role from V$database;
NAME Database_role
-------------------------------------------------- ----------------
TESTDB12 Physical STANDBY
This article is from the "Tianya blog," Please make sure to keep this source http://tiany.blog.51cto.com/513694/1617646
Oracle DataGuard Study--dataguard failover case