【DATAGUARD 學習】同一臺主機的dataguard 密碼問題！
DATAGUARD的資料傳輸方式有兩種：LGWR和ARCH。其中前者傳送的是聯機日誌的redo，後者傳輸的是歸檔。
FAL是9i推出的DATAGUARD的一大改進，它可以自動傳送備庫缺失的日誌，一般情況下，它是不需要手工干預的。
主庫的日誌要傳輸到備庫，兩者的密碼檔案中設定的口令必須一致。然而，如果我們不小心設定了不一致的密碼，則需要重新生成備庫的密碼檔案，但重置密碼檔案後，FAL還並不能自動處理日誌的GAP，需要DBA做一些額外的工作。
在這種情況下，用LGWR和ARCH兩種方式的處理方式有所區別，下面分別討論:
一、ARCH方式傳送日誌
--主庫引數
SQL> show parameter dest_2
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_online_log_dest_2 string
log_archive_dest_2 string SERVICE=standby LGWR ASYNC VA
LID_FOR=(ONLINE_LOGFILES,PRIMA
RY_ROLE) DB_UNIQUE_NAME=standb
y
--在備庫上查詢
SQL> select * from v$standby_log;
no rows selected
我們知道，用LGWR傳送日誌，如果備庫沒有standby redo log，則oracle自動會變成用ARCH傳送歸檔。
為了模擬主備庫密碼檔案不一致，我們重新生成備庫密碼檔案，並置一個與主庫不一樣的密碼。
[oracle@standby dbs]$ mv orapwprimary orapwprimary.bak
[oracle@standby dbs]$ orapwd file=orapwprimary password=aaa entries=10
接著重啟主庫，檢視主庫的alert日誌，可以發現下面的資訊：
Tue Jul 10 22:10:38 2007
Errors in file /u01/oracle/admin/primary/bdump/primary_arc1_3338.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Tue Jul 10 22:10:38 2007
ORACLE Instance primary - Archival Error. Archiver continuing.
Tue Jul 10 22:10:47 2007
FAL[server]: Fail to queue the whole FAL gap
GAP - thread 1 sequence 68-68
DBID 1463588919 branch 626106231
Tue Jul 10 22:15:50 2007
Error 1017 received logging on to the standby
------------------------------------------------------------
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191
------------------------------------------------------------
Tue Jul 10 22:15:50 2007
Errors in file /u01/oracle/admin/primary/bdump/primary_arc1_3338.trc:
ORA-16191: Primary log shipping client not logged on standby
PING[ARC1]: Heartbeat failed to connect to standby 'standby'. Error is 16191.
從上面的資訊不難看出，oracle的確換成了ARCH的方式傳送日誌，並且因為密碼檔案的原因不能傳送到備庫中。
如果檢視備庫的日誌，也可以發現類似如下的資訊：
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 68-68
DBID 1463588919 branch 626106231
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------
接著，我們在備庫還原密碼檔案，並重啟備庫：
[oracle@standby dbs]$ rm orapwprimary
[oracle@standby dbs]$ mv orapwprimary.bak orapwprimary
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1260696 bytes
Variable Size 134218600 bytes
Database Buffers 29360128 bytes
Redo Buffers 2932736 bytes
Database mounted.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
然而，隔一段時間後觀察主、備庫的日誌，仍然有上面的報錯資訊，說明這種情況下重啟備庫是沒有效果的。
我們再重啟主庫試試：
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1260696 bytes
Variable Size 150995816 bytes
Database Buffers 12582912 bytes
Redo Buffers 2932736 bytes
Database mounted.
Database opened.
隔一小段時間可以分別在主、備庫上看到如下資訊：
--主庫
Tue Jul 10 22:41:57 2007
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
--備庫
Tue Jul 10 22:31:57 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[5]: Assigned to RFS process 16058
RFS[5]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[5]: No standby redo logfiles created
Tue Jul 10 22:32:26 2007
Media Recovery Log /u01/archivelog/1_70_626106231.dbf
Media Recovery Waiting for thread 1 sequence 71 (in transit)
以上資訊充分說明，DATAGUARD日誌傳送已經恢復正常。
實際上，經過測試，我們在修改密碼檔案後只需要重啟主庫即可恢復日誌正常傳送。
二、LGWR方式傳送日誌
為了讓oracle可以用LGWR方式傳送日誌，我們先在備庫上建立幾個standby redo log。
SQL> alter database add standby logfile group 4 '/u01/oracle/oradata/primary/standbyredo04.log' size 50m;
Database altered.
SQL> alter database add standby logfile group 5 '/u01/oracle/oradata/primary/standbyredo5.log' size 50m;
Database altered.
SQL> alter database add standby logfile group 6 '/u01/oracle/oradata/primary/standbyredo6.log' size 50m;
Database altered.
SQL> alter database add standby logfile group 7 '/u01/oracle/oradata/primary/standbyredo7.log' size 50m;
Database altered.
重新生成一個與主庫不一致的密碼檔案：
[oracle@standby dbs]$ mv orapwprimary orapwprimary.bak
[oracle@standby dbs]$ orapwd file=orapwprimary password=aaa entries=10
重新生成一個密碼檔案後，必須重啟備庫才能模擬錯誤（不重啟的話是不會影響日誌傳輸的）
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1260696 bytes
Variable Size 142607208 bytes
Database Buffers 20971520 bytes
Redo Buffers 2932736 bytes
Database mounted.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
此時主庫alert日誌報錯如下：
Error 1017 received logging on to the standby
------------------------------------------------------------
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191
------------------------------------------------------------
Tue Jul 10 23:06:30 2007
Errors in file /u01/oracle/admin/primary/bdump/primary_arc0_3457.trc:
ORA-16191: Primary log shipping client not logged on standby
PING[ARC0]: Heartbeat failed to connect to standby 'standby'. Error is 16191.
備庫alert報錯：
Tue Jul 10 22:53:06 2007
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 79-79
DBID 1463588919 branch 626106231
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------
上面的資訊與ARCH方式傳送日誌的測試報錯類似，就不解析了。
我們重啟備庫，並備庫觀察日誌：
Tue Jul 10 23:13:28 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 16235
RFS[2]: Identified database type as 'physical standby'
Tue Jul 10 23:25:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 16237
RFS[3]: Identified database type as 'physical standby'
RFS[3]: Successfully opened standby log 4: '/u01/oracle/oradata/primary/standbyredo04.log'
Tue Jul 10 23:25:23 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 16239
RFS[4]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[4]: Successfully opened standby log 4: '/u01/oracle/oradata/primary/standbyredo04.log'
從備庫的alert資訊看，日誌傳送已經恢復正常。
但此時主庫還會繼續報如下的錯誤：
Tue Jul 10 23:18:31 2007
FAL[server]: Fail to queue the whole FAL gap
GAP - thread 1 sequence 79-79
DBID 1463588919 branch 626106231
FAL[server]: Fail to queue the whole FAL gap
GAP - thread 1 sequence 80-80
DBID 1463588919 branch 626106231
LNS1 started with pid=18, OS id=3499
這是因為雖然備庫重建了密碼檔案，並且存在standby redo log，但主庫仍然嘗試用ARCH的方式傳送日誌，直到切換日誌。
我們切換一下主庫日誌，主庫alert資訊就不會再報錯了：
SQL> alter system switch logfile;
System altered.
Tue Jul 10 23:35:02 2007
ARC2: Standby redo logfile selected for thread 1 sequence 80 for destination LOG_ARCHIVE_DEST_2
Tue Jul 10 23:35:05 2007
LNS: Standby redo logfile selected for thread 1 sequence 81 for destination LOG_ARCHIVE_DEST_2
進一步測試可以發現：在這種情況下，只重啟主庫也可以恢復日誌的正常傳送。
簡單總結：
1、ARCH方式傳送日誌時，如果主備庫密碼檔案不一致，在重新設定密碼檔案後，必須重啟主庫才能使日誌傳送恢復正常
2、LGWR方式傳送日誌時，如果主備庫密碼檔案不一致，在重新設定密碼檔案後，只需可以重啟主庫或重啟備庫就可使日誌傳送恢復正常。
看來LGWR在減少可能的資料損失同時，還可以減低主庫重啟的機率，推薦大家使用這種方式作為日誌傳送手段。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/22664653/viewspace-667271/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 【DATAGUARD 學習】同一臺主機上的dataguard
- 同一臺機器上DataGuard的密碼問題密碼
- 【DATAGUARD 學習】學習DATAGUARD 過程中遇到的問題
- 【DataGuard】同一臺主機實現物理Data Guard配置安裝
- 【問題解決】單機搭建dataguard的問題
- 【DataGuard】同一臺主機部署Oracle 11g物理Active Data Guard詳細過程Oracle
- 【DATAGUARD 學習】管理影響備庫的主庫事件事件
- dataguard環境中的密碼維護密碼
- 一次rac+dataguard 建立過程遇到密碼檔案問題密碼
- ORACLE dataguard學習筆記Oracle筆記
- dataguard歸檔路徑的問題
- 【DATAGUARD】 基於同一個主機建立物理備庫和邏輯備庫（二）
- 【DATAGUARD】 基於同一個主機建立物理備庫和邏輯備庫（一）
- 【DATAGUARD】 基於同一個主機建立物理備庫和邏輯備庫 (三)
- 【DataGuard】使用GC建立的物理DataGuard主備庫pfile比較GC
- 搭建dataguard碰到的幾個小問題
- Oracle在一臺機器上搭建dataguardOracle
- 【DATAGUARD 學習】ora-03113
- RMAN學習筆記_ Duplicate建立DataGuard筆記
- RMAN學習筆記_ Duplicate重做DataGuard筆記
- Dataguard(Standby) 後臺程式
- dataguard主庫壞塊的修復
- 【DATAGUARD 學習】測試standby應用REDO
- 【DATAGUARD 學習】如何停止standby資料庫資料庫
- 實戰dataguard主從切換
- dataguard 主備庫出現gap
- Oracle 單機配置DataGuardOracle
- DataGuard對異構平臺的支援
- 【DATAGUARD 學習】監控primary庫和standby庫
- DataGuard主備庫切換步驟
- js的cookie的同一域名下不同主機名問題JSCookie
- RAC和Dataguard環境下修改sys使用者密碼密碼
- 【Dataguard】DataGuard運維注意事項運維
- 跨平臺級聯dataguard配置
- Oracle DataGuard跨平臺支援列表Oracle
- DATAGUARD在做SWITCHOVER切換時遇到問題總結
- 【DATAGUARD 學習】使用duplicate 建立物理standby 資料庫資料庫
- 【DATAGUARD】 基於同一個主機建立物理備庫和邏輯備庫 (四)--新增一個物理dg節點