11g Active DataGuard初探
生活随笔
收集整理的這篇文章主要介紹了
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
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"
與50位技術專家面對面20年技術見證,附贈技術全景圖
如果想查看備庫中的數據情況,則只能使用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"
與50位技術專家面對面20年技術見證,附贈技術全景圖
總結
以上是生活随笔為你收集整理的11g Active DataGuard初探的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 申请Bing Search API
- 下一篇: BAT解密:互联网技术发展之路(5)-