oracle 10g dataguard 安裝配置說明及原理

 網上很多文章都只是介紹如何搭建Oracle Data Guard，但是很少有介紹到基本的概念和理論知識。同時官方文件是純英文的，對於英文不好的讀起來是非常痛苦。本人因為是英文專業，結合官方文件和自己所學，整理了以下這些文字，和大家一起共同學習。同時感謝謝永生（Warehouse）和OCM群中的其他兄弟們，並以此文獻給口香糖同學新出生的兒子。

1．            Oracle Data Guard介紹：

Oracle Data Guard是Oracle資料庫高可用技術中的一種，通過資料冗餘為企業級資料庫提供高可用，資料保護和災難恢復。Data Guard 通過日誌同步機制，在主備庫之間實現資料同步，由於相互之間是通過網路連線，所以每個庫可以放置在不同的地理位置，只要保證網路連線通暢即可。如果主庫發生計劃中或者異常停機，Data Guard可以將任何1臺Standby資料庫切換成Primary資料庫繼續提供服務。

 

1.1.         Primary資料庫：

Data Guard配置中包含1臺生產資料庫，這臺資料庫可以是單例項也可以是RAC叢集，負責對外提供大部分服務，在Data Guard中這臺的角色就是Primary。

 

1.2.         Standby資料庫：

在一套Data Guard中最多可以有9臺Standby資料庫，Primary資料庫通過網路將日誌傳輸到Standby資料庫，然後Standby在接收完日誌後進行應用，以實現主備庫之間的資料同步和事務一致性。和Primary資料庫一樣，Standby資料庫也可以是單例項或者RAC叢集。根據Redo Log的應用方式不同，Standby資料庫又可以分為物理Standby和邏輯Standby。另外Data Guard是通過控制檔案來識別Primary和Standby資料庫的，所以Standby資料庫的控制檔案一定不能用作業系統複製，一定要通過命令ALTER DATABASE CREATE STANDBY CONTROLFILE AS來進行建立。

 

1.2.1.   物理Standby：

物理Standby使用的是Media Recovery技術，通過Redo Apply，使用從主庫接收到的Redo Log進行恢復，是基於block級的恢復，所以主備庫中所有的schema都是完全一樣的。物理Standby必須在mount階段才能進行恢復，但是能通過只讀方式開啟，在10g版本中如果以只讀方式開啟的話就無法進行恢復操作。所以在某些情況下，Standby可以分擔一部分查詢和備份的壓力，但是Data Guard還不能作為效能優化的解決方案。

 

1.2.2.   邏輯Standby：

邏輯Standby使用的是Log Miner技術，把Redo Log中的內容還原成SQL語句，通過SQL Apply在備庫執行SQL語句來實現資料同步。Log Miner不支援所有的資料型別，不支援的型別可以在DBA_LOGSTDBY_UNSUPPORTED檢視中進行檢視。邏輯Standby可以在恢復的同時進行寫操作。

 

1.3.         Data Guard保護模式

1.3.1.   最大保護模式Maximum protection

在這種模式下，能夠確保在Primary當機時資料沒有任何丟失。在事務提交之前，Primary資料庫將Redo Log寫入本地Online Redo Log，同時寫入Standby資料庫的Standby Redo Log，並且確保至少Redo Log在一個Standby資料庫上可用，這樣事務才會被提交，否則Primary會被shutdown。

 

1.3.2.   最高可用模式Maximum availability

最高可用和最大保護類似，也是確保Redo在寫入本地Online Redo Log和至少一個Standby資料庫的Standby Redo Log，事務才會被提交。但是和最大保護不同的是，如果發生故障（如網路中斷）導致Redo Log無法被寫入Standby資料庫時，Data Guard會自動切換到最高效能模式，而不是shutdown Primary資料庫。當故障排除，Redo Log的gap被解決之後，Data Guard會自動切換回最高可用模式。

 

1.3.3.   最高效能模式Maximum performance

Data Guard預設模式。在這種模式下，Primary資料庫在寫入本地Online Redo Log之後就提交事務，寫入Standby Redo Log是非同步的，所以對於Primary效能影響是最小的。

 

1.3.4.   設定Data Guard保護模式

	Maximum protection 最大保護	Maximum availability 最高可用	Maximum performance 最高效能
Redo歸檔程式	LGWR	LGWR	LGWR或ARCH
網路傳輸模式	SYNC	SYNC	如使用LGWR: SYNC或ASYNC 如使用ARCH: SYNC
磁碟I/O模式	AFFIRM	AFFIRM	AFFIRM或NOAFFIRM
是否必需Standby Redo Log	是	是	否，但是建議建立

改變Data Guard保護模式可以在Primary資料庫（mount階段）執行SQL語句：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY｜ PERFORMANCE}，另外通過SQL語句：SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE 可以檢視當前資料庫的保護模式。

 

1.4.         跨平臺Data Guard 配置條件

除了相同的作業系統平臺，Data Guard支援跨作業系統。

Oracle版本必須是10g及以上，同時Primary和Standby的作業系統必須有相同的位元組序（同為big endian或者little endian），可以通過查詢檢視V$TRANSPORTABLE_PLATFORM獲取資訊。

 

2．            Online Redo Logs,Archived Redo Logs, and Standby Redo Logs

2.1.         Online Redo Logs

Primary資料庫和邏輯Standby資料庫都會用到Online Redo Log，但是物理Standby資料庫是不使用Online Redo Log的，因為物理Standby只能以只讀方式開啟，不會有寫操作，所以不會有Redo Log產生。

