史上最全Oracle文件損壞處理辦法 (附實驗步驟)

　　本文轉自 | 數據和云

　　作者| 楊豹

　　概述

　　本文將給大家介紹oracle各類文件損壞的現象和應對策略，請注意所有的恢復都是基于有備份的情況，所以請開啟數據庫的日常備份。

　　文章將從以下文件展開：a. 密碼文件b. 參數文件c. 控制文件d. 數據文件(分普通表空間數據文件，其它表空間數據文件如system、sysaux、undo)e. 日志文件(分current、active、inactive)

　　在正式實驗之前，我先問一個問題，上面這些文件，哪個損壞最致命？歡迎在文末留言處留言。

　　環境準備

　　本實驗在oracle 11G歸檔模式下進行，實驗前先對數據庫做個全庫備份。

　　文件說明：密碼文件存儲的是sys密碼

　　模擬故障：清空該文件

　　現象：使用sys通過oracle net登錄報密碼錯誤sqlplus sys/123456@10.40.16.120:1521/orcltest as sysdba

　　修復：使用自帶工具orapwd重新生成密碼文件

　　文件說明：這里所說的參數文件指的是spfile，該文件存儲的是實例啟動的參數和控制文件的路徑

　　模擬故障：清空該文件

　　現象：修改數據庫參數時會報錯

　　修復：使用rman還原參數文件

　　注意在還原spfile的時候如果還原到spfile原先的位置，會報ORA-32011: cannot restore SPFILE to location already being used by the instance所以需要還原到一個新的路徑，然后手工移過去PS：參數文件也可以從內存中直接創建一個新的，更省事（create spfile='/home/oracle/spfileorcltest.ora' from memory;）

　　文件說明：控制文件記錄數據庫文件的信息和日志的信息等查看控制文件

　　模擬故障：將該文件清空

　　現象：前臺正常的增刪改查不受影響，但一旦出現切換日志或產生檢查點時數據庫宕機

　　數據庫alert日志

　　可以看到ckpt這個進程最先發現控制文件損壞了，實例之后被lgwr進程殺掉。可能大家在做實驗的時候發現實例是被ckpt殺掉，這也是有可能的，反正可以肯定的一點是，實例最后肯定會掛掉修復：使用rman還原控制文件

　　說明：

