【導(dǎo)讀】Dataguard是ORACLE推出的一種高可用性的數(shù)據(jù)庫方案,RAC的技術(shù)。在8i之前稱之為standbydatabase，從9i開始，正式更名為Dataguard，它是在主節(jié)。點與備用節(jié)點間通過日志同步來保證數(shù)據(jù)的同步，可以實現(xiàn)快速切換與災(zāi)難性恢復(fù)。果是在實時應(yīng)用模式則理論上主備庫的數(shù)據(jù)應(yīng)該是一樣的）。所以如果在主庫出現(xiàn)故障的情。況下會丟失這部分未歸檔的數(shù)據(jù)。當(dāng)然這是最壞的一種情況。不創(chuàng)建數(shù)據(jù)庫和實例。主備數(shù)據(jù)庫所在操作系統(tǒng)版本以及位數(shù)要求一樣。同一個dataguard環(huán)境中數(shù)據(jù)庫名必須一樣。如果已經(jīng)是歸檔模式則跳。如果在執(zhí)行forcelogging時有nologging之類的語句在執(zhí)行，則force. logging會等待直到這類語句全部執(zhí)行。FORCELOGGING是做為固定參數(shù)保存在控制文。增加以下參數(shù)，如果在初始化參數(shù)已經(jīng)有配置，則看需要做相應(yīng)的修改。庫db)，以逗號分隔。指定參數(shù)值為ENABLE，標(biāo)示對應(yīng)的LOG_ARCHIVE_DEST_n參數(shù)是否有效。推薦設(shè)置參數(shù)值為EXCLUSIVE或者SHARED，注意保證相同DataGuard配置中所有db服務(wù)。指定歸檔文件格式。一般也不用修改，保持默認(rèn)即可。庫角色相互轉(zhuǎn)換后不需要做修改dataguard也能正常運行。

　　