2.2.         Archived Redo Logs

Primary資料庫和Standby資料庫（邏輯和物理）都需要用到Archived Redo Log，來保證Primary和Standby的事務一致性。

2.3.         Standby Redo Logs

Standby Redo Log是Standby資料庫用來存放從Primary資料庫接收到的Redo Log的，以下幾種情況必須要使用Standby Redo Log：

? 最大保護和最高可用模式 見1.3 Data Guard保護模式。

? Real-time apply

? Cascaded destinations

Standby Redo Log組的數量必須不少於Primary資料庫的Online Redo Log組的數量，建議比Online Redo Log多1組。可以通過觀察RFS程式的trace檔案或者alert.log，如果日誌中記錄了RFS程式頻繁等待歸檔程式的話，就需要增加Standby Redo Log組。

SQL語句ALTER DATABASE ADD STANDBY LOGFILE GROUP 1(‘/disk1/stdlog1a.rdo’, ‘/disk2/stdlog1b.rdo’) size 20M; 用於新增一組Standby Redo Log。

SQL語句ALTER DATABASE ADD STANDBY LOGFILE MEMBER ‘/disk3/stdlog1c.rdo’TO GROUP 1; 用於在第1組Standby Redo Log中再增加一個member。

SQL語句ALTER DATABASE DROP STANDBY LOGFILE GROUP1; 用於刪除一組Standby Redo Log。

 

3．            Redo傳輸服務Redo transport services

Redo傳輸服務是用來自動將Primary資料庫產生的Redo Log傳輸到Standby資料庫，並且能自動處理因為網路故障導致的歸檔日誌gap。為了保障日誌傳輸的安全性，Oracle是通過SYS密碼來驗證的，所以必須確保Primary資料庫和所有的Standby資料庫密碼一致，並且引數REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE必須設定。

3.1.         Redo傳輸路徑的型別

? Data Guard Standby資料庫 邏輯或者物理Standby資料庫

? 歸檔日誌容器 類似於Data Guard，archive log repository也是使用Standby controlfile和pfile來啟動例項到mount階段，但是這個資料庫沒有資料檔案，無法進行切換，僅僅是用於儲存歸檔日誌。

? Stream實時下游捕獲資料庫 Oracle流複製技術，此處不做深入討論。

? Oracle Change Data Capture stagingdatabase

 

3.2.         使用LOG_ARCHIVE_DEST_n引數來設定Redo傳輸路徑

LOG_ARCHIVE_DEST_n引數一共有10個（n從1到10），每一個引數都必須使用LOCATION或者SERVICE屬性來指定傳輸路徑。對應的LOG_ARCHIVE_DEST_STATE_n引數用來控制其狀態，

LOG_ARCHIVE_DEST_STATE_n共有4種狀態：

? ENABLE 這是預設狀態，Redo傳輸服務會傳送日誌到引數指定的路徑。

? DEFER   表示路徑有效，但是未使用。Redo傳輸服務不會把日誌傳送到指定的路徑。

? ALTERNATE  表示路徑不可用，但是如果和該路徑設定為關聯的另外一個路徑失效的話，會切換成可用狀態。

? RESET    功能和DEFER一樣, 但是如果之前失效的話，會清除相關的錯誤資訊。

 

3.3.         LOG_ARCHIVE_DEST_n引數屬性詳解

3.1.1.   LOCATION和SERVICE屬性

每一個歸檔路徑必須設定LOCATION或SERVICE屬性，並且沒有預設值。

? LOCATION

LOCATION=local_disk_directory或者也可以設定成LOCATION=USE_DB_RECOVERY_FILE_DEST，表示使用DB_RECOVERY_FILE_DEST引數指定的路徑。通常設定了DB_RECOVERY_FILE_DEST引數後，LOG_ARCHIVE_DEST_10會隱式的設定為USE_DB_RECOVERY_FILE_DEST，即歸檔到flash_recovery_area。

? SERVICE

SERVICE屬性用於設定一個通過Oracle NET連線的遠端歸檔路徑，SERVICE=net_service_name。net_service_name必須在TNSNAMES.ORA中事先定義好，並且通過tnsping命令確保連線暢通。檢視V$ARCHIVE_DEST可以用來檢視相關的設定資訊。

 

3.1.2.   ARCH和LGWR屬性

該屬性指定Redo傳輸服務使用ARCn程式或者LGWR程式來傳輸Redo Log。預設值是ARCH。

? ARCH

ARCH模式是通過ARCn程式，在資料庫進行歸檔時將Redo Log寫入指定路徑。ARCH模式僅支援Data Guard中的最高效能模式。當Primary資料庫觸發了log switch事件，ARCn程式會開始本地歸檔，在歸檔成功之後，ARCn程式會將本地歸檔日誌（非Online Redo Log）傳輸到Standby資料庫。在Standby資料庫上RFS程式（Remote File Server Process）會將日誌依次寫入歸檔日誌，寫完之後MRP程式（物理Standby）或者LSP程式（邏輯Standby）會將日誌應用到Standby資料庫。檢視V$ARCHIVED_LOG檢視可以檢查歸檔日誌是否成功寫入。

? LGWR

