Oracle DataGuard Study--dataguard failover case

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