Oracle10g Data Guard (Standby) 理論與實踐 [final]

tolywang發表於2010-09-08


Oracle10g Data Guard (Standby) 理論與實踐 
 
 
 
簡單summary :

A. 日誌傳送 :
 
ARCH SYNC -- 將PRI DB上的歸檔透過RFS傳輸給Standby的歸檔或Standby Redo Log(如果有)。
 
LGWR SYNC -- LGWR提交redo資料到LNSn,LNSn啟動網路傳輸,standby資料庫的RFS將接收到
             的redo資料寫入standby redo log, Primary 上的事務不會提交直到用於恢復
             這個transaction所需的redo data被所有設定lgwr sync的遠端目的地接收到。
 
LGWR ASYNC -- LGWR寫資料到online redo log,LNSn程式訪問online redo log並非同步傳輸
              redo data 到遠端standby的RFS,Primary 上的LGWR程式會繼續執行下一個
             請求而不用等LNS Network I/O完成。
 
B. 日誌應用 :
一種是實時應用(Real-Time Apply), 這種方式必須Standby Redo Log,每當日誌被寫
入Standby RedoLog時,就會觸發恢復,使用這種方式的好處在與可以減少資料庫切換
(Switchover 或者Failover)的時間,因為切換時間主要用在剩餘日誌的恢復上。
 
另一種是歸檔時應用,這種方式在Primary Database發生日誌切換,觸發Standby
Database 歸檔操作,歸檔完成後觸發恢復。 這也是預設的恢復方式。
 
歸檔時應用:
Alter database recover managed standby database disconnect from session ;
 
Real-Time應用(物理):
Alter database recover managed standby database using current logfile
 disconnect from session ;
Real-Time應用(邏輯):
Alter database start logical standby apply immediate;
 

C.  注意: 日誌傳送和應用是兩回事 。
不管是arch sync, lgwr sync, lgwr async 方式,實時應用就是透過standby redo log
直接傳輸給MRP 程式進行恢復 ,   非實時傳輸就是需要Primary db的歸檔程式觸發
Standby上的歸檔程式對Standby redo log 進行歸檔,然後standby 上的歸檔日誌通
過MRP程式恢復到Standby .  
 

D. 資料保護模式  :
最大保護模式: 這種模式確保在primary失敗時沒有資料丟失,在Primary DB上的事
務提交前,可被用來recovery這個transaction的redo data必須寫入local online
redo log以及至少一個standby庫上的standby redo log . 為確保資料不丟失,如果
redo data不能寫入到至少一個standby庫的standby redo log,  Primary DB將
會shutdown.

最大可用模式: 預設情況下為最大保護模式,和最大保護模式不一樣的是,一旦redo
log不能同時寫入到所有的遠端standby redo log,primary DB將不會shutdown , 而是
以最大效能模式執行,直到問題被解除以及在redo log中的gap被解決,當所有gap都
解決後,primary db將自動回覆到最大可用模式操作。

最大效能模式:這種模式允許用於transaction恢復的redo data一寫入本地online
redo log就可以允許transaction提交, primary database的redo stream也被寫入
至少一個standby庫, 但是那些redo stream寫入standby庫相對於這個transaction
的提交是非同步的。  當網路足夠好時,它接近最高可用性,最大效能模式允許設定
lgwr async 及 arch .
 
 
 
 
------------------------------------------------------------------------------------------------------------------------------
 
 
 
1. ARCH網路傳輸模式
Primary DB中一旦ARC0完成redo log的歸檔,ARC1程式即開始傳輸該歸檔到Standby庫
指定的路徑,在Standby上的RFS(Remote File Server) 程式輪流將redo資料寫入standby
redo log,  再由standby上的ARCn程式將其寫入Standby歸檔日誌,然後透過redo應用
(物理備庫) 或 SQL應用(邏輯備庫)將資料應用到Standby庫 (物理備庫採用MRP程式-
Media Recovery process , 邏輯備庫採用LSP-Logical Standby Process) . 
備註: 如果是Real Time Apply,  直接從Standby redo log透過MRP或LSP應用到standby庫。
如果不存在Standby redo log檔案,那麼ARC1程式透過Net將歸檔傳送給Standby的RFS, RFS
把接收到的日誌寫入歸檔日誌,由MRP程式對歸檔進行應用。 
 
