昨日跟着君三思的塗抹oralce做RMAN的備份恢復實驗，爲了營造相同的實驗環境，中間刪除了books01.dbf這個文件，開始模擬控制文件丟失的情況，在這裏我犯了一個錯誤，下面會講，當我使用恢復操作之後重新打開數據庫的時候，發現system01.dbf文件提示沒有從過久的備份中恢復，原因爲恢復之後的SCN與當前不一致，欲恢復之，發現控制文件是比較舊的時間，這就是我犯的錯誤，全庫備份沒有autobackup controlfile，導致恢復的控制文件是早上9點的，而其他的文件則是晚上6點的，並且無法open resetlogs，次奧啊，於是一直在恢復死循環中無限掙扎，後來“天高雲淡”大師指點我查看v$datafile視圖的status，發現被我刪除掉的books01.dbf變成了unnamed00006，offline了，大擦嘞啊，drop offline之後，system01.dbf重新回到offline，unnamed00006offline了。。。在網上找到了用redolog還原數據文件的方法，一個一個試，終於redolog03可以用，介質恢復成功，成功恢復到晚上崩潰前的狀態
但是查詢jss.book_list，依然不可用，unnamed00006文件依然存在，
想辦法還原books01.dbf，由於全庫備份並沒有此表空間，所以只能使用重做日誌來恢復，此時又一個因爲知識不全面而犯的錯誤，
open rsetlogs之後，聯機存檔日誌組會清空，大概是這個意思吧？所以之前的14，5個日誌序列都沒有了，因爲我恢復前沒有備份，這是天高雲淡大師告訴我的，說一般在生產環境中，肯定要先備份再恢復的，而且一般採用異機備份，這樣能大大減少這樣的誤操作，。。。無奈使用君三思書中的辦法，先創建那個數據文件，
查看之，名稱已改好了，但SCN 依然是0，由於沒有重做日誌可用，幾乎可以肯定沒有辦法還原了（當前能力和工具的限制範圍內，大師說用複雜的工具可以）就在我萬般絕望，準備放棄去睡覺的時候，我發現了flashback_recovery_area裏面的幾個文件，一看居然是重做日誌文件，才忽然想到，閃回恢復功能是打開的，而且時間也吻合，嘗試之
成功！！感謝上蒼啊 ，
數據成功恢復，今天學到了很多東西，備份重於一切啊，要學習的還有很多，其實技術的學習讓我很有感覺很有動力，加油！