LGWR模式在每一次commit之後，LGWR程式寫本地Online Redo Log，同步或者非同步（取決於SYNC和ASYNC）寫入LOG_ARCHIVE_DEST_n引數指定的路徑（Standby資料庫必須存在Standby Redo Logs），如果該路徑是遠端的，LGWR程式會呼叫LNSn程式建立一個網路連線訪問遠端的例項並由該程式負責傳輸日誌。在Standby資料庫上RFS程式（Remote File Server Process）會將接收到的Redo Log寫入Standby Redo Log中。Primary資料庫發起的log switch會同步引起Standby資料庫對Standby Redo Log進行歸檔，歸檔完成之後MRP程式（物理Standby）或者LSP程式（邏輯Standby）會在下一次歸檔完成之後將日誌應用到Standby資料庫。如果啟用了LGWR模式，在歸檔的時候除了本地歸檔就不會再觸發ARCH程式寫遠端歸檔路徑了，但是如果LGWR在寫目標路徑時失敗，則會自動轉換成ARCH模式，直到錯誤排除。

? 使用注意點

a.    如果不指定是ARCH或LGWR，則預設是ARCH。

b.   ARCH模式使用的是ARCn程式，LGWR模式則是使用LGWR程式。同一個歸檔路徑不能同時指定兩種模式，但是一個資料庫中的多個路徑可以使用不同的模式，比如LOG_ARCHIVE_DEST_2是ARCH，LOG_ARCHIVE_DEST_3是LGWR。

c.    如果通過ALTER SYSTEM修改了一個歸檔路徑的模式，比如從ARCH修改到LGWR，不是立刻生效的，必須等到下一次log switch才會生效。

 

3.1.3.   SYNC和ASYNC屬性

控制LGWR或ARCH程式在寫Redo Log時是同步還是非同步寫。

 

3.1.4.   AFFIRM和NOAFFIRM屬性

該屬性指定Redo傳輸服務在寫Archived Redo Log和Standby Redo Log時，磁碟I/O是否同步。

? AFFIRM

表示Redo傳輸服務在寫Archived Redo Log和Standby Redo Log時，Primary和Standby兩邊的磁碟I/O是同步的。並且只有在兩邊都成功寫入後，Log寫程式才會繼續。

? NOAFFIRM

預設值，表示Redo傳輸服務在寫Archived Redo Log和Standby Redo Log時是非同步的，Primary端的日誌寫程式不會等待Standby端寫Archived Redo Log和Standby Redo Log。

? 使用注意點

a.    當Data Guard為最大保護或最高可用模式，並且設定為LGWR和SYNC時，該引數自動設定為AFFIRM。

b.   如果指定了LGWR和AFFIRM，Primary和Standby兩邊日誌寫程式會同時寫Redo，直到兩邊的磁碟I/O都完成了使用者才能繼續操作。

c.    如果指定了ARCH和AFFIRM，ARCn程式會同步將Redo寫入本地歸檔目錄和遠端路徑，所以歸檔操作會消耗更長的時間。

d.   如果指定了ASYNC和AFFIRM，那麼Primary資料庫效能將不受影響。

e.   AFFIRM和NOAFFIRM對於Primary資料庫的Online Redo Log沒有影響。

 

重點：SYNC/ASYNC，AFFIRM/NOAFFIRM 這2對屬性單獨理解比較困難，需要結合起來一起分析。這2對屬性控制了Data Guard在做同步資料時的方式，同時也決定了Data Guard的保護模式。下面結合LGWR和ARCH來分別看這2對屬性是如何控制資料同步的。

LGWR模式：

在Primary資料庫產生commit事件之後，Primary資料庫通過LGWR程式寫Online Redo Log，此時LGWR程式會同步或者非同步（SYNC/ASYNC）寫入Standby Redo Log。如果該歸檔路徑是遠端的（歸檔路徑設定為SERVICE），那麼LGWR程式會呼叫LNSn程式，通過Oracle Net建立網路連線，然後往Standby資料庫傳輸Redo Log。在Standby資料庫，RFS程式（Remote File Server Process）在接收到LNSn程式傳輸來的Redo Log後，如果是AFFIRM，那麼RFS程式會在成功寫入Standby Redo Log之後返回給Primary資料庫一個處理結果，Primary資料庫的LGWR程式會進行等待直到Standby資料庫返回處理結果。如果是NOAFFIRM，那麼Standby資料庫的RFS程式在接收到Redo Log後，在寫入Standby Redo Log之前就返回給Primary資料庫處理結果，此時Primary資料庫的LGWR程式不會等待Standby資料庫的RFS程式寫Redo Log，因為已經提前收到了處理結果。

ARCH模式：

在Primary資料庫發起log switch事件之後，Primary資料庫會通過ARCn程式，將Online Redo Log進行歸檔，寫入本地歸檔路徑。並且會通過Oracle Net建立網路連線，同步或者非同步（SYNC/ASYNC）向Standby資料庫傳輸歸檔日誌（Archived Redo Log）。Standby資料庫的RFS程式在接收到ARCn程式傳輸來的Archived Redo Log後，如果是AFFIRM，那麼RFS程式會在寫完歸檔日誌之後返回給Primary處理結果，在RFS程式寫入期間，Primary資料庫的ARCn程式會進行等待。如果是NOAFFIRM，則RFS在寫歸檔日誌之前先返回處理結果，此時Primary的ARCn程式在收到返回結果後就不會再等待RFS寫歸檔日誌了。

 

3.1.5.   ALTERNATE屬性

該屬性用來指定當一組路徑失敗時，啟用替補歸檔路徑。

? 使用方法

Example 1. 自動fail over到替補歸檔路徑

