這篇文章的動力來自於一個朋友的提問，他問我備庫的密碼檔案直接重建可以嗎，我說最好還是複製，如果重建可能會有一些潛在的問題，當然這個所謂潛在問題也是自己給自己打的馬虎眼，到底哪裡有問題，腦海裡搜尋了一番似乎沒有找到什麼有效的資訊，但是隱隱之中感覺搭建dataguard好像還從來沒有直接重建密碼檔案的時候，似乎是一種非常規的方式，但是轉眼一想一旦發生這種情況的時候，或者密碼檔案出現了一些潛在問題的時候，怎麼有效防範，這個問題就又上升了一個高度，所以我對這個問題做了一些初步的分析，然後在網上竟然看到還真有一些技術大拿對這類看起來細節問題做了深入的解析，我想我就不用再重新寫了，直接把他的成果拿過來分享給大家。 文章來自於下面的連結，感興趣可以看一下。 https://prutser.wordpress.com/2011/06/13/password-file-maintenance-in-a-data-guard-environment/ 自己簡單翻譯了一下。 這篇文章會提到另外一個問題：在dataguard環境中，對於密碼檔案的維護管理有什麼特別注意的地方嗎？ 答案是肯定的，在Data Guard環境中更新密碼檔案並沒有想象的那樣簡單。 我們首先看看我的當前dataguard配置情況，然後再來深入密碼檔案的一些細節過程。 DGMGRL> show configuration; Configuration - PeppiEnKokki Protection Mode: MaxPerformance Databases: peppi - Primary database kokki - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS

這個輸出可以看到當前存在一個主庫peppi,一個物理備庫kokki，dataguard環境整體的狀態是success. 特別需要說明的是peppi在host pruster，kokki執行在el5上

提出問題 第一個問題是：如果在主庫的密碼檔案做了變更，是否會傳播到備庫去？我們可以在主庫peppi中進行簡單的驗證，即在主庫更新密碼檔案，然後在備庫kokki中檢視密碼檔案的情況。 SQL> connect sys/oracle@peppi as sysdba Connected. SQL> select * from v$pwfile_users; USERNAME SYSDB SYSOP SYSAS ------------------------------ ----- ----- ----- SYS TRUE TRUE FALSE

