聊聊Oracle 11g的Snapshot Standby Database（上）

 

Oracle 11g是Data Guard的重要里程碑版本。在11g中，Active DataGuard、Advanced Compression等特性大大豐富了Data Guard的功能和在實踐領域應用的廣度。其中，除了傳統的Physical Standby和Logical Standby，11g推出了新的Standby型別——Snapshot Standby。

Standby的實質是“同步更新”，無論是Physical Standby還是Logical Standby，都是依照主庫Primary的形式進行同步或者非同步更新。Standby自身是不能有主動地更新動作的。所以，即使進入11g的Active Data guard，備庫也只是可以進行只讀操作動作，不能自我進行更新動作。

而Snapshot Standby的出現改變了這一點。在Oracle官方文件中，對這個特性的解釋如下：

“A snapshot standby database is a fully updatable standby database. A snapshot

standby database receives and archives, but does not apply, redo data from a primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.”

簡單的說，Snapshot Standby是一種特殊的Standby型別。它以某一個時點的Physical Standby作為基礎，透過convert操作變成snapshot備庫。該備庫可以進行修改操作（增加、修改和刪除）操作。當執行結束之後，可以重新回到Physical Standby角色。“失聯”期間發生的所有update操作，都全部被取消掉。“失聯”期間主庫發生的修改動作，也會在應用apply日誌的時候追趕上。

技術是面對應用場景的。Snapshot是針對什麼樣的需求特徵呢？在實際環境，特別是應用開發、測試環境中，我們偶爾會需要一個臨時性的測試環境。這個環境上進行一些臨時性、可拋棄的測試。這個時候，就可以使用這個snapshot standby。

本篇透過一系列的實驗，來演示Snapshot Standby的常用操作、工作特性和日誌行為分析。

 

1、環境說明

 

筆者使用Oracle 11gR2進行測試，版本編號為11.2.0.4。當前Primary和Standby都已經搭建完成。

版本資訊如下：

 

SQL> select * from v$version;

 

BANNER

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

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

PL/SQL Release 11.2.0.4.0 - Production

CORE     11.2.0.4.0     Production

TNS for Linux: Version 11.2.0.4.0 - Production

NLSRTL Version 11.2.0.4.0 – Production

 

 

主庫Primary資訊：

 

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

 

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ WRITE           PRIMARY          MAXIMUM PERFORMANCE

 

 

SQL> select instance_name from v$instance;

 

INSTANCE_NAME

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

vlife

 

SQL> select group#, sequence#, archived, status from v$log;

 

    GROUP#  SEQUENCE# ARCHIVED STATUS

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

         1         95 YES      INACTIVE

         2         96 YES      INACTIVE

         3         97 NO       CURRENT

 

 

SQL> select recid,sequence#, archived, applied from v$archived_log where name='vlifesb' and sequence#>90;

 

     RECID  SEQUENCE# ARCHIVED APPLIED

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

       123         91 YES      YES

       126         92 YES      YES

       128         93 YES      YES

       130         94 YES      YES

       132         95 YES      YES

       134         96 YES      NO

 

6 rows selected

 

 

當前保護模式是Maximum Protection模式，正在apply狀態的日誌編號是96。當前online redo log編號為97。

Standby端資訊：

 

 

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

 

NAME      OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

VLIFE     READ ONLY WITH APPLY PHYSICAL STANDBY MAXIMUM PERFORMANCE

 

SQL> select instance_name from v$instance;

 

INSTANCE_NAME

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

vlifesb

 

SQL> select group#, sequence#, archived, status from v$log;

 

    GROUP#  SEQUENCE# ARCHIVED STATUS

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

         1         95 YES      CLEARING

         2         96 YES      CLEARING

         3         97 YES      CURRENT

 

 

SQL>  select recid,sequence#, archived, applied from v$archived_log where sequence#>90;

 

     RECID  SEQUENCE# ARCHIVED APPLIED

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

        87         91 YES      YES

        88         92 YES      YES

        89         93 YES      YES

        90         94 YES      YES

        91         95 YES      YES

        92         96 YES      IN-MEMORY

 

6 rows selected

 

 

當前Standby端的Flashback Database開啟。

 

 

SQL> select oldest_flashback_scn, oldest_flashback_time from v$flashback_database_log;

 

OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME

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

             1646229 2015/10/21 3:41:25

 

 