　　a. 不要使用刪控制文件的方式去模擬該實驗，這是由于ckpt、lgwr進程已經打開了控制文件，內存中已經有了這個控制文件的鏡像，而rm命令并不能把這些進程已經打開的控制文件的句柄刪掉。所以你會發現實例并沒有掛掉。b. 對數據庫resetlogs之后，之前的備份就作廢了，所以應該第一時間對數據庫做一個全備。c. 可能大家也注意到了，該實驗中只有一個controlfile，當controlfile被破壞了之后，實例就掛了。如果是controlfile的多路復用，其中一個controlfile壞了數據庫又是什么影響？我這里先說下我的結論：controlfile只要有一個壞了，實例就會奔潰，同時在alert日志中會提示具體是哪個controlfile損壞，解決辦法就是復制一份好的controlfile去替換損壞的controlfile，重新啟庫即可。實驗就留給大家自己做吧。附一段我實驗的alert日志（ORA-00227: corrupt block detected in control file: (block 1, # blocks 1) ORA-00202: control file: '/u01/app/oracle/oradata/orcltest/control02.ctl'）總結：

　　1. 控制文件恢復不會丟失任何事務，但會要求數據庫resetlogs，這將會導致之前的備份片無效，所以恢復控制文件后最好做一個全庫備份。2. 對控制文件最好設置兩個，一個壞了還能利用另一個恢復，對數據庫的影響和恢復的時間都是最小的。

　　為了繼續實驗，請手工刪除之前所有的歸檔日志和備份文件，并對現在的數據庫做一個全備

　　模擬故障：將該文件清空echo '' > /u01/app/oracle/oradata/orcltest/tbs01.dbf // tbs01是一個普通表空間數據文件現象：查詢該數據文件上的對象報錯

　　修復：先對數據文件offline，然后使用rman還原恢復，最后online

　　模擬故障：將該文件清空

　　現象：查詢數據字典報錯

　　修復：先關庫，然后使用rman還原恢復，最后啟庫

　　sysaux表空間的文件損壞處理手段與普通表空間數據文件損壞處理手段相同，undo表空間的文件損壞處理手段與system表空間數據文件損壞處理手段相同，因為undo表空間的數據文件也不能offline。限于篇幅省略實驗步驟，僅貼出文件損壞的現象。sysaux表空間文件損壞現象：訪問sysaux表空間的對象報錯

　　undo表空間文件損壞現象：所有修改操作全部報錯

　　查看當前日志狀態：current-當前正在寫入的日志組，active-還未歸檔的日志組，inactive-已歸檔的日志組

　　模擬故障：將inactive日志文件清空

　　現象：當數據庫切換到該日志組時，數據庫并不知道磁盤上的日志文件有問題，只是將內容寫到日志文件在內存的拷貝中，等到切換的時候，日志文件落盤就會發現該日志是有問題的，然后alert日志出現報錯，不過不影響數據庫正常運行，只是以后數據庫切換日志會跳過該日志組

　　觀察alert日志

　　查看v$log，可以看到group 3一直沒有被用到

　　修復：將該日志文件重新初始化

　　為了繼續實驗，請手工刪除之前所有的歸檔日志和備份文件，并對現在的數據庫做一個全備

　　查看當前日志狀態

　　模擬故障：current日志文件清空

　　現象：前臺正常的增刪改查不受影響，但一旦出現切換日志數據庫宕機

　　查看alert日志

　　恢復：使用不完全恢復打開

　　這個時候就需要加入隱含參數，再啟動

　　說明：

　　a. 使用該方式恢復的庫，可能會造成數據的丟失，而且也并不能保證一定成功。b. 恢復成功后，應將表全部使用expdp導出，重建庫。c. 上面的實驗每個日志組都只有一個member，如果每個日志組有兩個member又是什么樣子呢？

　　先說下我的結論：損壞其中任何一個member對數據庫沒什么影響，只是在切換到有member損壞的日志組時，會在alert日志中提示告警ORA-00313 ORA-00312 ORA-27048，解決辦法就是刪掉這個member，重新添加，不需要對數據庫進行重啟，實驗過程我就不展示了。所以最好是每組日志中設置2個成員。這兒我有個疑問想不通：對inactive的日志進行破壞，數據庫切換到這個被破壞的日志時，數據庫正常寫，只是在日志切換的時候報錯，這個能理解，因為系統內存中有這個被破壞的日志之前的拷貝，所有的寫可能都是在內存中。切換的時候該日志文件就必須要落盤，所以提示報錯。而對current的日志進行破壞，數據庫也正常寫，但是在日志切換的時候數據庫直接崩了。沒弄懂這兩個為什么會有這個區別。

　　1. 生產中應制定好備份策略2. 控制文件和日志文件最好是設置大于一個成員3. 當前日志組損壞最為致命，如果日志寫很繁忙，可以只為日志文件配置一個成員，但同時需要配置一個dataguard，方便切換4. 此博客僅為個人理解，如有不對的地方，歡迎大家指出

　　作者：楊豹，東財基金DBA，modb.pro/db/22833

　　原文：https://www.cnblogs.com/ddzj01/p/12526100.html

　　??更多閱讀：誤執行了 rm -rf /*刪庫之后，除了跑路還能怎么整？！一文帶你解讀 Redis分布式鎖發展史和正確實現方式

　　80歲COBOL碼農：「扶我起來，這個bug我會修。」

　　今日頭條技術架構一覽

　　中臺的問題，是技術的問題，還是人的問題？

　　來，關于你對女程序員的好奇心，這里都告訴你為什么大部分人做不了架構師？這2點是關鍵

　　架構師為你詳解：Nginx 架構我在外包公司做增刪改查有前途么？10 款最佳的 MySQL GUI工具，DBA 必備神器！

　　再見，微服務

　　可能是全網最好的 MySQL 重要知識點

　　?資料下載DTCC中國數據庫技術大會2020-2019SACC2019中國系統架構師大會PostgreSQL 2019中國技術大會點擊上方文字可以直接進入小程序瀏覽，下載請在后臺分別回復關鍵詞? DTCC、SACC、PG19即可直接收到完整版 PPT 下載鏈接