1. 程式人生 > 其它 >11g Active DataGuard初探(r5筆記第54天)

11g Active DataGuard初探(r5筆記第54天)

原本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 1 row selected. 檢視日誌的應用情況,發現最新的記錄中日誌應用的需要為 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 1 row selected. 這個時候我們來啟用日誌應用,這個也是在11g中的特色了。 idle> recover managed standby database using current logfile disconnect from session; Media recovery complete. 這個時候檢視狀態就發生了細微的變化。 idle> select open_mode from v$database; OPEN_MODE -------------------- READ ONLY WITH APPLY 1 row selected. 這個時候為了驗證,我們從主庫做點什麼,比如建立一個小表看看備庫能夠在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 1 row selected. 這個時候在備庫中馬上檢視是沒有效果的。 ##### 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 alter system switch logfile; 備庫中的alert日誌顯示如下: ### standby log Mon Jun 01 22:59:57 2015 RFS[2]: Selected log 8 for thread 1 sequence 79 dbid 1028247664 branch 880742847 Mon Jun 01 22:59:57 2015 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: Mon Jun 01 22:59:57 2015 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; COUNT(*) ---------- 19 1 row selected. n1@TEST11G> show user USER is "N1"