ORA-01111,ORA-01110,ORA-01157報錯處理

客戶一套AIX平臺的9208的DG災備端報歸檔日誌不能正常應用，從alert日誌觀察到有以下報錯：

ORA-01111: name for data file 13 is unknown – rename to correct file
ORA-01110: data file 13: ‘/u01/app/oracle/oradata/fapdb/UNNAMED0013′
ORA-01157: cannot identify/lock data file 13 – see DBWR trace file

跟客戶溝通下來了解到7號應用那邊對生產數據庫某一表空間增長了一個裸設備文件，經過查詢生產數據庫肯定13號數據文件即7號添加的裸設備文件，照理說不會出現這種狀況，因爲有2套災備standby庫，出問題的這套是上海的，另外一套在深圳，登錄查看深圳那套備庫沒有問題。我深信該問題確定是因爲上海災備端的數據文件轉換參數有問題，由於standby的數據文件都是同一放在/oradata/fapdb下面的。

經過查詢standby數據庫的db_file_name_convert參數發現這個參數確實設置的有問題，設反了！！這一個小問題可能會致使一個很嚴重的生產事故。

在確認問題後以及確認文件號與文件的關係後經過以下命令對該數據文件進行了重建。

alter system set standby_file_management=manual;
alter database create datafile  ‘/oradata/fapdb/dcept01.dbf’ as ‘/u01/app/oracle/oradata/fapdb/UNNAMED0013′;
alter system set standby_file_management=auto;
alter database recover managed standby database disconnect from session;

改是改完了可是在我想應用未應用的日誌時客戶跟我說他們的歸檔只保留5天，我操~這不玩我麼，備份策略非常有問題，連沒應用的規檔都給清了，怎麼辦？2個辦法 要麼這套DG重搭，要麼使用增量備份前滾standby，因爲考慮到該庫只有九十多G的大小以及要對生產減少到最小的影響，故採用從新搭建該DG的方式解決了該問題。

 

在作恢復的過程當中對客戶其他8套災備數據庫的參數也作了一個檢查，發現災備端的db_file_name_convert和log_file_name_convert所有設反了~~OH MY GAD!這個工程師怎麼搭的DG 啊。。。。犯這麼低級的錯誤~~

既然發現了問題，所有改正~

OK，問題圓滿解決！