dataguard環境中的密碼維護
這篇文章的動力來自於一個朋友的提問，他問我備庫的密碼檔案直接重建可以嗎，我說最好還是複製，如果重建可能會有一些潛在的問題，當然這個所謂潛在問題也是自己給自己打的馬虎眼，到底哪裡有問題，腦海裡搜尋了一番似乎沒有找到什麼有效的資訊，但是隱隱之中感覺搭建dataguard好像還從來沒有直接重建密碼檔案的時候，似乎是一種非常規的方式，但是轉眼一想一旦發生這種情況的時候，或者密碼檔案出現了一些潛在問題的時候，怎麼有效防範，這個問題就又上升了一個高度，所以我對這個問題做了一些初步的分析，然後在網上竟然看到還真有一些技術大拿對這類看起來細節問題做了深入的解析，我想我就不用再重新寫了，直接把他的成果拿過來分享給大家。
文章來自於下面的連結，感興趣可以看一下。
自己簡單翻譯了一下。
這篇文章會提到另外一個問題：在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的。
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 ;-)
文章來自於下面的連結，感興趣可以看一下。
自己簡單翻譯了一下。
這篇文章會提到另外一個問題：在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的。
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 ;-)
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8494287/viewspace-2089576/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- RAC環境中的密碼檔案密碼
- RAC和Dataguard環境下修改sys使用者密碼密碼
- RAC+DATAGUARD+ADVANCED REPLICATION環境修改sys和repadmin密碼密碼
- DataGuard 日常維護命令整理
- RAC環境下dataguard的搭建
- RAC+Dataguard環境中JDBC Failover配置JDBCAI
- 環境維護（二）：虛擬機器中安裝win7虛擬機Win7
- 【Dataguard】Oracle多租戶環境對Dataguard的影響Oracle
- 維護網路安全環境需從人人做起
- Dataguard日常維護及故障解決
- Oracle密碼檔案的建立、使用和維護 (zt)Oracle密碼
- DataGuard環境程式資訊追蹤
- 搭建rac+DataGuard的測試環境
- 在工業環境中透過預測性維護實現價值
- Dataguard 維護操作-01-- MRP process
- RAC和Data Guard環境中修改使用者密碼密碼
- dataguard系列之六------備用資料庫的維護資料庫
- Oracle DataGuard 常用維護命令參考手冊Oracle
- Oracle資料庫密碼檔案的使用和維護(轉)Oracle資料庫密碼
- 【DATAGUARD 學習】同一臺主機的dataguard 密碼問題！密碼
- linux環境下ssh不輸入密碼Linux密碼
- 9I DATAGUARD實施和維護總結
- 1.7. 建立和維護資料庫密碼檔案資料庫密碼
- WPS文字中的表格也保護密碼功能密碼
- 自動刪除歸檔日誌的指令碼(尤其是dataguard環境)指令碼
- 物聯網在環境保護行業中的應用行業
- Oracle DataGuard環境中主庫收到ORA-16198報錯Oracle
- 域環境的Windows伺服器無法禁用密碼策略Windows伺服器密碼
- ORACLE RAC資料庫配置Dataguard環境(3)Oracle資料庫
- ORACLE RAC資料庫配置Dataguard環境(2)Oracle資料庫
- ORACLE RAC資料庫配置Dataguard環境(1)Oracle資料庫
- ORACLE 9I DATAGUARD實施和維護總結Oracle
- 9I DATAGUARD原理，實施和維護總結
- 【PASSWORD】Linux環境下使用密碼驗證方式重置SYS使用者密碼Linux密碼
- 【ARCH】留存，Oracle11g之前Dataguard環境刪除歸檔指令碼Oracle指令碼
- 更優雅的配置：docker/運維/業務中的環境變數Docker運維變數
- 騰訊安全姬生利：雲原生環境下的“密碼即服務”密碼
- 如何刪除word文件密碼保護 解除word文件保護密碼密碼