客戶一套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，問題圓滿解決！