Oracle DBA手記4：數據安全警示錄
蓋國強 著ISBN 978-7-121-17206-9
2012年7月出版
定價：65.00元
16開
404頁
宣傳語
災難與拯救 全真全程商業案例！
內 容 簡 介
這是一本寫給大家看的數據安全之書，不僅僅是給技術人員，更重要的是給企業數據管理者，如果不看這些案例，你也許永遠不會理解資料庫為何會遭遇到滅頂之災，你也許永遠無法理解為何千里之堤一朝潰於蟻穴。當然，這仍然是一本相當深入的技術書，作者將很多案例的詳細拯救過程記錄了下來，包括一些相當深入的技術探討，這些技術探討一方面可以幫助讀者加深對於Oracle資料庫技術的認知，另一方面又可以幫你在遇到類似案例時，做出同樣的營救工作。
作者介紹
蓋國強（網名Eygle），Oracle ACE總監，恩墨科技創始人，ITPUB論壇超級版主，遠程DBA服務的倡導者和實踐者，致力於以技術服務客戶。著有《深入解析Oracle》、《循序漸進Oracle》、《深入淺出Oracle》等書；從2010年開始，致力於《Oracle DBA手記》的撰寫與編輯工作，並與張樂奕共同創立了ACOUG用戶組，在國內推進公益自由的Oracle技術交流活動。前 言
未雨綢繆，防患未然在資料庫領域十幾年，我發現在國內技術人員往往在充當救火隊員的角色，企業也常常認為只有能夠力挽狂瀾、起死回生的技術人員，才是好的技術人員。而實際上，能夠不犯錯誤、少犯錯誤，提前預防、規避災難的技術人員才是企業技術環境的最有力保障，能夠未雨綢繆，防患於未然才是更好的技術實踐。
我們每年都幫助很多企業挽救數據、拯救危機。2011年12月30日和31日，連續的兩個整天，從凌晨再到凌晨，連續挽救了幾個用戶的資料庫。這些災難發生得那么簡單，那么不可思議，在邁入2012這個神秘年份的一刻，深深地觸動了我。我想，如果把這些案例描述出來，就可能讓一些用戶警醒，避免再陷入這樣的困境。而從別人的挫折中學習，進而在自己的環境中未雨綢繆，防患於未然，是每個資料庫管理人員和企業數據環境管理者應該具備的素質。
寫作本書還和2011年底眾多席捲而來的密碼泄露事件有關。當我注視著最常用的幾個密碼都在網際網路上被公開時，除了手忙腳亂地在各大網站修改密碼，剩下的就是深深的遺憾。幾乎所有從事IT行業的人，都深知安全的重要性，可是放在實際執行中，大家又往往習慣性失明，忽視了自己周圍本來力所能及之安全，很多專業人士就以這樣或者那樣的僥倖心理放任了風險的存在，並一步一步走向了安全危機。
對於資料庫安全來說，通常缺乏的並非技術手段，更多的是缺乏規範和安全認知，如果用戶都能夠嚴格遵循安全守則並套用現有的安全技術手段，資料庫的安全性就能夠大幅增強，我們的安全事故率也會大大降低。
於是我決定動筆，寫下自己多年來所遭遇到的安全案例，以及對於數據安全的思考。如果本書中的內容能夠幫助一些企業規避錯誤，保全數據，挽救一些技術人員的時間，那么我將感到無比欣喜。於我們的生命中，最為寶貴的就是時間，寸金難買寸光陰。
信息安全
在傳統的信息安全領域，存在三個基本的安全要素，這三個要素分別是：保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），簡寫為CIA。
這三個要素的基本定義如下。
保密性：指信息在存儲、使用和傳輸過程中不會泄露給非授權方。
完整性：指信息在存儲、使用和傳輸過程中不被非授權用戶篡改、變更，同時防止授權用戶對系統及信息進行非授權篡改，保持信息在整個過程中內外的一致性。
可用性：信息系統因其服務使命，必須在用戶需要時，可以被正常訪問。授權用戶或實體對信息系統的正常使用不應被異常拒絕或中斷，應當允許其可靠、及時地訪問和獲取信息及資源。高可用系統要求所有時間可用，要確保系統不因電源故障、硬體故障和系統升級等因素影響服務的可用性。
信息安全的三要素是對安全的概括和提煉。不同機構和組織，因為需求不同，對CIA的側重也會有所不同。隨著信息安全的發展，CIA經過細化和補充，增加了許多新的內容，包括可追溯性（Accountability）、抗抵賴性（Non-repudiation）、真實性（Authenticity）、可控性（Controllable）等。與CIA三元組相反的一個概念是DAD三元組，即泄漏（Disclosure）、篡改（Alteration）和破壞（Destruction）。實際上DAD就是信息安全面臨的最普遍的三類風險，是信息安全實踐活動最終應該解決的問題。
CIA的核心三要素涉及軟體（Software）、硬體（Hardware）和通信（Communications）三個方面
從CIA理念出發，通過對信息安全範疇所有相關主題精煉整理得到了一個標準化的知識體系——公共知識體系（Common Body of Knowledge，CBK）。CBK包括10個知識範疇（Domain），對安全進行了全面的概括，具有極強的指導意義。
以上10個範疇分別為：訪問控制，電信、網路和網際網路安全，風險管理和商務連續性計畫，策略、標準和組織，計算機架構和系統安全，法律、調查和道德，應用程式安全，密碼學，計算機操作安全，物理安全。
數據安全
信息安全的核心是數據安全。
在數據安全的範疇內，也包含信息安全的諸多方面。根據多年的服務經驗與思考，我們將安全劃分為五大方面，分別是：軟體安全、備份安全、訪問安全、防護安全和管理安全。
這五大方面是信息安全在數據領域的引申和映射。在企業數據安全中，這五大方面是相輔相成、互有交叉、共同存在的。
在這五大安全方向中，可能出現兩種性質的安全問題：第一，由於內部管理不善而導致的數據安全問題；第二，由於外部惡意攻擊入侵所帶來的安全問題。通常我們把安全問題狹義化為後者，這實際上是片面的，在數據安全問題上，前者造成的數據損失、數據損毀，其發生率和影響度都遠遠超過後者。
下面我們對數據安全的五大方面進行簡要的分析和探討。
軟體安全是指我們選擇的資料庫產品、版本是否穩定安全，廠商所能提供的補丁集和Bug修正是否及時，基礎硬體與作業系統是否經過認證。很多用戶在部署資料庫軟體時，僅僅選擇了最容易獲得的初始發布版本（如Oracle Database 10.2.0.1或者Oracle Database 11.2.0.1等），遺漏了可能已經存在的補丁修正，並且在運行維護中並不能夠及時跟蹤軟體更新，也無法獲得Bug信息、補丁修正和安全告警。這就使得軟體本身的很多風險隱患得不到修正。如果軟體安全無法保證，資料庫安全的基礎也就喪失了。
備份安全是指用戶數據能否得到及時有效的備份保全，能否在故障災難之後獲得及時的恢復和挽救。在資料庫運行期，最為重要的就是備份安全，如果沒有可靠的備份，將數據集中起來就只能是等待數據災難，所以我們將備份安全提升到核心地位，備份及隨之衍生的容災安全等，都是企業整體數據架構應該考慮的因素。很多企業在數據災難之後因為缺乏有效備份而一蹶不振。Gartner在2007年的一份調查報告顯示，在經歷了數據完全丟失而導致系統停運的企業中，有2/5再也沒能恢復運營，餘下的企業也有1/3在兩年內宣告破產。由此可見，由於備份安全問題導致的企業傷害可能遠遠大於黑客攻擊。
訪問安全是指用戶資料庫的訪問來源和訪問方式是否安全可控。通常資料庫系統處於IT系統的核心，其安全架構涉及主機、系統、存儲、網路等諸多方面。如果沒有明確的訪問控制，缺乏足夠的訪問分析與管理，那么資料庫的安全將是混亂和無法控制的。在套用軟體使用和訪問資料庫時，要正確設定許可權，控制可靠的訪問來源，保證資料庫的訪問安全。唯有保證訪問安全才能夠確保數據不被越權使用，不被誤操作所損害。通常最基本的訪問安全要實現程式控制、網路隔離、來源約束等。
安全防範是指通過主動的安全手段對資料庫通信、傳輸等進行增強、監控、防護、禁止或阻斷，諸如數據加密、審計、數據防火牆等技術都屬於這一範疇。我們必須認識到，在IT技術高度發展的今天，風險是無處不在、層出不窮的，可能我們從未思考過的安全問題每天都在不斷湧現，在資料庫環境中採取主動式防護，將可以幫助我們監控分析和禁止很多未知風險。目前已經有很多成熟的產品和技術可以用於安全防範。
管理安全是指在企業數據的日常管理維護範疇內，能否充分保證數據安全及服務的高可用連續提供。諸如DBA的維護、檔案的管理、參數或數據結構的變更等都可能引入數據風險，管理安全要求我們通過規範、制度及技術手段去確保維護管理安全。另外，基於硬體、電力等基礎平台的故障都可能影響資料庫服務的高可用性，在管理中要通過監控手段及時預警，通過集群、備庫等的切換與服務分擔保障服務的連續性。
這就是數據安全的五大方面。
業界安全事故
在2011年的新聞報導中，我們注意到很多企業遭受了嚴重的安全事故，影響深遠。以下摘錄了幾起廣為人知的數據安全事故，讓我們一起看一看安全問題都出現在了哪裡。
1. 陝西移動近1400萬條個人信息遭泄露
根據新聞報導（案件大約發生在2011年3月），犯罪嫌疑人所在的某技術公司承擔著陝西某電信企業手機資費計算系統軟體平台的開發、運行、維護、諮詢、防毒等多項工作，可以獲取該電信運營商擁有的手機用戶號碼、姓名、年齡、性別、身份證號、住址、每月通信費用等資料。
犯罪嫌疑人為了個人利益，竊取用戶信息並出售。
“朋友向我要西安、榆林、延安、渭南等六七個地市的移動手機每個月話費消費20元以上的信息，內容包括手機號碼、月話費消費情況、辦卡區域、機主性別、出生年月等，我同意了。第二天我在單位將計算機連線到省移動公司資料庫中，提取了1000餘萬條信息，每個地市建立一個資料夾，存儲到我的筆記本計算機中……”
2. 高陽捷迅工程師利用支付寶漏洞盜取11萬
2009年，支付寶公司開通話費支付業務，用戶可以通過購買手機充值卡充入支付寶賬戶後進行網上購物，高陽公司負責這一話費充值系統的運行維護。即在支付寶與移動、聯通、電信之間搭建平台，負責將支付寶用戶購買的手機充值卡轉變為支付寶賬戶的存款。
犯罪嫌疑人是負責這一系統維護的工程師，在2010年1月至3月間，他利用了這個系統的漏洞，多次通過網際網路進入高陽公司系統資料庫，調取用戶充值失敗而暫存於此的充值卡信息，然後將其轉入自己在支付寶設立的48個賬戶和在快錢設立的31個賬戶，總計111650元。
3. CSDN 600餘萬用戶密碼泄露事件
2011年12月21日，一組安全事件在國內引發了轟動，黑客在網上公開了CSDN網站用戶資料庫，包括600餘萬個明文的註冊信箱賬號和密碼可能遭集中曝光。事件發生之後，CSDN相關網頁更一度緊急關閉，以升級為由暫時關閉。
隨後又曝出了一系列的密碼安全事故，多家大型網站的用戶信息遭泄露。
4. PuTTY中文版後門事件
據2012年2月1日訊息，中文版PuTTY等SSH遠程管理工具被曝出存在後門，該後門會自動竊取管理員所輸入的SSH用戶名與口令，並將其傳送至指定伺服器上。根據分析，此次事件涉及來自和等站點的中文版PuTTY、WinSCP、SSHSecure和sftp等軟體，而這些軟體的英文版本不受影響。
5. 賽門鐵克遭黑客“破門”，千萬用戶信息安全存疑
台北時間2012年02月07日，一個容量達1.2GB、標題為“賽門鐵克的pcAnywhere原始碼遭泄露”的檔案出現在了BT網站，並開放提供下載。
賽門鐵克確認，pcAnywhere原始碼已被公開發布。這是黑客組織Anonymous在過去幾周中所聲稱已獲取的2006版本產品原始碼的一部分。黑客曾經向賽門鐵克索取5萬美元。
賽門鐵克在與黑客的電子郵件中表示：“我們將向你支付5萬美元。但是，我們需要確認你在收到錢後不會把原始碼發布到網際網路上。在起初的三個月中，我們將每月支付2500美元。我們將從下周開始向你支付這筆費用。在三個月結束之後，在我們支付餘款前，你要讓我們相信你已經銷毀了原始碼。我們相信你不會沒完沒了地討價還價。”
在經過了數周有關原始碼證據及如何轉賬的談判後，雙方未能達成一致，交易未能完成。
很快，在微博上出現了這樣的“段子”：“悲劇——安全軟體原始碼被黑客偷了；喜劇——人家只勒索5萬美元；悲劇——賽門鐵克要求分期付款，談崩了；喜劇——只好報警；悲劇——黑客發布原始碼……”
我們可以注意到，數據安全問題無處不在，從軟體到資料庫，從維護人員到黑客，損害安全的因素不是越來越少，而是越來越多。這些事件更警示我們，要不斷提升數據安全，防止安全事故的發生。
Oracle資料庫安全
其實Oracle資料庫自1977年肇始，就一直將安全置於首位，從強大的數據恢復機制，到不斷增強的加密及安全防範措施。“Oracle”這個名字就來自於美國中央情報局投資的項目代碼，而CIA也正是Oracle最早期的用戶之一。
接觸過Oracle資料庫的人都應當熟悉一個如下所示的錯誤“ORA-00942：表或視圖不存在”。這個簡單的錯誤提示，最初就是在CIA的要求之下作為一項安全防範設定的，其安全意義在於：避免提供任何具體的實質性提示信息，以預防黑客的攻擊性嘗試。由此可見，安全防範可以從每一個細節入手，安全是一項全面整體的技術實現，並非孤立地存在。
SQL> select * from emp;
select * from emp
*
ERROR at line 1:
ORA-00942: table or view does not exist
受密碼事件影響，我們首先在此從Oracle資料庫的密碼機制上來稍微深入了解一下Oracle的加密機制。雖然我們知道早在Oracle資料庫版本8的年代，就已經提供了強大豐富的資料庫加密功能，但是直至今日，恐怕半數以上的資料庫中，仍然存放著用戶的明文密碼，並且未採用任何資料庫安全增強機制。這也就是我認為最重要的安全問題：我們並不缺乏安全防範手段，但是缺乏對於安全風險的認知。
誠然，我們對於安全的認識是隨著不斷出現的安全事故逐步增強的，但是希望大家都能夠有計畫地逐步增強對於資料庫的安全防範，主動規劃推進數據安全與從挫折中學習提高實有天壤之別。對於2011年底的密碼泄露事件，如果各大網站能夠採取基本的技術手段對用戶密碼進行一定的加密，那么這次密碼泄露的安全事件就不會顯得那么初級和令人恐慌，想一想明文密碼和MD5加密串的區別。前者基本上意味著資料庫從未從安全形度進行過任何思考和增強。
Oracle資料庫的用戶信息及密碼存儲於一個名為USER$的數據表中（所有者為SYS用戶），我們可以通過基於USER$表建立的DBA_USERS視圖來查詢和獲得這些信息，包括加密的口令串。
在Oracle Database 11g之前，用戶口令通過DES加密算法進行加密，使用用戶名作為“Salt”，密碼最長為30個字元，所有字母被強制轉換為大寫。從Oracle 7至Oracle 10g，加密一直使用username和password串連之後進行HASH運算，因此像sys/temp1和system/p1將會獲得相同的HASH加密輸出。
從Oracle Database 11g開始，Oracle允許最多使用30個字元、大小寫混合方式作為密碼，同時支持DES和SHA-1算法進行加密（SHA-1算法支持大小寫混合，通過初始化參數SEC_CASE_SENSITIVE_LOGON開關），使用password||salt的方式進行HASH加密。
以下是Oracle 9i資料庫中口令的加密形式，DBA_USERS視圖的PASSWORD欄位顯示了加密後的密鑰。
口令的加密內容存儲在底層的核心表（USER$是Oracle資料庫的元數據表之一）中，以下PASSWORD欄位存儲的是DES加密值，SPARE4存儲的是SHA-1加密信息。
關於口令的維護，Oracle支持各種約束性限制（通過utlpwdmg.sql腳本啟用），諸如複雜程度、長度、有效期、失敗登錄次數等，通過這些增強，Oracle的口令限制可以定製出非常穩固的安全解決方案。如果你從未接觸和研究過這些手段，那么可能就說明你的資料庫還缺乏足夠的第一層安全防守。
如果我們能夠從Oracle的安全策略入手，學習一下Oracle的口令安全解決方案，就能夠構建一套較為完善的基本安全解決方案。從Oracle的第一個Internet版本Oracle 8i（1998年發布）開始，Oracle就提供了一個加密包DBMS_OBFUSCATION_TOOLKIT用於數據安全防護，這個加密包支持DES、3DES和MD5加密算法。
通過非常簡單的封裝調用，DBMS_OBFUSCATION_TOOLKIT包就能夠實現數據加密。以下是一個簡單的示例輸出，對於給定字元串進行MD5加密，以RAW方式返回加密結果（通過創建穩固的函式，可以實現用戶登錄時的即時加密、比較、認證）。
從Oracle Database 10g開始，DBMS_CRYPTO包被引入到資料庫中，該程式包支持更廣泛的加密算法，並用於替代DBMS_OBFUSCATION_TOOLKIT包。在新的版本中，諸如DES、3DES、AES、RC4、MD5、SHA-1、MD4、HMAC_MD5、HMAC_SH1等加密算法和加密方式都已被支持。
通過選定的加密算法和加密方式，可以對重要數據進行加密和解密，我們不僅可以實現對於密碼或數值、字元數據的加密，甚至可以對類似LOB等非結構化數據進行加密。以下範例使用了DES算法CBC模式和PKCS5補碼規則的加密解密實現，模擬對於信用卡卡號的處理過程。金融類企業數據的安全性更為突出，需要進行安全加密的類型更為豐富。
我想重申的是，各種不同的資料庫產品，都存在足夠成熟的安全實現手段，套用這些安全手段就能夠實現對於數據的基本保護。對於技術人最重要的是：認識和重視數據安全問題，並逐步推動企業或組織套用安全手段進行數據安全增強。重視數據，保護數據，這是每一位技術人的共同使命！
本書使命
本書所描述的所有恢復及安全案例全部確有其事，但是出於保護用戶隱私的考慮，我們隱去了所有客戶相關的信息，摘錄的內容涉及用戶判斷的，全部進行了處理，但是時間、故障內容一切屬實。多年來的災難挽救為我積累了很多素材，所以寫作這本書是一次回顧的旅程，以一條主線將眾多的災難挽救過程串聯起來。本書中的很多案例尚屬首次批露，而你也許還會注意到，書中的某些技術細節和恢複方法至今從未在其他地方看到過。
本書中的很多案例恢復非常艱難，拯救過程花費了大量的人力、物力和時間，我們也因此贏得了數百萬的商業契約，但是從內心上講，我們永遠不希望用戶陷入到這樣的境地，所以我寫作了這本書，以使這些曾經慘痛的教訓可以具備更廣泛的警示意義。
基於這些想法，我對每個案例的發生過程進行了描述，並且提出了供大家警示的規避法則。所以，我希望這是一本寫給大家看的數據安全之書，不僅僅是給技術人員，更重要的是給企業數據管理者，如果不看這些案例，你也許永遠不會理解資料庫為何會遭遇到滅頂之災，你也許永遠無法理解為何千里之堤一朝潰於蟻穴。
當然，這仍然是一本相當深入的技術書，我將很多案例的詳細拯救過程記錄了下來，包括一些相當深入的技術探討，這些技術探討一方面可以幫助讀者加深對於Oracle資料庫技術的認知，另一方面又可以幫你在遇到類似案例時，做出同樣的營救工作。
於我自身而言，年紀越長，就越是認識到這個世界上最為寶貴的就是時間，而如果我的分享，從警示到技術，能夠幫助大家規避錯誤，在恢復時不走彎路，快速拯救數據，節省工程師們和用戶的時間，這將是我最深刻之所願。拯救時間即為功德，這世界上，寸金永遠也買不到寸光陰。
這本書是用他人的災難為大家做警示，但願我們都能夠從中吸取教訓，永遠不要遇到本書所描述的種種災難。
致謝
感謝我的朋友們，他們對我的幫助和支持使得本書的很多內容得以成型。劉磊在ACOUG上的演講《猜測的力量》幫助我深入了關於REDO分析的案例；本書還引用了楊廷琨分析解決的一個ASM故障案例，此外，老楊提供的函式（收在附錄中）對我們非常有用。感謝用戶，是他們的信賴使我能夠接觸種種艱難的案例，並幫助他們挽回數據。感謝支持幫助過我的朋友們，以及一貫支持我的讀者們，本書中真摯的內容就是我最好的回報。
感謝我的好友丁曉強同學，他在支付寶公司進行了多年的安全與運維體系的建設與管理工作，他基於實踐而來的對於安全和運維的真知灼見給予了本書很多肯綮的建議，這些建議讓我對於安全有了更加系統全面的理解，從而對本書的架構做出了調整。雖然有很多想法最終沒能在本書中體現，但是我相信，仍然有機會在未來和大家繼續分享我從他那裡學來的寶貴經驗。
再次感謝楊廷琨。他在本書出版之前，通讀了全書書稿，細緻到幫我修改一個敲錯的字母，一個寫錯的漢字，這份細緻認真令我無比欽佩；他還幫助我增加了兩個警示條目，它們來自於他感觸最為深刻的技術經歷。老楊的工位和我相鄰，在工作中我隨時請教都可以即刻得到他絕妙的提示，為我節省了大量的工作時間，這是達成本書的另外一個重要助力。
我還要感謝我的太太Julia和兒子，以及我的家人。我為寫作這本書，犧牲了很多陪伴他們的時間，但也因為有他們的支持，我才能夠不斷地寫作下去。
最後，我希望書中這些看起來似乎很遙遠的故事，能夠警醒你某些似曾相識的操作，並且永遠不要面對這樣的災難。
蓋國強（Eygle）
2012-01-20 初稿
2012-03-01定稿於北京
目 錄
靡不有初，鮮克有終 1以空間之由——誤操作刪除數據檔案恢復案例兩則 3
災難描述 3
案例警示 4
技術回放 5
恢復過程——通過檔案描述符進行數據恢復 7
技術難點 21
通過BBED獲取檔案號信息 21
通過od命令獲得檔案號信息 24
以拯救之因——強制恢復導致ORA-600 4000錯誤案例 29
災難描述 29
案例警示 30
技術回放 31
恢復過程 35
ORA-600 4000錯誤揭秘 36
通過_minimum_giga_scn消除SCN異常 41
ORA-600 4194錯誤UNDO故障消除 45
以最佳化之名——存儲最佳化導致表空間誤刪除案例 49
災難描述 49
案例警示 50
技術回放 51
以安全之期 57
VALIDATE實現備份驗證 57
資料庫備份加密 60
口令模式 61
透明模式 63
混合模式 66
透明加密（TDE）技術 66
合抱之木，起於毫末 73
Oracle資料庫軟體發布序列 75
一個邏輯壞塊引發的災難 79
案例警示 79
技術回放 80
一個硬碟壞塊引發的災難 81
災難描述 81
案例警示 81
技術回放 83
AIX系統ODM簡介 83
ASM頭塊備份機制 84
kfed工具編譯與使用 87
手工修復ASM案例一則 91
災難描述 91
技術回放 91
PROVISIONED磁碟狀態分析 92
使用kfed修改ASM磁碟頭信息 94
ASM數據抽取恢復——通過AMDU恢複數據案例一則 101
災難描述 101
案例警示 101
技術回放 102
AMDU工具 102
檔案分析 105
AMDU檔案恢復 106
未雨綢繆，防患未然 109
DBA四大守則 111
DBA守則外兩則 113
各種慘痛的案例 117
系統級誤刪除案例 117
資料庫誤刪除案例 122
通過觸發器實現DDL監控 123
主備環境錯誤案例 132
業務高峰誤操作案例 136
備份級誤操作案例 139
進程級別誤操作案例 142
數據檔案誤操作案例 143
誤關閉生產庫案例 145
系統存儲級誤刪除案例 148
亡羊補牢，未為遲也 151
數據篡改案例解析 153
案例描述 153
案例警示 153
技術回放 154
故障分析的過程 155
日誌檔案的轉儲 157
LOGMNR解析 162
案例之深入解析 164
技術難點 176
密碼安全與加密 185
明察秋毫，見微知著 207
一次碰撞引發的災難——ASM保護式檔案離線引發故障 209
災難描述 209
案例警示 209
技術回放 210
恢復過程 214
又一次碰撞引發的災難——檔案離線與歸檔缺失案例 217
災難描述 217
案例警示 217
技術回放 219
恢復過程 224
空間與檔案離線——離線表空間載入修復 239
災難描述 239
案例警示 239
技術回放 240
恢復過程 248
技術提示 254
關於歸檔空間的設定 254
關於檢查點的一致性調整 258
心存目想，三思後行 265
Truncate導致的災難——核心字典表誤操作TRUNCATE 267
災難描述 267
案例警示 267
技術回放 268
恢復過程 274
腳本錯誤導致的災難——資料庫整體被刪除故障 281
災難描述 281
案例警示 281
技術回放 282
恢復過程 283
千里之堤，潰於蟻穴 291
一個字元引發的災難——大小寫字元疏忽導致的維護故障 293
災難描述 293
案例警示 293
案情解析 294
技術回放 302
一個盤符引發的災難——判斷失誤導致的誤格式化故障 315
災難描述 315
案例警示 315
技術回放 316
物盡其用，人盡其才 319
關庫與關機——強制關機導致的寫丟失故障 321
災難描述 321
案例警示 321
恢復過程 322
技術提示 351
從小恙到災難——重建控制檔案失誤導致的故障 353
災難描述 353
案例警示 353
技術回放 354
尺有所短，物有不足——硬體故障導致的災難一則 365
災難描述 365
案例警示 365
技術回放 366
附錄一BBED的說明 369
附錄二函式f_get_from_dump 372
參考資料 377