2. LGWR 網路傳輸模式
Standby資料庫的LGWR程式會先選擇一個standby redo log檔案對映primary資料庫當前
redo log的sequence(以及檔案大小),一旦primary資料庫有redo資料產生,會以同步(SYNC)
或非同步(ASYNC)方式傳輸到standby資料庫。
 
SYNC屬性(預設是SYNC):  primary資料庫任何時候產生redo操作都會同步觸發網路I/O,
並且等到網路I/O全部完成才會繼續下面的提交; 即  LGWR必須等待寫入本地日誌檔案
操作和透過LNSn程式的網路傳送都成功,Primary Database 上的事務才能提交 。
 
ASYNC屬性 : LGWR 把日誌同時提交給日誌檔案和本地LNS 程式,但是LGWR程式只需成功
寫入日誌檔案就可以,不必等待LNSn程式的網路傳送成功。
 
如果使用LGWR程式必須明確指定。使用LGWR SYNC方式時,可以同時使用NET_TIMEOUT參
數,這個引數單位是秒,代表如果多長時間內網路傳送沒有響應,LGWR 程式會丟擲錯誤。
示例如下:
alter system set log_archive_dest_2 = 'SERVICE=ST LGWR  SYNC NET_TIMEOUT=30'scope=both;
 

3. LGWR 網路傳輸工作流程
在primary資料庫,LGWR提交redo資料到LNSn  (LGWR Network Server process, 存在的
目的就是減輕LGWR程式的負擔)程式(n>0),LNSn啟動網路傳輸(傳輸給standby上的RFS)。
standby的RFS(Remote File Server)將接收到的redo資料寫入standby redo log。
一旦primary資料庫執行日誌切換,就會級聯觸發standby的ARCn將standby redo寫入
歸檔,然後透過redo應用(MRP程式)或sql應用(LSP程式)讀取歸檔檔案將資料應用至
standby資料庫。預設情況下,LGWR網路傳輸模式使用的是這種讀取歸檔檔案應用的
方式,即
SQL> alter database recover managed standby database disconnect from session;
這種不是實時應用的方式,如果需要修改為Real Time Apply ,需要:
SQL> alter database recover managed standby database using current
 logfile disconnect from session ;
如果啟用了實時應用的話,MRP/LSP會直接讀取standby redo log並應用到standby
資料庫,無須再等待歸檔 。
 
4. Redo 接收 .
Standby Database 的RFS(Remote File Server)程式接收到日誌後,就把日誌寫
到Standby Redo Log或者Archived Log檔案中,具體寫入哪個檔案,取決於Primary
的日誌傳送方式和Standby database的位置。如果寫到Standby Redo Log檔案中,
則當Primary Database發生日誌切換時,也會觸發Standby Database上的Standby
Redo Log 的日誌切換,並把這個Standby Redo Log 歸檔。 如果是寫到Archived
Log,那麼這個動作本身也可以看作是個歸檔操作。
 
5. Redo Apply .
根據Redo Apply發生的時間可以分成兩種:
 
一種是實時應用(Real-Time Apply), 這種方式必須Standby Redo Log,每當日誌被寫
入Standby RedoLog時,就會觸發恢復,使用這種方式的好處在與可以減少資料庫切換
(Switchover 或者Failover)的時間,因為切換時間主要用在剩餘日誌的恢復上。
 
另一種是歸檔時應用,這種方式在Primary Database發生日誌切換,觸發Standby
Database 歸檔操作,歸檔完成後觸發恢復。 這也是預設的恢復方式。
 
歸檔時應用:
Alter database recover managed standby database disconnect from session ;
 
Real-Time應用(物理):
Alter database recover managed standby database using current logfile
 disconnect from session ;
Real-Time應用(邏輯):
Alter database start logical standby apply immediate;
 

注意: 日誌傳送和應用是兩回事 。
LGWR SYNC 日誌傳送方式確定的情況下, 日誌實時應用與非實時應用的區別: 根據
oracle文件上的圖示,  不管是arch, lgwr sync, lgwr async 方式 ,  實時應用
就是透過standby redo log 直接傳輸給MRP 程式進行恢復 ,   非實時傳輸就是需
要Primary db的歸檔程式觸發Standby上的歸檔程式對Standby redo log 進行歸檔,
然後standby 上的歸檔日誌透過MRP程式恢復到Standby .  
 

