【DataGuard】由於備庫引數設定不當導致資料檔案無法新增的故障分析
本文將描述由於standby_file_management和db_file_name_convert設定不當導致資料檔案無法新增的故障處理過程。
1.故障再現
1)主庫建立新的表空間tbs_sec1
SQL> create tablespace tbs_sec1 datafile '/u01/app/oracle/oradata/secdb/tbs_sec1.dbf' size 10m;
Tablespace created.
2)手工切換日誌
SQL> alter system switch logfile;
System altered.
3)此時在備庫alert中記錄中便可以檢視到如下報錯內容
Tue Aug 10 16:16:21 2010
RFS[2]: No standby redo logfiles created
RFS[2]: Archived Log: '/u01/app/oracle/flash_recovery_area/SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc'
Tue Aug 10 16:16:22 2010
Media Recovery Log /u01/app/oracle/flash_recovery_area/SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc
File #6 added to control file as 'UNNAMED00006' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
Errors with log /u01/app/oracle/flash_recovery_area/SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc
MRP0: Background Media Recovery terminated with error 1274
Tue Aug 10 16:16:22 2010
Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_15738.trc:
ORA-01274: cannot add datafile '/u01/app/oracle/oradata/secdb/tbs_sec1.dbf' - file could not be created
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Tue Aug 10 16:16:24 2010
Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_15738.trc:
ORA-01274: cannot add datafile '/u01/app/oracle/oradata/secdb/tbs_sec1.dbf' - file could not be created
Tue Aug 10 16:16:24 2010
MRP0: Background Media Recovery process shutdown (secdg)
對應的trace檔案中記錄的報錯內容大同小異。
2.故障原因
問題是由於沒有正確設定standby_file_management和db_file_name_convert引數導致的。但此時,在已經出現問題的前提下修改這個引數,已經於事無補。
SQL> alter system set db_file_name_convert='/u01/app/oracle/oradata/secdb/','/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;
System altered.
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 1219184 bytes
Variable Size 96470416 bytes
Database Buffers 213909504 bytes
Redo Buffers 2973696 bytes
SQL> alter database mount standby database;
Database altered.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
此時alert中仍然會記錄如下報錯資訊
Tue Aug 10 16:24:36 2010
alter database recover managed standby database disconnect from session
Tue Aug 10 16:24:36 2010
Attempt to start background Managed Standby Recovery process (secdg)
MRP0 started with pid=23, OS id=16942
Tue Aug 10 16:24:36 2010
MRP0: Background Managed Standby Recovery process started (secdg)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1111
Tue Aug 10 16:24:41 2010
Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_16942.trc:
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'
Tue Aug 10 16:24:41 2010
Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_16942.trc:
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'
Tue Aug 10 16:24:41 2010
MRP0: Background Media Recovery process shutdown (secdg)
Tue Aug 10 16:24:42 2010
Completed: alter database recover managed standby database disconnect from sessi on
可見,問題依舊!
3.處理方法
在這種故障場景下,我們可以透過調整資料檔案的方法在備庫端進行處理。
SQL> select name from v$datafile;
NAME
----------------------------------------------------------------------
/u01/app/oracle/oradata/SECDG/datafile/o1_mf_system_661zb5rh_.dbf
/u01/app/oracle/oradata/SECDG/datafile/o1_mf_undotbs_661zc97r_.dbf
/u01/app/oracle/oradata/SECDG/datafile/o1_mf_sysaux_661zd3d0_.dbf
/u01/app/oracle/oradata/SECDG/datafile/o1_mf_tbs_1_661zdwb9_.dbf
/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006
6 rows selected.
SQL> alter database create datafile '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006' as '/u01/app/oracle/oradata/SECDG/datafile/tbs_sec1.dbf';
Database altered.
此時,對應的資料檔案已經處於正確的狀態,該問題已經得到比較圓滿的處理。
4.杜絕出現該問題的方法
防止該問題出現的的根本方法是在建立物理DataGuard的過程中就將standby_file_management、db_file_name_convert及log_file_name_convert引數設定正確。
1)調整standby_file_management引數為AUTO
SQL> alter system set standby_file_management=auto;
System altered.
2)設定db_file_name_convert引數
SQL> alter system set db_file_name_convert='/u01/app/oracle/oradata/secdb/','/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;
3)設定log_file_name_convert引數
SQL> alter system set log_file_name_convert='/u01/app/oracle/oradata/secdb/','/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;
5.小結
關於物理DataGuard的配置,每一個引數都要細細揣摩。針對文中提到的故障一旦出現,會給我們帶來很多不必要的麻煩。
無論使用Grid Control還是透過指令碼來建立物理DataGuard,建立完畢之後建議對資料庫的每個引數做最終的檢驗和確認。
Good luck.
secooler
10.08.10
-- The End --
1.故障再現
1)主庫建立新的表空間tbs_sec1
SQL> create tablespace tbs_sec1 datafile '/u01/app/oracle/oradata/secdb/tbs_sec1.dbf' size 10m;
Tablespace created.
2)手工切換日誌
SQL> alter system switch logfile;
System altered.
3)此時在備庫alert中記錄中便可以檢視到如下報錯內容
Tue Aug 10 16:16:21 2010
RFS[2]: No standby redo logfiles created
RFS[2]: Archived Log: '/u01/app/oracle/flash_recovery_area/SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc'
Tue Aug 10 16:16:22 2010
Media Recovery Log /u01/app/oracle/flash_recovery_area/SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc
File #6 added to control file as 'UNNAMED00006' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
Errors with log /u01/app/oracle/flash_recovery_area/SECDG/archivelog/2010_08_10/o1_mf_1_10_6622ponv_.arc
MRP0: Background Media Recovery terminated with error 1274
Tue Aug 10 16:16:22 2010
Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_15738.trc:
ORA-01274: cannot add datafile '/u01/app/oracle/oradata/secdb/tbs_sec1.dbf' - file could not be created
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Tue Aug 10 16:16:24 2010
Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_15738.trc:
ORA-01274: cannot add datafile '/u01/app/oracle/oradata/secdb/tbs_sec1.dbf' - file could not be created
Tue Aug 10 16:16:24 2010
MRP0: Background Media Recovery process shutdown (secdg)
對應的trace檔案中記錄的報錯內容大同小異。
2.故障原因
問題是由於沒有正確設定standby_file_management和db_file_name_convert引數導致的。但此時,在已經出現問題的前提下修改這個引數,已經於事無補。
SQL> alter system set db_file_name_convert='/u01/app/oracle/oradata/secdb/','/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;
System altered.
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 314572800 bytes
Fixed Size 1219184 bytes
Variable Size 96470416 bytes
Database Buffers 213909504 bytes
Redo Buffers 2973696 bytes
SQL> alter database mount standby database;
Database altered.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
此時alert中仍然會記錄如下報錯資訊
Tue Aug 10 16:24:36 2010
alter database recover managed standby database disconnect from session
Tue Aug 10 16:24:36 2010
Attempt to start background Managed Standby Recovery process (secdg)
MRP0 started with pid=23, OS id=16942
Tue Aug 10 16:24:36 2010
MRP0: Background Managed Standby Recovery process started (secdg)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1111
Tue Aug 10 16:24:41 2010
Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_16942.trc:
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'
Tue Aug 10 16:24:41 2010
Errors in file /u01/app/oracle/admin/secdg/bdump/secdg_mrp0_16942.trc:
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01111: name for data file 6 is unknown - rename to correct file
ORA-01110: data file 6: '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006'
Tue Aug 10 16:24:41 2010
MRP0: Background Media Recovery process shutdown (secdg)
Tue Aug 10 16:24:42 2010
Completed: alter database recover managed standby database disconnect from sessi on
可見,問題依舊!
3.處理方法
在這種故障場景下,我們可以透過調整資料檔案的方法在備庫端進行處理。
SQL> select name from v$datafile;
NAME
----------------------------------------------------------------------
/u01/app/oracle/oradata/SECDG/datafile/o1_mf_system_661zb5rh_.dbf
/u01/app/oracle/oradata/SECDG/datafile/o1_mf_undotbs_661zc97r_.dbf
/u01/app/oracle/oradata/SECDG/datafile/o1_mf_sysaux_661zd3d0_.dbf
/u01/app/oracle/oradata/SECDG/datafile/o1_mf_tbs_1_661zdwb9_.dbf
/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006
6 rows selected.
SQL> alter database create datafile '/u01/app/oracle/product/10.2.0/db_1/dbs/UNNAMED00006' as '/u01/app/oracle/oradata/SECDG/datafile/tbs_sec1.dbf';
Database altered.
此時,對應的資料檔案已經處於正確的狀態,該問題已經得到比較圓滿的處理。
4.杜絕出現該問題的方法
防止該問題出現的的根本方法是在建立物理DataGuard的過程中就將standby_file_management、db_file_name_convert及log_file_name_convert引數設定正確。
1)調整standby_file_management引數為AUTO
SQL> alter system set standby_file_management=auto;
System altered.
2)設定db_file_name_convert引數
SQL> alter system set db_file_name_convert='/u01/app/oracle/oradata/secdb/','/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;
3)設定log_file_name_convert引數
SQL> alter system set log_file_name_convert='/u01/app/oracle/oradata/secdb/','/u01/app/oracle/oradata/SECDG/datafile/' scope=spfile;
5.小結
關於物理DataGuard的配置,每一個引數都要細細揣摩。針對文中提到的故障一旦出現,會給我們帶來很多不必要的麻煩。
無論使用Grid Control還是透過指令碼來建立物理DataGuard,建立完畢之後建議對資料庫的每個引數做最終的檢驗和確認。
Good luck.
secooler
10.08.10
-- The End --
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/519536/viewspace-670703/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【DataGuard】由於備庫引數設定不當導致資料檔案無法新增的故障分析(轉)
- 核心引數導致的備庫當機分析
- 由於網路卡故障導致DATAGUARD傳輸檔案失敗
- memory_target設定不當導致資料庫無法啟動的問題資料庫
- [Oracle]由於初始化引數檔案修改錯誤導致oracle無法startupOracle
- 【shmmax】由於shmmax設定過小導致dbca建庫無法完成HMM
- 由hugepage設定導致的資料庫事故資料庫
- 由於歸檔路徑設定不當,系統無法響應的問題
- 故障分析 | 血的教訓-由慢查詢引發的備份等待導致資料庫連線打滿資料庫
- 磁碟IO故障導致的SQLServer資料庫無法寫入SQLServer資料庫
- dataguard 由於主庫引數未配置歸檔刪除策略導致庫歸檔丟失ORA-16016
- 用rman建立dataguard備用資料庫繼續(無法找到備份檔案)資料庫
- oracle SGA設定過大導致資料庫無法啟動Oracle資料庫
- 【恢復】非歸檔模式下因誤刪除資料檔案導致資料庫無法OPEN的故障處理模式資料庫
- ORACLE的歸檔空間滿導致的監聽故障資料庫無法啟動Oracle資料庫
- 歸檔問題導致的資料庫無法啟動資料庫
- 由於無法分配ip而導致的FailedCreatePodSandBoxAI
- dataguard備庫的資料檔案的遷移
- 並行設定不當導致資料處理速度變慢並行
- 歸檔日誌無法歸檔導致資料庫hang住資料庫
- 由OGG引發的資料庫故障資料庫
- LD_LIBRARY_PATH設定不當導致無法登陸和啟動oracleOracle
- 【ASM】RAC19C因引數設定不當,asm無法啟動ASM
- db_file_name_convert設定出錯導致備庫無法recovery
- 又一例SPFILE設定錯誤導致資料庫無法啟動資料庫
- AIX下由於nfs故障導致oracle hangAINFSOracle
- STANDBY_FILE_MANAGEMENT引數未設定auto導致的ADG備庫異常
- shmall引數設定不當引起資料庫啟動時報out of memory報錯資料庫
- 搭建DG過程由於沒有口令檔案而導致rman連不上主庫
- dataguard之物理備庫丟失資料檔案
- dataguard備庫的資料檔案的遷移實戰
- Oracle資料庫由dataguard備庫引起的log file sync等待Oracle資料庫
- dataguard新增臨時資料檔案的bug
- 【DataGuard】錯誤的log_file_name_convert引數導致物理Data Guard配置故障分析與處理
- JDBC的連線引數的設定導致rowid自動新增到sqlJDBCSQL
- openGauss 由於RemoveIPC未關閉導致資料庫crashREM資料庫
- dataguard之邏輯備庫移動資料檔案
- 故障分析 | MySQL 5.7 使用臨時表導致資料庫 CrashMySql資料庫