LOG_ARCHIVE_DEST_1='LOCATION=/disk1MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_2='LOCATION=/disk2MANDATORY'

LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

 

Example 2. 使用不同的Oracle Net自動fail over到Standby資料庫上

LOG_ARCHIVE_DEST_1='LOCATION=/disk1MANDATORY'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 OPTIONALALTERNATE=LOG_ARCHIVE_DEST_3'

LOG_ARCHIVE_DEST_STATE_2=ENABLE

LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2OPTIONAL'

LOG_ARCHIVE_DEST_STATE_3=ALTERNATE

 

? 使用注意點

a.    ALTERNATE屬性是可選的，如果沒有指定，那麼在原始路徑fail之後是無法自動切換到其他的歸檔路徑上的。

b.   每一個LOG_ARCHIVE_DEST_n只能設定一個替補路徑。

c.    當前可用的歸檔路徑數量要符合LOG_ARCHIVE_MIN_SUCCEED_DEST引數的值（如果設定的話）。

d.   無法將自己設定為替補路徑。

e.   至少要有一個本地強制歸檔路徑。

f.     當一個路徑失效時，替補路徑會在下一次歸檔時才生效。

g.   如果設定了REOPEN屬性，並且MAX_FAILURE屬性為0，那麼ALTERNATE將無效。如果同時設定了REOPEN和MAX_FAILURE，那麼只有當失效的歸檔路徑達到MAX_FAILURE指定的數量，ALTERNATE才會生效。

                                                                                                                                                                 

 

3.1.6.   LOG_ARCHIVE_MAX_PROCESSES引數

當LOG_ARCHIVE_DEST_n採用ARCH模式時該引數用於限制開啟ARCH的程式數量，最大值是30，可以通過ALTER SYSTEM來動態修改。預設情況下會自動開啟4個ARCH程式，並且自動進行負載均衡。

 

3.1.7.   VALID_FOR屬性

語法為：VALID_FOR=(redo_log_type, database_ role) 

redo_log_type的有效值為：ONLINE_LOGFILE,STANDBY_LOGFILE和ALL_LOGFILES。該引數指明瞭歸檔路徑log_archive_dest_n對哪種型別的日誌有效。

database_role的有效值為：PRIMARY_ROLE,STANDBY_ROLE和ALL_ROLES。該引數指明瞭歸檔路徑

log_archive_dest_n在哪個資料庫角色下生效。

如果未設定VALID_FOR屬性，預設相當於設定了VALID_FOR=(ALL_LOGFILES, ALL_ROLES)。

 

3.1.8.   DB_UNIQUE_NAME屬性

此處的DB_UNIQUE_NAME是指設定在LOG_ARCHIVE_DEST_n引數裡的，當LOG_ARCHIVE_DEST_n引數設定了SERVICE屬性，則必須同時設定DB_UNIQUE_NAME。

例如：

LOG_ARCHIVE_DEST_2='SERVICE=boston LGWRASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'

這個屬性的值和引數LOG_ARCHIVE_CONFIG以及引數DB_UNIQUE_NAME的值都對應，如果上述例子中，Standby資料庫（boston）的DB_UNIQUE_NAME不是boston，則LOG_ARCHIVE_DEST_2在歸檔到Standby資料庫時連線會被拒絕。

 

3.1.9.   REOPEN和MAX_FAILURE屬性

語法為：LOG_ARCHIVE_DEST_1='LOCATION=/arc_destREOPEN=60 MAX_FAILURE=3' ，REOPEN可以單獨使用，但是MAX_FAILURE必須和REOPEN一起使用。

REOPEN屬性用來設定該歸檔路徑是否會自動重試，單位為秒，預設值300秒。比如上例中如果第一次Redo傳輸失敗，那麼在60秒後，ARCn或者LGWR程式會嘗試重新傳輸日誌。如果REOPEN=0表示關閉重試功能。

MAX_FAILURE屬性用來設定連續失敗的次數。比如上例中如果傳輸日誌失敗後每隔60秒會重試，重試失敗3次後會關閉自動重試功能。

 

3.1.10.MANDATORY和OPTIONAL屬性

語法為：LOG_ARCHIVE_DEST_3= 'LOCATION=/arc_dest MANDATORY | OPTIONAL'

該屬性的含義是假如設定了MANDATORY，那麼在log switch之後，如果該歸檔路徑下的歸檔操作沒有成功，那麼對應的那一組Online Redo Log也不會被覆蓋和重用，只有在錯誤排除後那一組Online Redo Log才變為可用狀態。如果設定為OPTIONAL，那麼即使發生歸檔錯誤，Online Redo Log也會再次被標記為可用狀態。

預設值是OPTIONAL，但是即使所有的歸檔路徑都設定了OPTIONAL，仍然有一個本地歸檔路徑是MANDATORY以此來保證至少有一組歸檔日誌是可用的。

 

3.1.11. DEPENDENCY屬性

該屬性主要用於共享歸檔路徑，必須和SERVICE一起使用，並且不能設定NOREGISTER屬性。具體用法如下：

LOG_ARCHIVE_DEST_1='LOCATION=DISK1MANDATORY'

LOG_ARCHIVE_DEST_2='SERVICE=stdby1OPTIONAL'

LOG_ARCHIVE_DEST_3='SERVICE=stdby2OPTIONAL DEPENDENCY=LOG_ARCHIVE_DEST_2'