5. 檢視相關檢視  .
檢視是否使用Real-Time apply:
Select recovery_mode from v$archive_dest_status;
select process,status,thread#,sequence#,client_pid from v$managed_standby;
 
 
6. Primary DB及Standby上的相關程式
在Primary DB中,相關的主要程式有:
 
LGWR:寫log程式, 用於將SGA中log buffer的內容寫入redo log檔案。
 
LNS(Logwriter Network Service):用於讀取LGWR程式flush的redo,並將其
傳輸到Standby。其存在的目的就是減輕LGWR程式的負擔。
 
ARCH:依然是將已經寫滿的ORL檔案進行歸檔。但是會有一個比較特殊的ARCH會
用於redo log gap的定位與恢復。
 
在Standby中,相關的程式有:
RFS(Remote File Server):接收PDB傳送的redo data,並將這些放入
network buffer中的內容寫入standby redo log(SRL)。
ARCH:同Primary上的ARCH程式作用類似,為standby redo log檔案產生相應的歸檔檔案。
MRP(Managed Recovery Process):用於協調介質恢復管理,喚起物理standby為
永久的恢復模式。它還負責將redo data從相應的SRLs或歸檔檔案中讀入到用於恢復的共享空間結構。
LSP(Logical Standby Process):該程式主要是在邏輯standby中協調SQL Apply的。
       
PR0x(recovery server Process):讀取SRL或歸檔日誌檔案中的redo,並將其應用於SDB上。
 
 
7. 資料保護模式
 
Data Guard 允許定義3鍾資料保護模式,分別是最大保護(Maximum Protection),最大可用(Maximum
Availability)和 最大效能(Maximum Performance)。
 
 
 
a. 最大保護(Maximum Protection)
 
這種模式能夠確保絕無資料丟失。要實現這一步當然是有代價的,它要求所有的事務在提交前其REDO不僅被
寫入到本地的Online Redologs,還要同時寫入到Standby資料庫的Standby Redologs,並確認REDO資料至少
在一個Standby資料庫中可用(如果有多個的話),然後才會在Primary資料庫上提交。如果出現了什麼故障
導致Standby資料庫不可用的話(比如網路中斷),Primary資料庫會被Shutdown,以防止資料丟失。
 
使用這種方式要求Standby Database 必須配置Standby Redo Log,而Primary Database必須使用LGWR,SYNC
,AFFIRM 方式歸檔到Standby Database.
 
最大保護:   
程式LGWR  
網路傳輸模式LGWR SYNC 
Standby Redo Log:   需要
磁碟寫操作:  AFFIRM
 

b. 最高可用性(Maximum availability)
 
這種模式在不影響Primary資料庫可用前提下,提供最高階別的資料保護策略。其實現方式與最大保護模式類
似,也是要求本地事務在提交前必須至少寫入一臺Standby資料庫的Standby Redologs中,不過與最大保護模
式不同的是,如果出現故障導致Standby資料庫無法訪問,Primary資料庫並不會被Shutdown,而是自動轉為
最高效能模式,等Standby資料庫恢復正常之後,Primary資料庫又會自動轉換成最高可用性模式。
 
這種方式雖然會盡量避免資料丟失,但不能絕對保證資料完全一致。這種方式要求Standby Database 必須配
置Standby Redo Log,而Primary Database必須使用LGWR,SYNC,AFFIRM 方式歸檔到Standby Database.
 
最大可用 :   
程式LGWR 
網路傳輸模式LGWR SYNC 
Standby Redo Log:   需要
磁碟寫操作:   AFFIRM
 
 

c. 最高效能(Maximum performance)
 
預設模式。 這種模式在不影響Primary資料庫效能前提下,提供最高階別的資料保護策略。事務可以隨時提
交,當前Primary資料庫的REDO資料至少需要寫入一個Standby資料庫,不過這種寫入可以是不同步的。如果
網路條件理想的話,這種模式能夠提供類似最高可用性的資料保護,而僅對Primary資料庫的效能有輕微影響
。這也是建立Standby資料庫時,系統的預設保護模式。
 
