Oracle DG（Dataguard）是目前比較常見的資料庫HA配置策略。透過實現Physical Standby和Logical Standby，可以實現資料冗餘容錯機制。防止在主庫出現嚴重故障，不能支援服務的時候，沒有快速的後備支援環境。

在DG中，switchover和failover是兩個重要的概念，也是DG實現的核心。兩者共同點都是Primary和Standby角色切換，差異在於Planned和UnPlanned之分。Switchover關鍵點在於Planned，這個切換動作是在運維機構規劃範圍內的動作。比如，進行定期系統軟硬體升級、裝置維修等動作。而Failover是真正出現嚴重系統故障，如資料庫當機、軟硬體故障導致的Primary不能支援服務，從而進行的切換動作。

根據不同的DG配置，switchover和failover也是有差異的。理論上，Switchover是不會造成資料丟失的，Primary在切換之後也是在DG配置環境中，作為Standby存在的。但是Failover則不同，除了執行在最大保護（Maximum Protection）模式下，Primary突發的故障可能引起一部分Redo Log不能及時的傳遞到Standby端，切換之後很可能有資料損失的情況。更重要的是，Primary端在發生Failover之後，是不能夠直接加入回DG配置的！也就是說，Failover之後，Primary實際上就是被“丟擲”了DG環境。

那麼，有什麼方法實現Primary回到原有的環境呢？這個問題的困難在於保持Primary和Standby一致。在正常情況下，Primary和Standby之間是關聯同步的，即使發生了Switchover，也在可控情況下。Failover過程中有資料的缺失，還有Primary修復問題。在目前流行版本（11g）中，有三個方法：

ü 環境重建：一種最簡單的方法就是直接刪除原來的Primary庫，引用DG重建方法，重新搭建Standby端；

ü RMAN備份恢復：如果Primary端保留過一份Failover之前的備份，則可以強制原來的Primary端恢復到進行Failover的時間點，之後作為Standby接收當前Primary的redo log傳遞，應用後可以跟上進度；

ü Flashback Database恢復：Flashback技術是作為傳統備份還原技術的補充，提供了更加便捷的恢復策略。使用flashback，可以將資料庫恢復到failover之前的時間點。之後的過程和RMAN備份恢復策略相同；

本篇主要介紹使用Flashback恢復failover主庫的過程。

1、環境介紹

筆者選擇Oracle11g進行測試，具體版本為11.2.0.4。DG已經搭建完成，主庫例項名為ora11g，standby庫名稱為ora11gsy。

由於環境所限，兩臺例項在相同伺服器上。

[root@SimpleLinux ~]# su - oracle

[oracle@SimpleLinux ~]$ ps -ef | grep pmon

oracle 1655 1 0 12:20 ? 00:00:03 ora_pmon_ora11g

oracle 1891 1 0 12:30 ? 00:00:03 ora_pmon_ora11gsy

oracle 2635 2604 1 14:01 pts/0 00:00:00 grep pmon

兩臺例項角色關係和配置關係正常。

--ora11g

SQL> select name, open_mode, database_role, flashback_on from v$database;

NAME OPEN_MODE DATABASE_ROLE FLASHBACK_ON

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

ORA11G READ WRITE PRIMARY NO

--ora11gsy

SQL> select name, open_mode, database_role, flashback_on from v$database;

NAME OPEN_MODE DATABASE_ROLE FLASHBACK_ON

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

ORA11G READ ONLY WITH APPLY PHYSICAL STANDBY NO

下面首先進行Primary端的flashback database配置。

2、Flashback配置

在Primary端進行flashback配置，確保閃回日誌時間範圍。首先需要完全關閉資料庫，進入mount狀態配置。

[oracle@SimpleLinux ~]$ env | grep ORACLE_SID

ORACLE_SID=ora11g