以上示例是指Primary資料庫將Redo Log傳輸到stdby1，但是不傳輸給stdby2，stdby2通過共享stdby1的Redo Log進行恢復。

 

3.1.12. DELAY屬性

語法為：LOG_ARCHIVE_DEST_3='SERVICE=stbyC  DELAY=120' 必須和SERVICE一起使用。

該屬性主要作用是設定Standby資料庫從接收到Redo Log到應用Redo Log恢復資料庫之間的時間間隔，單位是分鐘，預設是沒有延遲。從Standby資料庫接收到Redo Log並且完成歸檔動作之後開始計時，計時結束後才會應用Redo Apply去恢復資料庫。通過以下語句可以關閉DELAY：

物理Standby： ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

邏輯Standby： ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

 

3.1.13. MAX_CONNECTIONS屬性

語法為：LOG_ARCHIVE_DEST_3='SERVICE=denverMAX_CONNECTIONS=3'

通常情況下Redo傳輸服務只會使用一個網路連線來執行遠端歸檔，如果該屬性的值設定大於1，Redo傳輸服務會使用多個網路連線。但是該屬性同時受到LOG_ARCHIVE_MAX_PROCESSES和PARALLEL_MAX_SERVERS這兩個引數影響。

 

3.1.14. NET_TIMEOUT

該屬性必須在LGWR SYNC傳輸方式下使用，且僅對LNSn程式生效。單位是秒，預設是180秒。Primary資料庫通過LNSn程式傳送日誌給Standby資料庫，如果在NET_TIMEOUT引數指定時間內沒得到Standby資料庫的響應，則連線超時。如果是最大保護模式，那麼資料庫會在5分鐘內重試連線，而不會立即shutdown Primary資料庫。

 

3.1.15. NOREGISTER

如果SERVICE方式的歸檔路徑不是Data Guard配置中的一部分，那麼必須加上NOREGISTER。

 

3.1.16. TEMPLATE

設定歸檔日誌檔案的命名格式。僅對使用SERVICE的歸檔路徑生效，不能命名LOCATION方式的歸檔日誌。

 

3.1.17. VERIFY

指在完成歸檔操作後是否對歸檔日誌進行驗證。驗證操作需要較長的時間來完成，並且可能對Primary資料庫造成效能方面的影響。

 

 

3.4.         處理歸檔裂縫Archive Gap

Primary資料庫完成了本地歸檔，但是在傳輸給Standby資料庫時因為各種原因導致遠端歸檔失敗，那麼這部分丟失的日誌就是歸檔裂縫。

3.4.1.   自動處理歸檔裂縫

從Data Guard 10g版本開始，Primary資料庫每隔1分鐘會自動發起檢查，如果發現裂縫會自動進行修復，不需要人工進行干預。FAL（Fetch Archive Log）機制有2部分組成，FAL server和FAL client。FAL client的作用是自動發起傳輸歸檔日誌的請求，FAL server則響應請求並傳輸缺失的歸檔日誌。如果Data Guard中有多個Standby資料庫，FAL可以從其他的Standby資料庫那獲取歸檔日誌。

FAL機制可以處理以下幾種情況的日誌裂縫：

a.    在建立Data Guard時，通過Primary資料庫的熱備份集建立Standby資料庫後，FAL會自動檢索Primary資料庫的歸檔日誌並恢復Standby資料庫以進行同步。

b.   如果Standby資料庫的歸檔日誌在被應用之前就刪除了，FAL會重新傳輸一份歸檔日誌。

c.    因為磁碟錯誤等原因或者歸檔日誌被其他檔案覆蓋導致歸檔日誌無法被應用，FAL會重新傳輸一份歸檔日誌。

配置該功能需要2個引數FAL_SERVER和FAL_CLINET，這2個引數的值都是在tnsnames.ora中預先定義的Oracle網路服務名：

FAL_SERVER：指定FAL機制獲取歸檔日誌的來源，可以包含多個值，例如FAL_SERVER= primary_db,standby3_db。

FAL_CLIENT：指定FAL機制發起請求的客戶端，一般來說是Standby資料庫，例如FAL_CLIENT=standby1_db。

 

3.4.2.   手動處理歸檔裂縫

以下示例是物理Standby資料庫手動處理的過程：

Step 1. 查詢V$ARCHIVE_GAP檢視獲得歸檔裂縫。

Standby資料庫：

SQL> SELECT * FROM V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

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

1        7                 10

從檢視中看出7號到10號歸檔日誌丟失。

 

Step 2. 查詢V$ARCHIVED_LOG獲取歸檔裂縫所在的歸檔日誌檔案。

Primary資料庫：

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE#BETWEEN 7 AND 10;

NAME

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

/primary/thread1_dest/arcr_1_7.arc

/primary/thread1_dest/arcr_1_8.arc

/primary/thread1_dest/arcr_1_9.arc

 

Step 3. 將以上3個檔案copy到Standby資料庫的/standby路徑下，並註冊到Standby資料庫中。

Standby資料庫：

SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_7.arc’;

SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_8.arc’;

SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_9.arc’;

 

Step 4. 重啟Log Apply服務。

如果是邏輯Standby資料庫，則通過在邏輯Standby資料庫上查詢

DBA_LOGSTDBY_LOG檢視：

SQL> SELECT THREAD#, SEQUENCE#,FILE_NAME FROM DBA_LOGSTDBY_LOG L

2> WHERE NEXT_CHANGE# NOT IN