2、切換到Snapshot Standby

 

當前我們的vlifesb是physical standby型別，保護模式是預設的最大效能模式。這也就意味著兩者之前是允許存在Gap的。切換Snapshot Standby，有兩個限制前提條件：

首先，如果切換為Snapshot Standby，就不能在期間進行Switchover和Failover操作。如果需要使用操作，就需要先切換回Physical Standby才能實現。

其次，如果使用的保護模式是Maximum Protection模式，必須有其他的Standby與之相匹配。要不然就會出現由於日誌傳輸引起的當機情況。

當前Standby狀態是隻讀Apply狀態，這個時候需要終止Apply過程，並且切換回mount狀態。否則是不允許進行convert動作的。

 

SQL> alter database convert to snapshot standby;

 

alter database convert to snapshot standby

 

ORA-38784: 無法建立還原點 'SNAPSHOT_STANDBY_REQUIRED_10/22/2015 10:59:37'??

ORA-01153: 啟用了不相容的介質恢復

 

 

重啟資料庫進入mount狀態。

 

SQL> conn / as sysdba

Connected.

SQL> alter database recover managed standby database cancel;

 

Database altered.

 

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area 2471931904 bytes

Fixed Size                  2255752 bytes

Variable Size             738198648 bytes

Database Buffers         1711276032 bytes

Redo Buffers               20201472 bytes

Database mounted.

 

 

進行convert切換動作。

 

 

SQL> alter database convert to snapshot standby;

Database altered.

 

 

此時standby端的alert log展示了動作。

 

Thu Oct 22 11:09:21 2015

alter database convert to snapshot standby

Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_10/22/2015 11:09:21 –建立出一個可用的flashback database restore point

Killing 3 processes with pids 7314,7318,7316 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 7312

Begin: Standby Redo Logfile archival

End: Standby Redo Logfile archival

RESETLOGS after incomplete recovery UNTIL CHANGE 1794139

Resetting resetlogs activation ID 4208260171 (0xfad4f44b)

Online log /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_1_c261g1mo_.log: Thread 1 Group 1 was previously cleared

Online log /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_1_c261g1pt_.log: Thread 1 Group 1 was previously cleared

Online log /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_2_c261g2d0_.log: Thread 1 Group 2 was previously cleared

Online log /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_2_c261g2gl_.log: Thread 1 Group 2 was previously cleared

Online log /u01/app/oracle/oradata/VLIFESB/onlinelog/o1_mf_3_c261g34d_.log: Thread 1 Group 3 was previously cleared

Online log /u01/app/oracle/fast_recovery_area/VLIFESB/onlinelog/o1_mf_3_c261g36q_.log: Thread 1 Group 3 was previously cleared

Standby became primary SCN: 1794137

Thu Oct 22 11:09:23 2015

Setting recovery target incarnation to 3 –建立出一個新的朝代

CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby

Completed: alter database convert to snapshot standby

 

Thu Oct 22 11:09:30 2015

RFS[3]: Assigned to RFS process 7324

RFS[3]: Selected log 5 for thread 1 sequence 98 dbid -87496857 branch 892734889

Thu Oct 22 11:09:30 2015

ARC0: Becoming the 'no SRL' ARCH

Thu Oct 22 11:09:30 2015

RFS[4]: Assigned to RFS process 7326

RFS[4]: Selected log 4 for thread 1 sequence 99 dbid -87496857 branch 892734889

Archived Log entry 94 added for thread 1 sequence 98 ID 0xfad4f44b dest 1:

Thu Oct 22 11:09:54 2015

ARC2: Becoming the 'no SRL' ARCH

 

 

從日誌上看，我們看到Oracle將普通Physical Standby切換到Snapshot Standby的過程，經過了如下步驟：

 

ü  建立出一個Flashback的恢復點；

ü  傳輸剩餘的Standby Redo Log日誌資訊；

ü  清理Standby端的online redo log日誌組；

ü  使用reset log方法，建立出新的朝代資料；

 

結束之後，可以看到Standby端的狀態變化為Snapshot Standby。

 

 

SQL> select open_mode, database_role, protection_mode from v$database;

 

OPEN_MODE            DATABASE_ROLE    PROTECTION_MODE

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

MOUNTED              SNAPSHOT STANDBY MAXIMUM PERFORMANCE