[oracle@SimpleLinux ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Sun Jun 15 14:07:22 2014

SQL> conn / as sysdba

Connected.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 372449280 bytes

Fixed Size 1364732 bytes

Variable Size 331353348 bytes

Database Buffers 33554432 bytes

Redo Buffers 6176768 bytes

Database mounted.

啟動flashback database，檢視閃回資訊情況。

SQL> alter database flashback on;

Database altered.

SQL> alter database open;

Database altered.

SQL> select flashback_on from v$database;

FLASHBACK_ON

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

YES

flashback失效資訊，透過檢視v$flashback_database_log欄位可以確認最遠的閃回時間。

SQL> select oldest_flashback_scn, oldest_flashback_time from v$flashback_database_log;

OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME

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

779669 15-六月-14 14:08:42

SQL> show parameter flashback

NAME TYPE VALUE

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

db_flashback_retention_target integer 1440

引數db_flashback_retention_target控制閃回時間範圍，數字單位是分鐘，預設為1天。這個數字決定了閃回的時間範圍，如果設定更長的時間，對應的閃回日誌檔案大小就會比較大一些。

3、Primary主庫Failover過程

模仿主庫Primary突然當機，失去聯絡。

SQL> select instance_name from v$instance;

INSTANCE_NAME

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

ora11g

SQL> shutdown abort;

ORACLE instance shut down.

Standby端進行單獨的角色切換。注意：在實際的場景中，進行failover的原因是很多的，Oracle出現故障的場景也有所差異。不同的故障場景是會決定是否出現資料丟失的。

--在standby端進行

SQL> select * from v$archive_gap;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

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

SQL> alter database recover managed standby database cancel;

Database altered

SQL> alter database recover managed standby database finish;

Database altered

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

READ ONLY PHYSICAL STANDBY

如果上面操作順利進行，沒有額外錯誤報出。說明這個過程中沒有資料損失情況發生，也就意味著雖然發生了failover，但是不會有資料損失。

切換角色到Primary。

SQL> alter database commit to switchover to primary with session shutdown;

Database altered

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

MOUNTED PRIMARY

SQL> alter database open;

Database altered

之後，由於standby端ora11gsy上面的歸檔日誌路徑原因，alert log中報錯如下：

Sun Jun 15 14:23:06 2014

Error 1041 received logging on to the standby

FAL[server, ARC3]: Error 1041 creating remote archivelog file 'ora11g'

FAL[server, ARC3]: FAL archive failed, see trace file.

ARCH: FAL archive failed. Archiver continuing

ORACLE Instance ora11gsy - Archival Error. Archiver continuing.

查詢路徑情況：

SQL> col dest_name for a20;

SQL> select dest_id, dest_name, status, type from v$archive_dest_status;

DEST_ID DEST_NAME STATUS TYPE

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

1 LOG_ARCHIVE_DEST_1 VALID LOCAL

2 LOG_ARCHIVE_DEST_2 ERROR UNKNOWN

3 LOG_ARCHIVE_DEST_3 INACTIVE LOCAL

為避免問題反覆出現，臨時性的將路徑設定為defer，阻止反覆的資料傳輸動作。

SQL> alter system set log_archive_dest_state_2='defer';

System altered

SQL> select dest_id, dest_name, status, type from v$archive_dest_status;

DEST_ID DEST_NAME STATUS TYPE

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

1 LOG_ARCHIVE_DEST_1 VALID LOCAL

2 LOG_ARCHIVE_DEST_2 DEFERRED UNKNOWN

Failover過程完成。

4、Primary重新加入

Failover後的Primary資料庫，實際上已經失去了和DG的關聯，如果Primary故障嚴重，是難以保障對應的歸檔資料可以順利傳輸的。

如果希望Primary重新回到DG環境，關鍵就是恢復的時間點。要求Primary回到Standby切換角色的那個時間點，理論上就可以“延續”操作。

在ora11gsy端，檢視v$database檢視，可以看到這個庫成為primary的具體時間。

SQL> select STANDBY_BECAME_PRIMARY_SCN from v$database;

STANDBY_BECAME_PRIMARY_SCN

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

780222

為了測試資料，特建立資料表T，判斷同步情況。

SQL> create table t as select * from dba_objects where rownum<1000;

Table created

SQL> select count(*) from t;

COUNT(*)

----------

999

進行一系列的日誌切換。

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER

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

780959

SQL> alter system switch logfile;

System altered

SQL> alter system switch logfile;

System altered

SQL> alter system switch logfile;

System altered

原主庫啟動，進入mount後，進行flashback操作，回到指定時間點。

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 372449280 bytes

Fixed Size 1364732 bytes

Variable Size 331353348 bytes

Database Buffers 33554432 bytes

Redo Buffers 6176768 bytes

Database mounted.

SQL> flashback database to scn 780222

2 ;

Flashback complete.

注意：重新加入的原Primary是不能回覆角色的，而是隻能先成為Standby角色。應用後續的日誌達到同步。

SQL> alter database convert to physical standby;

Database altered.

SQL> select open_mode, database_role from v$database;

select open_mode, database_role from v$database

*

ERROR at line 1:

ORA-01507: database not mounted

啟動資料庫，確定角色情況。

SQL> shutdown immediate;

ORA-01507: database not mounted

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 372449280 bytes

Fixed Size 1364732 bytes

Variable Size 331353348 bytes

Database Buffers 33554432 bytes

Redo Buffers 6176768 bytes

Database mounted.

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

MOUNTED PHYSICAL STANDBY

在主庫端，啟動archive log傳輸動作。

SQL> alter system set log_archive_dest_state_2='enable';

System altered

SQL> select dest_id, dest_name, status, type from v$archive_dest_status;

DEST_ID DEST_NAME STATUS TYPE

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

1 LOG_ARCHIVE_DEST_1 VALID LOCAL

2 LOG_ARCHIVE_DEST_2 VALID PHYSICAL

3 LOG_ARCHIVE_DEST_3 INACTIVE LOCAL

4 LOG_ARCHIVE_DEST_4 INACTIVE LOCAL

啟動日誌應用，可以檢視逐步應用動作。

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered

SQL> select recid, name, sequence#, applied from v$archived_log where recid>33;

RECID NAME SEQUENCE# APPLIED

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

34 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_3_9sthd1k2_.a 3 NO

35 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_4_9sthd39c_.a 4 NO

36 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_5_9sthd8fp_.a 5 NO

37 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_6_9sthp1qt_.a 6 NO

38 ora11g 6 YES

39 ora11g 29 YES

40 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_7_9sthpky0_.a 7 NO

41 ora11g 1 YES

42 ora11g 2 YES

43 ora11g 3 YES

44 ora11g 4 YES

45 ora11g 5 YES

46 ora11g 7 YES

47 /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_06_15/o1_mf_1_8_9sthzxml_.a 8 NO

48 ora11g 8 NO

15 rows selected

在ora11g上，也可以確定建立資料表T的情況了。

SQL> select count(*) from t;

select count(*) from t

ORA-01219: 資料庫未開啟: 僅允許在固定表/檢視中查詢

SQL> alter database recover managed standby database cancel ;

Database altered

SQL> alter database open;

Database altered

SQL> select open_mode, database_role from v$database;

OPEN_MODE DATABASE_ROLE

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

READ ONLY PHYSICAL STANDBY

SQL> select count(*) from t;

COUNT(*)

----------

999

實驗成功！

5、結論

Oracle DG在發生Failover之後，當主庫解決問題，是不可以直接回到DG環境的。這個過程往往需要一些輔助組建的配合。如RMAN、Flashback，都可以簡化重回DG的過程時間。

使用Flashback讓Failover資料庫重新加入DG環境

相關文章