這種方式可以使用LGWR ASYNC 或者 ARCH 程式實現,Standby Database也不要求使用Standby Redo Log。
最大效能:
程式LGWR/ARCH    
網路傳輸模式LGWR SYNC/LGWR ASYNC/ARCH SYNC
Standby Redo Log:  LGWR時需要, ARCH傳輸時建議有.
磁碟寫操作:  NOAFFIRM
 
d. 修改資料保護模式步驟
 
1)關閉資料庫,重啟到Mount 狀態,如果是RAC,需要關閉所有例項,然後只啟動一個例項到mount狀態。
2)修改模式:
語法:ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY |
PERFORMANCE};
如:SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3) 開啟資料庫: alter database open;
4) 確認修改資料保護模式:
SQL>select protection_mode,protection_level from v$database;
 
 
注意: 日誌傳送, 日誌應用及三種模式沒有必然關係。 
 
 

 
8. 自動Archive GAP檢測和解決
 
 
當Primary Database的某些日誌沒有成功傳送到Standby Database, 這時候發生了歸檔裂
縫(Archive Gap)。
 
缺失的這些日誌就是裂縫(Gap)。 Data Guard能夠自動檢測,解決歸檔裂縫,不需要DBA
的介入。這需要配置FAL_CLIENT, FAL_SERVER 這兩個引數(FAL: Fetch Archive Log)。
這兩個引數都是在Standby上設定的。
從FAL 這個名字可以看出,這個過程是Standby Database主動發起的“取”日誌的過程,
Standby Database 就是FAL_CLIENT. 它是從FAL_SERVER中取這些Gap, 10g中,這個
FAL_SERVER可以是Primary Database, 也可以是其他的Standby Database。
 
如:FAL_SERVER='PR1,ST1,ST2';
 
FAL_CLIENT和FAL_SERVER兩個引數都是Tnsnames中設定的。 FAL_CLIENT 透過網路向
FAL_SERVER傳送請求,FAL_SERVER透過網路向FAL_CLIENT傳送缺失的日誌。 但是這
兩個連線不一定是一個連線。 因此FAL_CLIENT向FAL_SERVER傳送請求時,會攜帶
FAL_CLIENT引數值,用來告訴FAL_SERVER應該向哪裡傳送缺少的日誌。 這個引數
值也是一個Oracle Net Name,這個Name是在FAL_SERVER上定義的,用來指向
FAL_CLIENT.
 
當然,除了自動地日誌缺失解決,DBA 也可以手工解決。 具體操作步驟如下:
 
1) 檢視是否有日誌GAP:
SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
2) 如果有,則複製過來
3) 手工的註冊這些日誌:
SQL> ALTER DATABASE REGISTER LOGFILE '路徑';
 

9. 11g dataguard設定例子
 
三節點的Production DB初始化引數 
*.db_name='wsjdell'
*.db_unique_name='wsjdell'
 
# 下面的 fal_client及fal_server只需要在standby上設定,這裡設定是為了切換角色。
wsjdell1.fal_client='WSJDELL1'
wsjdell2.fal_client='WSJDELL2'
wsjdell3.fal_client='WSJDELL3'
*.fal_server='WSJDELLDG'
 
*.log_archive_config='DG_CONFIG=(wsjdell,wsjdelldg)'
*.log_archive_dest_1='LOCATION=+DATA mandatory alternate=log_archive_dest_3 noreopen VALID_FOR=
 