【正文】 arch/ 7 YES /opt/arch/ 8 YES /opt/arch/ 9 YES /opt/arch/ 10 YES /opt/arch/ 11 YES /opt/arch/ 12 YES /opt/arch/ 13 YES 如果有發(fā)現(xiàn)日志不連 續(xù)，則需要對照主庫的歸檔日志序列，判斷是否有丟失的日志，如果有則 需要手動注冊日志并應(yīng)用歸檔。（方法：從主庫的歸檔目錄拷貝相應(yīng)的歸檔文件到備庫上注冊 alter database register physical logfile 39。/opt/arch/歸檔文件名 ’ 。然后 手動應(yīng)用日志 alter database recover automatic standby database。 在 測試過程中發(fā)現(xiàn) oracle10G下 把丟失的 歸檔日志 文件考入指定目錄會自動注冊，不需手動注冊。 ） 4， select process,status from v$managed_standby。 查詢主備庫上的進程信息。 5， select message_num,message from v$dataguard_status。 查看 dataguard的狀態(tài)信息。 6, select * from v$archive_gap。 在備庫檢查是否有日志缺失 主備庫的切換 方法 主備庫的切換主要在兩種情況下切換， Switchover和 Failover ，這兩種切換都需要手工執(zhí)行完成。 一是 Switchover（計劃中的切換，不會丟失數(shù)據(jù)） 二是 Failover（ 當(dāng)主庫出現(xiàn)故障的時候需要主備庫切換角色 ） 1， Switchover的 切換方法 主庫端： select switchover_status from v$database。 如果是 to standby 表可以正常切換 . 直接執(zhí)行 alter database mit to switchover to physical standby。 否則執(zhí)行 :alter database mit to switchover to physical standby with session shutdown。 shutdown immediate。 startup nomount。 alter database mount standby database。 alter database recover managed standby database disconnect from session。 備庫 端： select switchover_status from v$database。 如果 是 to_primary 表可以正常切換 . 執(zhí)行 : alter database mit to switchover to primary。 否則執(zhí)行 : alter database mit to switchover to primary with session shutdown。 shutdown immediate。 startup。 2， Failover切換方法 (1) 判斷主數(shù)據(jù)庫確實出現(xiàn)嚴(yán)重的硬件故障或其他原因?qū)е轮鲾?shù)據(jù)庫無法啟動。 (2) 在物理備用數(shù)據(jù)庫上檢查是否有 archive redo log gaps SQLSELECT THREAD, LOW_SEQUENCE, HIGH_SEQUENCE FROM V$ARCHIVE_GAP。 (3) 消除 archive redo log gaps 從主數(shù)據(jù)庫上或其他備份的地方把沒有傳到 物理備用數(shù)據(jù)庫 的 archive redo log傳到物理備用數(shù)據(jù)庫上，并注冊到物理備用數(shù)據(jù)庫的 controlfile中。 SQL ALTER DATABASE REGISTER PHYSICAL LOGFILE 39。archive redo log文件名稱 39。 重復(fù) 2,3步驟直到 V$ARCHIVE_GAP 視圖無記錄存在。 (4） 在物理備用數(shù)據(jù)庫上發(fā)起 failover操作 SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE。 (5) 把物理備用數(shù)據(jù)庫轉(zhuǎn)化成主用角色 SQL ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY。 (6) 把新的主用數(shù)據(jù)庫重新啟動 SQL SHUTDOWN IMMEDIATE。 SQL STARTUP。 (7) 對新的主用數(shù)據(jù)庫做全備份 . 歸檔日志的處理 1， 物理備庫中已經(jīng)應(yīng)用的歸檔日志需定 期 刪除 . rman DELETE ARCHIVELOG ALL COMPLETED BEFORE 39。SYSDATE739。 刪除 7天前的歸檔日志文件。 刪除之后最好做一個全備份。 2， 先手動刪除歸檔日志文件，然后再 RMAN里執(zhí)行下面 2條命令 以更新控制文件 crosscheck archivelog all。 delete expired archivelog all。 3， 取消對備庫傳送日志 ALTER SYSTEM SET log_archive_dest_state_2=’DEFER’ 。 七、 常見故障 備庫重啟后，在主庫上歸檔出現(xiàn) ORA03113錯誤 SQL select dest_name,status,error from v$archive_dest。 DEST_NAME STATUS ERROR LOG_ARCHIVE_DEST_1 VALID LOG_ARCHIVE_DEST_2 ERROR ORA03113: endoffile on munication channel 解決辦法：在主庫執(zhí)行 SQL alter system set log_archive_dest_state_2= enable。 這個命令式手動觸發(fā)主庫區(qū)嘗試連接備庫。 其實這種情況下，只要保證主備庫之間的網(wǎng)絡(luò)和配置是正確的。 dataguard會自動恢復(fù)這個錯誤。 這個周期 默認(rèn)是 300 秒，也可以在 log_archive_dest_2 的參數(shù)中添加 reopen 參數(shù)指定這個主備庫之間失敗后繼續(xù)嘗試的周期 。 ORA01031: insufficient privileges 錯誤 SQL select dest_name,status,error from v$archive_dest。 DEST_NAME STATUS ERROR LOG_ARCHIVE_DEST_1 VALID LOG_ARCHIVE_DEST_2 ERROR ORA01031: insufficient Privileges 解決辦法：統(tǒng)一主備庫的數(shù)據(jù)庫密碼文件，或者重建密碼文件， sys密碼設(shè)置成一樣。 并查看主庫和備庫 ：主庫 orapwGMMDB, 備庫 orapwGMMDB_DG1。 然后 在主庫執(zhí)行 SQL alter system set log_archive_dest_state_2= enable。 ORA16191: Primary log shipping client not logged on standby SQL select dest_name,status,error from v$archive_dest。 DEST_NAME STATUS ERROR LOG_ARCHIVE_DEST_1 VALID LOG_ARCHIVE_DEST_2 ERROR ORA16191: Primary log shipping client not logged on standby 解決辦法：統(tǒng)一主備庫的數(shù)據(jù)庫密碼文件，或者重建密碼文件， sys密碼設(shè)置成一樣。 然后在主庫執(zhí)行 SQL alter system set log_archive_dest_state_2= enable。 發(fā)現(xiàn)備庫一直無法應(yīng)用日志， MRP0 進程顯示W(wǎng)AIT_FOR_GAP 的問題 發(fā)現(xiàn)從主庫傳來的日志無法應(yīng)用 在備庫檢查 , SQL select sequence,applied from v$archived_log。 SEQUENCE APP ——— — 930 NO 931 NO 932 NO 933 NO 934 NO 935 NO 936 NO 937 NO 938 NO 939 NO 940 NO 然后開始查看有沒有 mrp [oracle@HJITBACKUP bdump]$ ps ef | grep mrp oracle 31896 1 0 14:37 ? 00:00:00 ora_mrp0_flow oracle 32020 31820 0 15:17 pts/1 00:00:00 grep mrp 看來有，接著查 gap，發(fā)現(xiàn)備庫上有此進程， SQL select * from v$archive_gap 2 。 no rows selected 查詢視圖沒有發(fā)現(xiàn)， 在接著檢查 V$MANAGED_STANDBY SQL select process,status from v$managed_standby。 PROCESS STATUS ——— ———— ARCH CONNECTED ARCH CONNECTED MRP0 WAIT_FOR_GAP RFS IDLE RFS IDLE 發(fā)現(xiàn) MRP0在等待 GAP,進一步查看此視圖 select process,status,group,thread,sequence,block,blocks from v$managed_standby。 PROCESS STATUS GROUP THREAD SEQUENCE BLOCK BLOCKS ——— ———— ——— ——— ——— ——— ——— ARCH CONNECTED N/A 0 0 0 0 ARCH CONNECTED N/A 0 0 0 0 MRP0 WAIT_FOR_GAP N/A 1 928 0 0 RFS IDLE N/A 0 0 0 0 RFS IDLE N/A 0 0 0 0 發(fā)現(xiàn)日志 928沒有應(yīng)用， 原來是由于主庫刪除了 928，導(dǎo)致備庫沒法應(yīng)用，所以只能從備份中恢復(fù)， restore archivelog 至此問題處理完畢。 查 詢備庫狀態(tài) SQL select process,status from v$managed_standby。 PROCESS STATUS ——— ———— ARCH CONNECTED ARCH CONNECTED MRP0 WAIT_FOR_LOG RFS IDLE RFS IDLE 所以當(dāng) standby裝完后，在主庫切換日志后，這里狀態(tài)應(yīng)該是 MRP0 WAIT_FOR_LOG 才是正常的狀態(tài) 八、