當前主庫peppi所在的密碼檔案只存在一條記錄，如果賦予sysdba給system使用者會觸發密碼檔案的更新 SQL> grant sysdba to system; Grant succeeded. SQL> select * from v$pwfile_users; USERNAME SYSDB SYSOP SYSAS ------------------------------ ----- ----- ----- SYS TRUE TRUE FALSE SYSTEM TRUE FALSE FALSE 這樣，主庫的密碼檔案中就會存在兩條記錄了，那麼在備庫中存在幾條記錄呢？ SQL> connect sys/oracle@kokki as sysdba Connected. SQL> select * from v$pwfile_users; USERNAME SYSDB SYSOP SYSAS ------------------------------ ----- ----- ----- SYS TRUE TRUE FALSE 這個輸出很清晰地看出主庫的密碼檔案變更並沒有傳輸到備庫 然後我們收回system的sysdba許可權，因為我們還是不希望system的許可權過於寬泛？ SQL> connect sys/oracle@peppi as sysdba Connected. SQL> revoke sysdba from system; Revoke succeeded. 這樣對dataguard會有影響嗎? 接下來的問題是: 這樣對dataguard是否有影響?主庫到備庫的redo傳輸需要通過密碼檔案中的sys使用者密碼來進行認證，如果在主庫配置了其它的sysdba使用者也可以，但問題是主庫的redo傳輸是通過密碼檔案像sys一樣的使用者來作為認證基礎的，一旦主庫加密後的密碼和備庫不一致，那麼redo傳輸就會有麻煩。 ?如果需要驗證這個問題，可以通過修改peppi中的sys密碼，然後看看是如何影響kokki的。 see if or how it affects kokki. SQL> alter user sys identified by prutser; User altered. SQL> connect sys/prutser@peppi as sysdba Connected. SQL> connect sys/prutser@kokki as sysdba ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. 上面的輸出很明顯再次看到主庫中的密碼檔案變更不會自動傳播到備庫。 ?但是事實上，我們在備庫kokki上依舊可以使用原來的密碼檔案，如下： SQL> connect sys/oracle@kokki as sysdba Connected. 然後第二個問題是：如果密碼檔案已經不一致的情況下，redo是否能夠正常傳輸？對這個問題，我們在主庫切換一次日誌來驗證一下。 SQL> connect sys/prutser@peppi as sysdba Connected. SQL> alter system switch logfile; System altered. SQL> alter system switch logfile; System altered. SQL> alter system switch logfile; System altered. DGMGRL> show configuration; Configuration - PeppiEnKokki Protection Mode: MaxPerformance Databases: peppi - Primary database kokki - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS 通過上面的輸出我們可以看到，竟然結果都是正常的，很明顯密碼檔案的變化不會直接影響到redo的傳輸，這是因為主庫和備庫已經建立了連線，對於redo的部分，備庫就不需要再次獲得主庫的重新認證了。但是一旦重置redo的傳輸，就會很清楚的看到會存在問題。 DGMGRL> edit database kokki set property LogShipping=off; Property "logshipping" updated DGMGRL> edit database kokki set property LogShipping=on; Property "logshipping" updated DGMGRL> show configuration; Configuration - PeppiEnKokki Protection Mode: MaxPerformance Databases: peppi - Primary database Error: ORA-16778: redo transport error for one or more databases kokki - Physical standby database Fast-Start Failover: DISABLED Configuration Status: ERROR 通過這可以很清晰的看到redo的傳輸中斷了然後提示了ORA-16778的錯誤，如果主庫的密碼檔案一旦發生改變，那麼不會馬上暴露出問題，但是可能在後來的某一個時間點爆發。 那麼ORA-16778 錯誤代表什麼含義？ $ oerr ora 16778 16778, 00000, "redo transport error for one or more databases" // *Cause: The redo transport service was unable to send redo data to one // or more standby databases. // *Action: Check the Data Guard broker log and Oracle alert log for // more details. Query the LogXptStatus property to see the // errors. 我們剛剛已經在主庫修改了sys的密碼，這個時候的問題是怎麼修復？ ?探索答案： 可能我們可以簡單的通過在kokki上面重建密碼檔案得以解決，讓我們試一試。 el5$ rm $ORACLE_HOME/dbs/orapwv1120 el5$ orapwd file=$ORACLE_HOME/dbs/orapwv1120 password=prutser SQL> connect sys/prutser@kokki as sysdba Connected. 看起來似乎是可以的，但是問題是dataguard是否如此樂觀的認為問題已經解決了呢？ SQL> connect sys/prutser@peppi as sysdba Connected. SQL> alter system switch logfile; System altered. SQL> alter system switch logfile; System altered. SQL> alter system switch logfile; System altered. DGMGRL> show configuration; Configuration - PeppiEnKokki Protection Mode: MaxPerformance Databases: peppi - Primary database Error: ORA-16778: redo transport error for one or more databases kokki - Physical standby database Fast-Start Failover: DISABLED Configuration Status: ERROR 這個時候發現情況沒有看上去那麼好了，是不是我們需要重置一下redo的傳輸，我們來簡單驗證一下。 DGMGRL> edit database kokki set property LogShipping=off; Property "logshipping" updated DGMGRL> edit database kokki set property LogShipping=on; Property "logshipping" updated DGMGRL> show configuration; Configuration - PeppiEnKokki Protection Mode: MaxPerformance Databases: peppi - Primary database Error: ORA-16778: redo transport error for one or more databases kokki - Physical standby database Fast-Start Failover: DISABLED Configuration Status: ERROR 這個時候還是不奏效，在備庫重建密碼檔案看來不是解決方法了，因為密碼檔案是加密的，儘管密碼是相當的，但是加密之後的效果不同。 那麼如果從主庫拷貝密碼問價到備庫的話怎麼樣呢？ 我們嘗試拷貝密碼檔案到備庫kokki，然後看看效果： $ scp $ORACLE_HOME/dbs/orapwv1120 el5:$ORACLE_HOME/dbs/orapwv1120 orapwv1120 100% 1536 1.5KB/s 00:00 SQL> connect sys/prutser@kokki as sysdba Connected. 這個時候我們可以在kokki使用sys接入例項了，那麼dataguard這邊確實ok了嗎？ SQL> connect sys/prutser@peppi as sysdba Connected. SQL> alter system switch logfile; System altered. SQL> alter system switch logfile; System altered. SQL> alter system switch logfile; System altered. DGMGRL> show configuration; Configuration - PeppiEnKokki Protection Mode: MaxPerformance Databases: peppi - Primary database Error: ORA-16778: redo transport error for one or more databases kokki - Physical standby database Fast-Start Failover: DISABLED Configuration Status: ERROR 再一次證明dataguard還是不夠滿意，但是看起來一切已經和原來一樣了，如果我們稍作等待然後再次開啟歸檔日誌的傳輸，就會連帶redo的傳輸，當然這個過程可以通過禁用啟用redo傳輸來完成。 DGMGRL> edit database kokki set property LogShipping=off; Property "logshipping" updated DGMGRL> edit database kokki set property LogShipping=on; Property "logshipping" updated DGMGRL> show configuration; Configuration - PeppiEnKokki Protection Mode: MaxPerformance Databases: peppi - Primary database kokki - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS 最終dataguard的狀態終於正常了，因為主庫的redo傳輸到備庫已經正常了。 總結： 如果需要保證dataguard的可持續日誌傳輸，如果主庫存在任何密碼檔案的變更，我們必須從主庫拷貝密碼檔案到備庫.當然最後還是是一句 Happy Data Guarding ;-)