3> (SELECT FIRST_CHANGE# FROMDBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)

4> ORDER BY THREAD#,SEQUENCE#;

THREAD# SEQUENCE# FILE_NAME

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

1        6        /disk1/oracle/dbs/log-1292880008_6.arc

1       10       /disk1/oracle/dbs/log-1292880008_10.arc

將檔案編號中7-9的檔案從Primary資料庫伺服器copy到邏輯Standby資料庫伺服器上，並使用ALTER DATABASE REGISTER命令進行註冊，註冊後重啟Log Apply服務。

 

4．            日誌應用服務Log Apply Services

Standby資料庫的RFS程式在接收到傳來的日誌之後，會寫入本地的Standby Redo Log或者Archived Log中，取決於LGWR和ARCH（詳見3.3.4）。在Standby Redo Log歸檔完成之後或者Archived Log寫完之後，MRP程式（物理Standby）或者LSP程式（邏輯Standby）會將日誌應用到Standby資料庫。根據日誌應用型別的不同，Standby分為物理Standby（Redo Apply）和邏輯Standby（SQL Apply）（詳見1.2）。

4.1.         Redo Apply （物理Standby）

預設情況下，在Standby Redo Log歸檔之後，MRP程式才會開始恢復資料庫。但是在LGWR SYNC模式下可以開啟實時應用，或者設定DELAY屬性開啟延時應用。

? 開啟Redo Apply：

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE; 開啟前臺Redo Apply，開啟之後該命令列視窗會停留在Redo Apply階段並且無法響應其他操作，直到其他的session終止了日誌應用。

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE {DISCONNECT | DISCONNECT FROM SESSION}; 開啟後臺Redo Apply，開啟之後Redo Apply將在後臺進行，命令列視窗可以繼續操作。

 

? 開啟Redo Apply實時應用：

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE USING CURRENT LOGFILE;

 

? 設定Redo Apply延時應用：

設定LOG_ARCHIVE_DEST_n引數中的delay屬性（詳見3.3.11）

 

? 取消Redo Apply延時功能：

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE NODELAY;

 

? 關閉Redo Apply：

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE CANCEL;

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE FINISH;

注意：cancel表示switchover, finish表示failover。

 

4.2.         SQL Apply （邏輯Standby）

邏輯Standby是通過LSP程式，在Redo Standby Log歸檔之後，通過log miner技術從Redo中還原出SQL語句並應用到Standby資料庫。

? 開啟SQL Apply：

SQL> ALTER DATABASE START LOGICALSTANDBY APPLY;

 

? 開啟SQL Apply實時應用：

SQL> ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

 

? 開啟SQL Apply延時應用：

方法同Redo Apply。

 

? 取消SQL Apply延時功能：

SQL> ALTER DATABASE START LOGICALSTANDBY APPLY NODELAY;

 

? 關閉SQL Apply：

SQL> ALTER DATABASE STOP LOGICALSTANDBY APPLY;

 

5．            角色切換

Data Guard角色切換有兩種方式：switchover 和 failover。    

5.1.         Switchover

5.1.1.   物理Standby

Switchover切換不會丟失資料，切換之後原先的Primary資料庫和Standby資料庫角色互換，並且每個資料庫在Data Guard配置中仍然繼續執行。切換必須從Primary資料庫發起，具體步驟如下：

Step 1. Primary資料庫檢查檢視V$DATABASE中的SWITCHOVER_STATUS列（SELECTSWITCHOVER_STATUS FROM V$DATABASE），如果是TO STANDBY則表示可以正常切換，如果是SESSIONS ACTIVE，在切換時帶上WITH SESSION SHUTDOWN 子句也可以成功切換。

 

Step 2. Primary資料庫發起switchover切換，ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; 切換之後重啟例項 SHUTDOWN IMMEDIATE; STARTUPMOUNT;

 

Step 3. Standby資料庫檢查檢視V$DATABASE中的SWITCHOVER_STATUS列（SELECTSWITCHOVER_STATUS FROM V$DATABASE），如果是TO PRIMARY則表示可以正常切換，如果是SESSIONS ACTIVE，在切換時帶上WITH SESSION SHUTDOWN 子句也可以成功切換。

 

Step 4. Standby資料庫切換Primary資料庫，ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 如果該Standby資料庫從上次啟動例項之後從未以read-only模式開啟過，則直接ALTER DATABASE OPEN; 否則需要重啟例項 SHUTDOWNIMMEDIATE; STARTUP;

 

Step 5. 如果必要的話，重啟新Standby資料庫的Log Apply服務 ALTER DATABASE RECOVER MANAGED STANDBYDATABASE; （詳見4.1）。

 

5.1.2.   邏輯Standby

同物理Standby一樣，switchover也必須從Primary資料庫發起。

Step 1. Primary資料庫檢查檢視V$DATABASE中的SWITCHOVER_STATUS列（SELECT SWITCHOVER_STATUS FROM V$DATABASE），如果是TO STANDBY或SESSIONS ACTIVE則表示可以正常切換。

 

Step 2. Primary資料庫執行SQL語句ALTER DATABASE PREPARE TO SWITCHOVER TOLOGICAL STANDBY;這一句SQL的作用是通知當前的Primary資料庫準備切換至Standby，並從新的Primary資料庫接收Redo Log。 此時V$DATABASE檢視中SWITCHOVER_STATUS列的狀態是PREPARING SWITCHOVER。

 

Step 3. Standby資料庫執行SQL語句ALTER DATABASE PREPARE TO SWITCHOVER TOPRIMARY; 這一句SQL的作用是在Standby資料庫上啟動Redo傳輸服務，此時該Standby資料庫會將Redo Log傳輸到當前的Primary資料庫和其他的Standby資料庫，但是不做應用。

 

Step 4. Primary資料庫檢查檢視V$DATABASE中的SWITCHOVER_STATUS列，在Step3完成後（LogMiner Multiversioned Data Dictionary被當前Primary資料庫接收完成），SWITCHOVER_STATUS狀態將變更為TO LOGICAL STANDBY。此時可以取消switchover切換，Primary和Standby分別執行SQL語句：ALTER DATABASE PREPARE TO SWITCHOVERCANCEL;

 

Step 5. Primary資料庫執行ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; 切換到Standby資料庫。檢查檢視V$DATABASE中的SWITCHOVER_STATUS列，如果是TO_PRIMARY表示切換成功。

 

Step 6. Standby資料庫執行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 切換到Primary資料庫。

 

Step 7. 在新的Standby資料庫（即原先的Primary資料庫）執行ALTER DATABASE START LOGICAL STANDBY APPLY; 開啟SQL APPLY。

 

5.2.         Failover

5.2.1.   物理Standby

如果使用了failover切換，那麼故障的Primary資料庫將會被踢出Data Guard配置。大部分情況下，除了將被切換成Primary資料庫的那臺Standby資料庫，其餘的Standby資料庫在failover切換之後將繼續在Data Guard中正常執行，不需要重啟或作其他操作。在少數情況下，會需要為新的Primary資料庫重做這些Standby，具體情況下面會描述到。如果要進行failover切換，請按照以下的步驟，不要使用ALTER DATABASE ACTIVATE STANDBY DATABASE;語句，否則會造成資料丟失。另外如果Data Guard不是最大保護或者最高可用的話，也會丟失部分資料。

Step 1. 解決gap（詳見3.4）。如果Data Guard為最大保護或者最高可用，那麼在Primary故障發生時是沒有gap的，所以可以直接跳到Step4進行操作。

 

Step 2. 重複Step1直到沒有gap。

 

Step 3. 待切換的Standby資料庫檢查檢視V$ARCHIVED_LOG，查出最高的日誌序列號 SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BYthread#) AS LAST from V$ARCHIVED_LOG; 從Primary資料庫的歸檔日誌路徑下，找到任何比之前查詢到的最高序列號更高的日誌，並copy到Standby資料庫，使用SQL語句ALTER DATABASE REGISTER PHYSICAL LOGFILE'filespec1'; 進行註冊。完成之後重複Step1，確保沒有gap。

 

Step 4. 從Standby資料庫發起failover切換。ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE; FORCE關鍵字表示讓RFS程式直接終止，而不等待網路超時。

 

Step 5. 執行SQL語句ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 切換成Primary資料庫。在執行完這一句SQL語句之後，目標Standby資料庫將切換成Primary資料庫，切換之後該資料庫將無法再被作為Standby資料庫，並且從老的Primary資料庫再傳來任何Redo也無法被應用。Data Guard中其餘的Standby資料庫將不需要重啟，自動從新的Primary資料庫接收日誌並應用，當然前提是歸檔路徑配置正確。

 

Step 6. 這一步是否需要取決於該Standby資料庫從上次啟動到現在是否曾經以只讀模式開啟，如果開啟過，則需要重啟，如果沒有則直接open即可。

 

Step 7. 備份新的Primary資料庫。

 

5.2.2.   邏輯Standby

Step 1. 將Primary資料庫上會傳輸過來的歸檔日誌copy到Standby資料庫並註冊。（詳見3.4.2）

 

Step 2. 檢查檢視SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS; 如果APPLIED_SCN和LATEST_SCN值相同，則表示Standby恢復的資料和Primary相同。如果Standby資料庫沒有啟用SQL APPLY，則可以通過SQL語句ALTER DATABASE START LOGICAL STANDBY APPLYFINISH; 開啟。

 

Step 3. 檢查LOG_ARCHIVE_DEST_2是否配置，VALID_FOR屬性是否正確配置。如果沒有，先配置好。（詳見3.3）

 

Step 4. Standby資料庫執行ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY; 這句語句會終止RFS程式，並且將Standby Redo Log中還未應用的日誌進行應用，然後停止SQL APPLY，將資料庫切換為Primary資料庫。如果沒有加FINISH APPLY，那麼Standby Redo Log中的日誌將不會被應用。

 

Step 5. 在原先Data Guard配置中其餘的Standby資料庫上執行以下三步，重新和新的Primary資料庫組成Data Guard。

              1. ALTER SESSION DISABLE GUARD;

              2.建立到新Primary資料庫的db link

              3.ALTER SESSION ENABLE GUARD;

 

Step 6. 在Standby資料庫上執行ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARYdblink; 這裡的dblink就是step 5建立的db link名字。

 

Step 7. 備份新的Primary資料庫。

 

 

6．            Data Guard物理Standby常用檢視

檢視名	資料庫角色	檢視內容描述
V$ARCHIVE_DEST	Primary, physical	顯示Data Guard配置中所有的歸檔路徑
V$ARCHIVE_DEST_STATUS	Primary, physical	顯示歸檔路徑的配置資訊和狀態
V$ARCHIVE_GAP	Primary, physical	顯示歸檔日誌gap，用於在failover切換時處理歸檔裂縫
V$ARCHIVED_LOG	Primary, physical	顯示控制檔案中儲存的歸檔日誌資訊
V$DATAGUARD_CONFIG	Primary, physical	列出Data Guard中所有的DB_UNIQUE_NAME和 LOG_ARCHIVE_CONFIG引數資訊
V$DATAGUARD_STATS	Primary, physical	顯示所有Primary上未能傳輸給Standby的Redo Log資訊，如果在Primary上查詢該檢視，那麼結果值將被清除。
V$DATAGUARD_STATUS	Primary, physical	顯示Data Guard中的事件資訊，同時這些資訊也會被記錄在alert.log中和其他的trace檔案中
V$MANAGED_STANDBY	Physical only	顯示當前Standby的所有狀態資訊
V$STANDBY_LOG	Primary, physical	顯示所有的Standby Redo Log資訊

 

 

 

7．            Data Guard 初始化引數

引數名	Primary	Standby	描述
ARCHIVE_LAG_TARGET = seconds	YES	Physical only	可選，在指定的時間後強制發生log switch事件。
COMPATIBLE = release_number	YES	Logical and Physical	Data Guard最低版本要求是9.2.0.1.0 如果想進行switchover切換的話，Primary和Standby必須設定相同的release_number。
CONTROL_FILE_RECORD_KEEP_TIME = number_of_days	YES	Logical and Physical	可選，該引數可以防止記錄在制定天數內被覆蓋。
CONTROL_FILES = ( 'control_file_name' ,’ control_file_name', '...')	YES	Logical and Physical	必須，指定控制檔案路徑和檔名。
DB_FILE_NAME_CONVERT = (‘location_of_primary_database_datafile' , 'location_of_standby_database_datafile_name' , '...'	NO	Physical only	如果Standby和Primary上資料檔案儲存的路徑不同，則必須設定該引數。（在Standby上設定時，先寫Primary路徑，後寫Standby路徑）
DB_UNIQUE_NAME = unique_service_provider_name_for_this_database	YES	Logical and Physical	建議，如果設定LOG_ARCHIVE_CONFIG引數則必須設定該引數，用於唯一標識Data Guard中每個資料庫。
FAL_CLIENT = Oracle_Net_service_name	YES	Physical only	詳見3.4.1。
FAL_SERVER = Oracle_Net_service_name	NO	Physical only	詳見3.4.1。
INSTANCE_NAME	YES	Logical and Physical	可選，如果Primary和Standby在同一臺伺服器上，那麼可以通過指定該引數來區分例項。
LOG_ARCHIVE_CONFIG = 'DG_CONFIG=(db_unique_name, db_unique_name, ...)'	YES	Logical and Physical	建議，該引數會指定Data Guard中Primary和所有的Standby資料庫。
LOG_ARCHIVE_DEST_n = {LOCATION=path_nam  |SERVICE=service_name, attribute,attribute, ... }	YES	Logical and Physical	必須，詳見3.3。
LOG_ARCHIVE_DEST_STATE_n = {ENABLE|DEFER|ALTERNATE|RESET}	YES	Logical and Physical	必須，詳見3.2。
LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc	YES	Logical and Physical	可選，如果設定了STANDBY_ARCHIVE_DEST引數則必須。指定歸檔日誌檔案的命名規則。
LOG_ARCHIVE_LOCAL_FIRST = [TRUE|FALSE]	YES	NO	可選，如果是TRUE表示ARCn程式在傳輸給Standby之前，至少確保一組本地歸檔路徑歸檔完成。
LOG_ARCHIVE_MAX_PROCESSES = integer	YES	Logical and Physical	詳見3.1.5。
LOG_ARCHIVE_MIN_SUCCEED_DEST = integer	YES	NO	可選，至少有指定數量的歸檔路徑成功接收到Redo Log之後，Primary才會重用Online Redo Log
LOG_ARCHIVE_TRACE = integer	YES	Logical and Physical	可選，當Redo Log傳輸到Standby時進行跟蹤，有效值有(0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096)
LOG_FILE_NAME_CONVERT = 'location_of_primary_database_redo_logs', 'location_of_standby_database_redo_logs'	NO	Logical and Physical	同DB_FILE_NAME_CONVERT （在Standby上設定時，先寫Primary路徑，後寫Standby路徑）
PARALLEL_MAX_SERVERS = integer	YES	Logical only	必須，設定邏輯Standby資料庫中的最大並行程式數。該引數最小不能低於5，Oracle建議最小設定為9。具體計算方法為：（如果PGA_AGGREGATE_TARGET>0） PARALLEL_MAX_SERVERS=CPU_COUNT x  PARALLEL_THREADS_PER_CPU x 10
REMOTE_LOGIN_PASSWORDFILE = {EXCLUSIVE|SHARED]	YES	Logical and Physical	必須，在Data Guard所有節點上設定。
STANDBY_ARCHIVE_DEST = filespec	NO	Logical and Physical	可選，指定Standby接收歸檔日誌後的存放路徑，該引數會覆蓋LOG_ARCHIVE_DEST_n引數指定的路徑。 （10g開始可以不設定此引數）
STANDBY_FILE_MANAGEMENT = {AUTO|MANUAL}	YES	Physical only	必須，建議設定為AUTO，這樣在Primary建立或者刪除datafile時，Standby會自動進行同步操作。
USER_DUMP_DEST = directory_path_name_of_trace_file	YES	Logical and Physical	如果設定了LOG_ARCHIVE_TRACE引數則必須設定此引數。

 

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