(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=wsjdell'
*.log_archive_dest_2='SERVICE=wsjdelldg LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=wsjdelldg'
 
*.log_archive_dest_3='LOCATION=+INDX mandatory'
*.log_archive_dest_state_3='ALTERNATE'
 

Standby DB初始化引數 
*.db_file_name_convert='+data/wsjdell/datafile/','+data/wsjdell/datafile/','+indx/wsjdell/dataf
ile/','+indx/wsjdell/d
 
atafile/'
*.db_name='wsjdell'
 
*.db_unique_name='wsjdelldg'
 
*.fal_client='wsjdelldg'
*.fal_server='wsjdell1','wsjdell2','wsjdell3'
*.log_archive_config='DG_CONFIG=(wsjdell,wsjdelldg)'
*.log_archive_dest_1='LOCATION=+DATA VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=wsjdelldg'
*.log_archive_dest_2='SERVICE=wsjdell LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=wsjdell'
--備庫中log_archive_dest_2可以不用設定,主要用於主庫備庫切換
*.log_archive_format='%t_%s_%r.arc'
*.log_file_name_convert='+data/wsjdell/onlinelog/','+data/wsjdell/onlinelog/','+indx/wsjdell/on
linelog/','+indx/wsjde
 
ll/onlinelog/'
*.standby_file_management='AUTO'
 
 
9. VALID_FOR
VALID_FOR=(redo_log_type, database_role). 
為指定角色設定日誌檔案的歸檔路徑,主要目的是為了輔助一旦發生角色切換操作後資料庫的正常運轉。
例子:
*.log_archive_dest_1='LOCATION=+DATA mandatory alternate=log_archive_dest_3 noreopen VALID_FOR=
 
(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=wsjdell'
 
redo_log_type可設定為:  ONLINE_LOGFILE, STANDBY_LOGFILE, ALL_LOGFILES
database_role可設定為:  PRIMARY_ROLE, STANDBY_ROLE,ALL_ROLES 
注意valid_for引數是有預設值的,如果不設定的話,其預設值等同於:
valid_for=(ALL_LOGFILES,ALL_ROLES)
推薦主動設定該引數而不要使用預設值,某些情況下預設的引數值不一定合適
 
比如邏輯standby就不像物理standby,邏輯standby處於open模式,不僅有redo資料
而且還包含多種日誌檔案(online redologs,archived redologs以及standby redologs)。
多數情況下,邏輯standby生成的online redologs與standby redologs生成在相同的目錄內。
因此,推薦你對每個*dest設定合適的valid_for屬性。
 
10 .  DB_UNIQUE_NAME
  db_unique_name引數是解決在同一臺計算機上存在多個相同的db_name的例項共存在而
增加的引數,  如果dataguard的主、備庫安裝在不同的計算機上,則不需要設定這個引數。
 
  如果安裝到同一臺計算機上,則需要設定,如果沒有設定例項的這個引數,第一個例項
啟動後,再啟動第二個例項是將報lk檔案無法鎖定的錯誤,第二個例項將無法啟動.
 
DB_UNIQUE_NAME在Dataguard會經常提及的,和DB_NAME不一樣的作用,在DG裡,要求物理DG
主從庫都有一樣的DB_NAME 。 這裡是資料庫的唯一名字。但是他們的DB_UNIQUE_NAME是不
一樣的,用以進行不同的標示。
 
 
11 .  LOG_ARCHIVE_CONFIG 
log_archive_config初始化引數還包括幾個屬性,可以用來控制資料庫的傳輸和接收,
SEND,NOSEND,RECEIVE,NORECEIVE:
SEND     允許資料庫傳送資料到遠端
RECEIVE  則允許standby接收來自其它資料庫的資料
NOSEND,NORECEIVE  自然就是禁止
 

12. REOPEN, MAX_FAILURE, ALTERNATE
例子:
LOG_ARCHIVE_DEST_1='LOCATION=E:\ora10g\oradata\jsspdg\ REOPEN=60 MAX_FAILURE=3'
使用REOPEN=seconds(預設=300)屬性,在指定時間重複嘗試向歸檔目的地進行歸檔
操作,如果該引數值設定為0,則一旦失敗就不會再嘗試重新連線併傳送,直到下次
redo資料再被歸檔時會重新嘗試,不過並不會歸檔到已經失敗的歸檔目的地,而是
向替補的歸檔目的地傳送。
 
alternate屬性定義一個替補的歸檔目的地,所謂替補就是一旦主歸檔目的地因各
種原因無法使用,則臨時向alternate屬性中指定的路徑寫。
需要注意一點,reopen的屬性會比alternate屬性優先順序要高,如果你指定reopen
屬性的值>0, 則lgwr/arch會首先嚐試向主歸檔目的地寫入,直到達到最大重試次
數,如果仍然寫入失敗,才會向alternate屬性指定的路徑寫。
*.log_archive_dest_3='LOCATION=+INDX mandatory'
*.log_archive_dest_state_3='ALTERNATE'
 
max_failure屬性指定一個最大失敗嘗試次數,大家應該能夠聯想到reopen,沒錯
兩者通常是應該配合使用,reopen指定失敗後重新嘗試的時間週期,max_failure則
控制失敗嘗試的次數
 

 
 
 
 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/35489/viewspace-708056/,如需轉載,請註明出處,否則將追究法律責任。

相關文章