Oracle10g Data Guard (Standby) 理論與實踐 2

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

LGWR SYNC -- LGWR寫資料到online redo log，LNSn程式訪問online redo log並傳輸資料到
             遠端standby的RFS

B.

  the log writer process writes to the local online redo log file,
while  LNSn processes asynchronously transmit the redo to remote destinations.
 
The LGWR process continues processing the next request without waiting for
the LNS network I/O to complete.

the LGWR submits the redo data to one or more network server (LNSn) processes, which then initiate the network I/O in

parallel to multiple remote destinations.

Transactions are not committed on
 the primary database until the redo data necessary to recover the transaction is received by all LGWR SYNC

destinations.

 

On the standby system, the remote file server (RFS) receives redo data over the network from the LGWR process and

writes the redo data to the standby redo log files.

 

 

 

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/datafile/','+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/onlinelog/','+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則
控制失敗嘗試的次數

 
http://tech.it168.com/db/2008-02-26/200802261700804.shtml