這章內容可說是又臭又長,但這章可是DG精華所在,希望能幫助你更了解DG。
Defining the redo transport mode
LOG_ARCHIVE_DEST_n說明
LOG_ARCHIVE_DEST_n(n 從1到10)定義redo檔案路徑。該參數定義必須透過location或service指明歸檔檔案路徑。location表示本地路 徑,service通常是net service name,即傳送redo的standby資料庫。
對於每一個LOG_ARCHIVE_DEST_n參數,還有一個對應的LOG_ARCHIVE_DEST_STATE_n參數。LOG_ARCHIVE_DEST_STATE_n參數用來指定對應的LOG_ARCHIVE_DEST_n參數是否生效,擁有4個屬性值
例如︰指定本地歸檔路徑
LOG_ARCHIVE_DEST_1='LOCATION=/oradata/pridg/'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
又比如,指定redo傳輸服務
LOG_ARCHIVE_DEST_2='SERVICE=pridg'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
當然,LOG_ARCHIVE_DEST_n參數的屬性遠不止這些。
這些參數都可以透過alter system set語句直接線上修改,修改會在primary下次日誌切換時生效,當然你直接shutdown再重啟資料庫的話也會生效
比如︰
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=pridg VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)';
除show parameter log_archive_dest外,還可以透過查詢V$ARCHIVE_DEST 查看參數配置,並且V$ARCHIVE_DEST 還可以看到更詳細的同步資訊。
使用ARCn歸檔redo資料
預設情況下,redo傳輸服務使用ARCn process歸檔redo日誌。不過ARCn歸檔 process只支援最高性能的保護模式。如果standby資料庫處於其它類型的保護模式,那你必須使用LGWR傳輸redo資料(想想為什麼ARCn process會這樣呢,我們知道對於最大保護和最高可用性兩種模式而言,其實強調的就是一點,redo資料必須及時應用於standby資料庫,我們再看來歸檔,歸檔是做什麼呢?是備份已完成切換的redolog,完成切換的redolog又說明著什麼呢?說明該redo中所有資料均已提交至datafile中(寫入硬碟),那再回過頭來看,資料已完成提交的redo並且完成了切換還被複製了一份做為歸檔,這個時候才準備開始傳輸到standby資料庫,這與最大保護和最高可用所要求的即時應用背道而馳,現在,應該明白為什麼ARCn歸檔 process 只能支援最高性能的保護模式)。
初始化參數控制ARCn歸檔行為
影響ARCn process的初始化參數有︰
LOG_ARCHIVE_DEST_n及LOG_ARCHIVE_MAX_PROCESSES。
關於LOG_ARCHIVE_DEST_n參數我們知道該參數的部分屬性與ARCn process相關,而 LOG_ARCHIVE_MAX_PROCESSES初始化參數則可看做是專為ARCn process設計,該參數用來指定最大可被調用的ARCn process的數量,我們指定的是最大值,也就是說資料庫在運行過程中是會根據歸檔的任務繁重程度自動調整歸檔 process數量的。當然如果說你覺得你的系統歸檔任務比較繁重,可以透過設定較多的歸檔 process數量提升歸檔速度,但是這個數字也不是越高越好,過高的歸檔 process數量有可能反而影響系統性能。調整該參數可以透過下列語句︰
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES = n;
注︰n>0 and n<=30
使用LGWR歸檔redo資料
使用LGWR process與使用ARCn process有明顯不同,LGWR無須等待日誌切換及完成歸檔。
Standby 資料庫的LGWR process會先選擇一個standby redo log檔案map primary資料庫當前redolog的sequence(含檔案大小,這也說明ORACLE為什麼建議standby redo size最好與online redo相同,因為直接mapping,減少DB再做一次搜尋比對過程),一旦primary資料庫有redo資料產生,視 LOG_ARCHIVE_DEST_n初始化參數中sync或async屬性設定,以同步或非同步模式傳輸到standby資料庫。
再來談談LGWR歸檔 process密切相關的幾個LOG_ARCHIVE_DEST_n參數的屬性,如果選擇LGWR歸檔redo資料,那麼在LOG_ARCHIVE_DEST_n中必須指定SERVICE和LGWR屬性以允許日誌傳輸服務使用LGWR process來傳送redo資料到遠端歸檔目錄。我們還需要指定SYNC(同步)還是ASYNC(非同步)的傳輸模式,如果指定SYNC屬性(預設是SYNC),則primary資料庫任何會產生redo操作都會同步觸發網路I/O,並且等到網路I/O全部完成才會繼續下面的提交,而如果指定了ASYNC屬性,則會primary資料庫的操作會先記錄online redologs,然後再傳輸到standby。
LGWR同步歸檔的流程
例如初始化參數中有如下設定︰
LOG_ARCHIVE_DEST_1='LOCATION=E:\oradata\sdb2\ '
LOG_ARCHIVE_DEST_2='SERVICE=pridg LGWR SYNC NET_TIMEOUT=30'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
如果設定LOG_ARCHIVE_DEST_n初始化參數SYNC屬性,建議同時設定NET_TIMEOUT屬性,該屬性控制網路連接的超時時間,如果超時仍無回應,則會返回錯誤訊息。
primary資料庫LGWR寫online redologs的同時,同步傳輸redo資料到standby資料庫一旦primary資料庫執行日誌切換,就會聯動觸發standby的ARCn將standby redo寫入歸檔,然後透過redo apply(MRP process)或sql apply(LSP process)讀取歸檔檔案將apply至standby資料庫。(如果啟用了及時應用 的話,MRP/LSP會直接讀取standby redolog並應用到standby資料庫,無須再等待歸檔)。
LGWR不同步歸檔的流程
例如初始化參數中有如下設定︰
LOG_ARCHIVE_DEST_1='LOCATION=E:\oradata\sdb2\ '
LOG_ARCHIVE_DEST_2='SERVICE=pridg LGWR ASYNC'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
ASYNC 模式歸檔就不需要再指定NET_TIMEOUT了,因為LGWR與LNSn之間已無關聯,所以指定不指定NET_TIMEOUT就都沒任何影響了,因此對於非同步傳輸而言,即使網路出現故障造成primary與standby之間通信中斷,也並不會影響到primary資料庫的提交。
大致步驟與同步傳輸相同,差別只在LNSn process這裡,LGWR寫資料到online redolog,LNSn process訪問online redolog並傳輸資料到遠端standby的RFS而不再與本地LGWR之間有聯繫。standby資料庫方面的處理邏輯仍然不變。
AFFIRM and NOAFFIRM
確認所有的archivelog files or standby redo log files全都傳輸成功並同步。
預設:NOAFFIRM(使用預設即可)
Delaying the application of redo
照字面上解釋就是設定archive redo log file延遲時間(預設30min) for standby DB。
但DB要是maximum protecion,maximum availablility還是會確保資料同步所以會忽略這參數設定又或者enable real-time apply這參數也會忽略。
相關參數屬性
ALTERNATE:設定替代路徑
LOG_ARCHIVE_DEST_3='SERVICE=sdb2_path1 REOPEN=0 ALTERNATE=LOG_ARCHIVE_DEST_4’
LOG_ARCHIVE_DEST_4='SERVICE=sdb2_path2 REOPEN=0 OPTIONAL'
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_ARCHIVE_DEST_STATE_4=ALTERNATE
設定了替代路徑 REOPEN=0(必須)
MAX_FAILURE:重試次數(傳送archive redo log),如有設定此參數那也一定要設定REOPEN。
NET_TIMEOUT:by pass netwotk timeout(預設180s)。
MAX_CONNECTIONS:傳送archive redo log file到達standby db by using parallel connections(max=5)。設定了此參數也一定要設定log_archive_max-processes且要大於max_connections。
Oracle10g Data Guard就在這先告一段落了,相信大家對DG在也不陌生了,在下一篇我將分享Oracle11g對Data Guard的改善。
補充:DG在Oracle 11g名稱為Active Data Guard,小弟有測試過一些新功能真是不賴(如果早點釋放出來就好了><),最大特點就是physical standby enable read only,同時還可開啟redo apply services,這在10gR2是不可能做到的(想要只有升級版本了),外加結合flashback技術所衍生出來的snapshot standby db,可說是測試DB的好功能,也修正了logical standby在同步上的限制...等。相關Oracle 11g Active Data Guard新特性等有空小弟再整理。