11g Active DataGuard初探

原本dataguard中日志應用和資料庫隻讀查詢是一個互斥的關系，兩者不能并存。如果需要應用日志，則資料庫隻能在Mount狀态下 使用recover managed standby database disconnect from session來不斷地從背景進行日志應用。

如果想檢視備庫中的資料情況，則隻能使用recover managed standby database cancel來取消日志應用，然後把資料庫啟動到read only 狀态下。這種情況從道理上也講也是有理有據，但是終歸還是感覺不夠友善，畢竟我們希望備庫能夠起到一些作用，不隻是應用日志，一些大查詢可以直接在備庫上執行，能夠分擔主庫的壓力。11g的active dataguard就做到了這一點，重點就在于所說的active，是以這個時候資料庫啟動到了read only狀态下，而且可以同時應用日志。如果配置備庫的模式級别較高，甚至感覺和主庫是一緻的。

我們來簡單看看這個特性。

我們來看看備庫的資訊。

idle> select name,database_role from v$database;

NAME      DATABASE_ROLE

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

TEST11G   PHYSICAL STANDBY

1 row selected.

對應的Instance資訊。此時在Mount狀态。

idle> select instance_name,status from v$instance;

INSTANCE_NAME    STATUS

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

DG11G            MOUNTED

檢視日志的應用情況，發現最新的記錄中日志應用的需要為 78

idle>  select *from v$dataguard_status

Remote File Server       Warning                0          28          0 NO  01-JUN-15          RFS[2]: No standby redo logfiles of size 84490 blocks available

Log Apply Services       Informational          0          29          0 NO  01-JUN-15          Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_77_880742847.dbf

Log Apply Services       Warning                0          30          0 NO  01-JUN-15          Media Recovery Waiting for thread 1 sequence 78

30 rows selected.

我們在主庫切換一下日志。

#### primary database

alter system switch logfile;

備庫這邊很快得到相應，可見dataguard的日志應用是沒有問題的。這些部分和在10g中是一緻的。

########## standby alert log

Mon Jun 01 22:46:51 2015

RFS[2]: No standby redo logfiles of size 57697 blocks available

RFS[2]: Opened log for thread 1 sequence 78 dbid 1028247664 branch 880742847

Archived Log entry 110 added for thread 1 sequence 78 rlc 880742847 ID 0x3d942dcb dest 2:

Mon Jun 01 22:46:54 2015

Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_78_880742847.dbf

Media Recovery Waiting for thread 1 sequence 79

這個時候我們取消日志應用，把資料庫啟動起來。

idle> recover managed standby database cancel;

Media recovery complete.

idle> alter database open;

Database altered.

這個時候檢視資料庫的狀态是read only.

idle> select open_mode from v$database;

OPEN_MODE

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

READ ONLY

這個時候我們來啟用日志應用，這個也是在11g中的特色了。

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

這個時候檢視狀态就發生了細微的變化。

READ ONLY WITH APPLY

這個時候為了驗證，我們從主庫做點什麼，比如建立一個小表看看備庫能夠在open狀态也能應用日志。

主庫中執行。

sys@TEST11G> conn n1/n1

Connected.

n1@TEST11G> create table aaa as select *from cat;

Table created.

n1@TEST11G> select count(*)from aaa;

  COUNT(*)

----------

        19

這個時候在備庫中馬上檢視是沒有效果的。

##### standby datababse

n1@TEST11G> select *from aaa;

select *from aaa

             *

ERROR at line 1:

ORA-00942: table or view does not exist

n1@TEST11G> show user

USER is "N1"

n1@TEST11G> 

這個時候我們嘗試切一下主庫的日志，看看備庫有啥反應。

#### primary 

備庫中的alert日志顯示如下：

### standby log

Mon Jun 01 22:59:57 2015

RFS[2]: Selected log 8 for thread 1 sequence 79 dbid 1028247664 branch 880742847

Archived Log entry 111 added for thread 1 sequence 79 ID 0x3d942dcb dest 1:

Archived Log entry 112 added for thread 1 sequence 79 ID 0x3d942dcb dest 3:

Media Recovery Log /u02/dg11g/switchover/DG11G/archivelog/1_79_880742847.dbf

Media Recovery Waiting for thread 1 sequence 80

這個時候再次在備庫檢視，就發現資料變更都同步過來了。

n1@TEST11G> select count(*) from aaa;