Oracle DBA手記 4，數據安全警示錄（簡體書）

蓋國強，Oracle ACE總監，恩墨科技創始人，ITPUB論壇超級版主，遠程DBA服務的倡導者和實踐者，致力於以技術服務客戶。著有《深入解析Oracle》、《循序漸進Oracle》、《深入淺出Oracle》等書；從2010年開始，致力於《Oracle DBA手記》的撰寫與編輯工作，並與張樂奕共同創立了ACOUG用戶組，在國內推進公益自由的Oracle技術交流活動。

《Oracle DBA手記4:數據安全警示錄》不僅是寫給技術人員看的，更是寫給企業數據管理者看的，力求幫助企業避免遭遇《Oracle DBA手記4:數據安全警示錄》所述種種災難。同時，這也是一本相當深入的技術書，包括了一些相當深入的技術探討，不僅可以幫助讀者加深對於Oracle數據庫技術的認知，還可以幫你在遇到類似案例時，做出同樣的營救工作。

靡不有初，鮮克有終
以空間之由——誤操作刪除數據檔恢復案例兩則
災難描述
案例警示
技術重播
恢復過程——通過檔描述符進行數據恢復
技術難點
通過BBED獲取檔號資訊
通過od命令獲得檔號資訊
以拯救之因——強制恢復導致ORA—6004000錯誤案例
災難描述
案例警示
技術重播
恢復過程
ORA—6004000錯誤揭秘
通過_minimum_giga_scn消除SCN異常
ORA—6004194錯誤UNDO故障消除
以優化之名——存儲優化導致表空間誤刪除案例
災難描述
案例警示
技術重播
以安全之期
VALIDATE實現備份驗證
數據庫備份加密
口令模式
透明模式
混合模式
透明加密（TDE）技術
合抱之木，起於毫末
Oracle數據庫軟件發布序列
一個邏輯壞塊引發的災難
案例警示
技術重播
一個硬盤壞塊引發的災難
災難描述
案例警示
技術重播
AIX系統ODM簡介
ASM頭塊備份機制
kfed工具編譯與使用
手工修復ASM案例一則
災難描述
技術重播
PROVISIONED磁盤狀態分析
使用kfed修改ASM磁盤頭資訊
ASM數據抽取恢復——通過AMDU恢復數據案例一則
災難描述
案例警示
技術重播
AMDU工具
檔分析
AMDU檔恢復
未雨綢繆，防患未然
DBA四大守則
DBA守則外兩則
各種慘痛的案例
系統級誤刪除案例
數據庫誤刪除案例
通過觸發器實現DDL監控
主備環境錯誤案例
業務高峰誤操作案例
備份級誤操作案例
進程級別誤操作案例
數據檔誤操作案例
誤關閉生產庫案例
系統存儲級誤刪除案例
亡羊補牢，未為遲也
數據篡改案例解析
案例描述
案例警示
技術重播
故障分析的過程
日誌檔的轉儲
LOGMNR解析
案例之深入解析
技術難點
密碼安全與加密
明察秋毫，見微知著
一次碰撞引發的災難——ASM保護式檔離線引發故障
災難描述
案例警示
技術重播
恢復過程
又一次碰撞引發的災難——檔離線與歸檔缺失案例
災難描述
案例警示
技術重播
恢復過程
空間與檔離線——離線表空間加載修復
災難描述
案例警示
技術重播
恢復過程
技術提示
關於歸檔空間的設置
關于檢查點的一致性調整
心存目想，三思後行
Truncate導致的災難——核心字典表誤操作TRUNCATE
災難描述
案例警示
技術重播
恢復過程
腳本錯誤導致的災難——數據庫整體被刪除故障
災難描述
案例警示
技術重播
恢復過程
……
千里之堤，潰於蟻穴
物盡其用，人盡其才
附錄一 BBED的說明
附錄二 函數f_get_from_dump
參考資料

其實這樣的洩密，一看就是無意識的。很多時候，DBA就是要對無意識的事情，保持高度的警惕。為了這樣的事情，影響到自己的職業生涯，是絕對不劃算的。建議DBA在發布任何會有第三方知道的文檔之前，先問問自己，這份東西會導致洩密麼？多問自己幾次，多確認幾次，如果不能確認，那就和你的主管確認吧。我還記得，以前我們有一條鐵的規定，非項目經理及以上級別，不得公開對甲方發布任何技術文檔及承諾。這條規定就很好，可以避免很多不必要的麻煩。
2.忘記你的系統有備份
雖然我曾經反復強調，備份重於一切，但是我不得不承認，有時候，忘記你的系統有備份的確是一個重要的提示。
在本書部分案例中，客戶存在備份，但是由於數據量龐大或者空間有限，使用備份進行恢復的成本很高或者不現實，於是客戶不得不選擇採取一些較為極端的方式來進行異常修復。
而很多DBA之所以犯下錯誤，也正是因為覺得別人做過備份，已經有了備份。這些想當然的前提在故障出現之後可能不再成立，而這正是很多經典故障的根源。
所以，我非常欣賞郭嶽在書中提出的觀點：在有些時候，忘記你的系統有備份。
很多人，看到這個標題，可能覺得十分詫異，作為一個DBA，需要遵守的守則中的第一條，就是要備份。
在eygle的DBA四大守則中的第一條，寫的就是備份重於一切，並且很明白地說明，唯一能使DBA半夜驚醒的事情，就是系統沒有備份。首先不得不說明，我完全同意這個觀點，但是在維護電信運營商系統的時候，請你一定要忘記你的系統是有備份的。
我提出這個觀點，基於以下兩個原因。
首先，對于運營商級別的系統，數據量之大，如果沒有到達非常讓人崩潰的情況（例如，生產系統崩潰，容災系統無法啟動，並且應急系統也無法運行這樣極端），是不會去採用恢復數據的方案的，因為數據量太大，恢復的時間太長，而運營商是要求業務能運行為第一要素的。
其次，人都是有依賴性的，當你知道你的系統有備份的時候，你的操作就開始不那麼如履薄冰了，就開始毛躁了，因為你的潛意識會認為，反正我的系統有備份，大不了恢復回來。
忘記你的系統有備份吧，忘記它吧。