本書源于眾多實踐案例的總結，我們將大量的數據安全事件、數據庫安全漏洞、Oracle數據庫災難恢復案例融合于一體，進行了詳細的闡述和分析，并總結形成了指導企業規范運維、強化管理、規避災難的指導原則。本書通過概括總結形成的數據庫運維原則，希望能夠給企業運維管理者以警示，通過提前預防措施和規范化管理避免遭遇到書中描述的種種情形；此外，本書還通過復雜的Oracle數據庫災難恢復案例，深入闡述了數據庫運行和工作的內部原理，希望能為讀者的深入技術探索提供幫助。本書既適合企業自動化和智能化運維的管理者參考，也適合深入學習數據庫技術的讀者學習探索。
云數據庫時代的技能升級
超復雜數據庫環境案例精粹
走向自動化、智能化的數據服務
安全 連續 高效 智能的解決方案實踐
再版序言
本書第一版最初寫于2012年，轉眼已經有8個年頭，當時還是Oracle 10g的天下，而現在19c已經發布。感謝電子工業出版社的支持，讓我有機會將這本書更新補充再次出版，有一些感觸在這里記錄下來，奉獻給支持我們的讀者們。
本書主旨
這本書是我所有作品中自己最喜歡的一本，也應該是對讀者和企業而言最有價值的經驗分享，所以這些年來我一直念念不忘，不斷記錄、不斷完善，希望能夠在新時代讓這本書再次發揮一些光和熱。
借助我在職業生涯中的所見所聞，本書將那些有關數據的風險和災難如實地刻畫下來，給讀者警示，引發思考，進而采取行動，制定原則，以規避和防范問題。
以我自己的職業生涯為例，我越是學習，就越是發現自己所知甚少，而所缺甚多，在飛速發展的信息技術領域，這種感覺往往使人焦慮。作為數據庫或者數據環境的管理者，崗位職責非常重大，在網絡上流傳著很多從刪庫到跑路的故事，往往在工作中的一個不慎，就會導致不可挽回的災難性局面，讓企業遭受滅頂之災。那么如何在這樣的環境下生存，并且不負企業或者客戶所托呢？
我想沒有什么比在工作中不斷建立指導自己工作的原則，并且堅持執行更加重要的事了。每年我們都會目睹很多因為疏忽造成的低級錯誤，比如誤刪數據文件、誤刪對Oracle生死攸關的Redo日志文件，這些問題和技能無關，但是事關工作原則。我曾經在一篇文章中寫到，知道如何繞過問題，往往比知道如何解決問題更重要。作為DBA的職業素養，應該包含一種稱為預感的能力，當我們需要執行某些任務的時候，應該敏銳地感知其中可能存在的風險點，然后設計方案進行防范或者迂回過去，而不是赴湯蹈火然后力挽狂瀾。
每個人都可以承認自己的知識有限，但是不能接受缺失行動準則。風險和災難千變萬化，而規則可以以不變應對萬變。
我在自己的工作歷程中，不斷總結提煉，形成了一系列指導自己工作的指導原則，通過這些原則的指引，我從未陷入不可控制的困境之中，也從未讓自己有失所托。過去我曾經在自己的網站和一些書籍中介紹過這些原則，其中包括DBA的四大守則、Oracle數據庫DevOps的三十六計等。
本書就是我的思考和總結，這些內容不一定適合你，但我希望，通過閱讀本書，讀者朋友們能夠思考和總結適合自己的行動原則，如果本書中記錄的案例、描述的法則能夠有一條讓大家有感，進而發揮作用防患于未然，那就是對作者最大的回饋。
本書的第一版在內容上走了兩個極端，一是通過極復雜的具體的災難處理過程，讓讀者能夠學習和掌握這些復雜案例的處理技能；二是通過極簡的案例描述和分析，提煉可以規避問題的法則，期望以原則來防范問題。
這兩個層面，也正是云和恩墨這些年走過的歷程。在創業之前，云和恩墨的技術團隊，以強大的單兵能力著稱，屢屢臨危受命力挽狂瀾并且久經考驗，幫助很多用戶挽救了大量的數據災難，本書中的很多案例就是這樣的。然而隨著服務體系的建立和完善，今天我們更加關注的是通過制定標準的服務流程和規范，通過內嵌服務理念的產品，幫助用戶防患于未然，不必再陷入這樣的境地。
前者治標，后者治本，顯然后者才是用戶真正期待的，而這些微小的技能和技巧，不過只是小道，又只有極少數的讀者能夠借鑒掌握并付諸實踐。
所以在本書的修訂過程中，我主要加強了對于后者的補充，期望在數據服務走向自動化和智能化的過程中，讓這些來自實踐的法則能給予讀者一些幫助和助力。而本書的第2章正是根據這樣的原則和思想高度提煉的，并早已在其他書籍中結集出版。
云數據庫時代
在本書第一版出版后的8年時間，數據庫領域已經發生了翻天覆地的變革，我以為，近代數據庫技術的發展可以劃分為三個階段，分別是：
? 商業數據庫時代：以Oracle、DB2、Sybase、SQL Server 等產品為代表，開創了一個企業級軟件時代。
? 開源數據庫時代：以MySQL、PostgreSQL、MongoDB、Redis 等產品為代表，推動和成就了互聯網時代。
? 云數據庫時代：以Oracle的自治數據庫、AWS 的 Aurora、阿里云的PolarDB等產品為代表，開創了云時代。
在商業數據庫時代，發展出一批偉大的產品和公司，Oracle 是其中的代表，至今仍以近2000億美元的市值屹立，這個時代的商業數據庫成就了一系列龐大的企業級軟件，ERP、CRM 等領域都有相當體量的企業存在，這個時代也是企業級軟件的時代，微軟 和 IBM 都有卓越的數據庫產品，曾經三足鼎立的數據庫時代漸漸發展成Oracle一枝獨秀的態勢。
在開源數據庫時代，呈現出百花齊放的生態，支撐和成就了互聯網行業，然而這些開源數據庫產品本身并未獲得應有的價值回報，近期很多開源數據庫都在調整其開源協議，尤其是面對云的時代變革。歷數開源時代的代表，MySQL 以10億美元賣身SUN公司，輾轉落入Oracle囊中，大數據的標志 Cloudera 和 Hortonworks 合并也僅僅 50億左右的市值，MongoDB 市值40億美元左右，Elastic 市值 25億左右，這些數據庫產品的總市值還不及微軟以262 億美元全現金收購的LinkedIn，這是互聯網的時代。
在云數據庫時代，數據庫則成了云內核的一部分或一個組件，甚至不復單獨存在，Amazon 提供 Redshift 和 Aurora 等多種數據庫產品，阿里云有 PolarDB 等多種數據庫，在這個時代，云才是永恒的主角，數據庫漸漸沉淀在底層，依托云的價值而存在，AWS、微軟、Google、阿里巴巴成了云時代的主角。
數據庫領域經歷了分分合合，再次呈現出百花齊放的局面，這讓我想起《易經》的一句：見群龍無首，吉。唯有百花齊放，才見活力，企業也才有選擇的自由。
誠然，大時代風起云涌，但是如果落地到企業級，我們認為用戶的核心訴求仍然是不變的，云和恩墨從創業開始，就在企業手冊中描述了這樣一個認知，無論對于數據庫還是IT架構，用戶的核心訴求安全、連續、高效和智能不曾改變。所以我曾經的主題演講用了8個字：穩筑基石，云帆萬里。只有打好基礎，才能云途高遠，否則一切都只是空中樓閣，遇到真正的危機就可能轟然倒塌。
就企業的核心數據而言：
? 安全：安全是基石，尤其是云時代的數據安全，沒有數據安全，甚至就沒有企業生存，歐盟在2018年5月25日生效了 GDPR 法案，對安全做出了嚴格的要求，對違反者可以做出2000萬歐元或企業全球年營業額4%的重量級處罰。
? 連續：連續運行是云時代和互聯網時代的核心訴求，無連續就無發展，傳統企業也漸漸走上了247不間斷服務的道路上來，數據庫的連續運行只是其中的一環。
? 高效：性能是支持業務高速增長、獲得競爭力的關鍵，是成本和效率的核心。
? 智能：智慧智能是未來科技的必然發展方向，是企業競爭的制高點，是產品和技術演進的終極目標，信息技術的各個環節都在走向智能化。
如前所訴，今天數據庫的競爭已經轉移到了云，而云時代的數據庫更多的是依托前兩個時代的技術積累，繼承其一致性、可用性，增強了在分布式、彈性伸縮、安全方面的能力，應云而生、為云而生，誰能夠在云上掌握話語權，誰才能夠在未來的云時代掌握數據先機。
然而無論在什么時代，云上還是云下，數據安全都是企業最重要的核心訴求，云時代安全問題更加突出，這樣看來，本書在今天的意義遠遠超越了本書第一版。
產品理念
隨著百花齊放的云數據時代的到來，我們發現企業面臨的數據應用和運維形態正在變得更加復雜，下圖中的數據庫產品往往大量存在于企業生產環境中，企業的數據庫品類往往從以前的兩三種，增加到今天包含商業數據庫和開源數據庫在內的七八種，這對企業的技術管理能力帶來了巨大的挑戰。
所以我認為今天的企業數據平臺建設，應當改變思想，從自底向上轉變為自頂向下。所謂自底向上是指，先根據業務系統的需要引入各種數據庫，再向上謀求統一和簡化的管理；而自頂向下則是指，先構建平臺化的數據管理能力，再引入能夠統一管理收縮自如的數據庫產品。
遵循數據管理平臺化、統一化的思想，以及數據庫運維自動化和智能化的思路，云和恩墨研發了融合多數據庫管理于一體的zCloud云平臺，只有真正具備了統一和自動化的管理能力，才能夠應對云數據庫時代復雜多樣化的數據庫環境。
談到數據庫運維就離不開性能，而性能的核心要素是應用。在應用層業務總是通SQL來訪問數據，控制住SQL 也就控制住了系統的性能和穩定性，我們可以回想，以前DBA面對一個數據庫時就曾經四處救火、焦頭爛額，如果在云時代面臨 5~10 種數據庫將會是什么局面？
我們必須改變線上優化排障的局面，防患勝于救災。
云和恩墨的 SQM （SQL 質量審核和性能管理）平臺致力于在開發測試環節發現和解決SQL性能問題，通過自動化和智能化實現性能管控也就規避了線上救火。SQM的審核功能，正是總結了來自實踐中的優化原則并內置到開發測試過程中的，以DevOps理念實現了預防性優化。
當然，本書反復強調對于企業數據環境而言，備份重于一切，有備方能無患，所以云和恩墨獨立研發了ZDBM數據庫備份一體機產品，可以通過實時的在線Redo備份實現近零數據丟失的數據保護，幫助用戶防范意外的數據損失。
云和恩墨的產品歷程，就是我們團隊用過去職業生涯的知識積累、用戶實踐不斷思考的成果輸出，這些產品中涵蓋了本書所陳列的各種運維安全原則，我們期望通過思考輸出的作品和產品化的能力，能夠幫助更多的讀者和企業規避數據運維和管理風險。而這些產品中有很多都已經通過SaaS或其他形式免費提供給用戶，包括智能巡檢平臺Bethune，在線SQL審核和技術問答墨天輪，MySQL數據庫一體機MyData 等等。
致謝
首先，我要感謝楊廷琨老師，在本書修訂的過程中，他再次給予我很多真知灼見，并且提供了幾個有趣的案例。他在技術方面的不斷探究、沉穩敏銳，永遠是我學習的榜樣。
其次，我要感謝云和恩墨的技術團隊，他們在面臨壓力、迎接挑戰、排憂解難的過程中，踐行了我們的理想和原則，不
蓋國強 云和恩墨創始人，Oracle ACE總監 蓋國強先生是中國地區首位Oracle ACE和ACE總監，曾獲評"中國首屆杰出數據庫工程師"獎，擁有近20年的數據行業咨詢和實踐經驗，著有《深入解析Oracle》、《循序漸進Oracle》等技術書籍。蓋國強先生于2011年發起創立云和恩墨公司，致力于以『數據驅動，成就未來』為使命，為企業和用戶提供卓越的數據產品和服務。
第1章 知己知彼 忘戰必危1
1.1 危機四伏，數據注定泄露1
1.2 從羅維鄧白氏案例看數據道德4
1.3 數據庫管理員出售新生兒信息6
1.4 美國上千萬信用卡信息疑遭盜取7
1.5 數據外泄主要來自內部8
1.6 GDPR帶來的數據安全思考9
1.7 數據庫的漏洞都會重來12
1.8 那些運維中的疏忽導致的數據風險16
1.9 參考資料18
第2章 運籌帷幄 三十六計20
2.1 有效的備份重于一切21
2.2 測試環境和生產環境隔離24
2.3 禁止遠程的和業務時間的DDL操作26
2.4 ORACLE數據庫DEVOPS的三十六計37
2.5 參考資料40
第3章 合抱之木 生于毫末41
3.1 ORACLE數據庫軟件發布序列42
3.2 DB LINK必須升級的預警48
3.3 SQL語句注入和CVE-2017-10282警告71
3.4 JAVA VM的反序列化86
3.5 從一次UPDATE的優化講起94
3.6 一個邏輯壞塊引發的災難104
3.7 參考資料106
第4章 靡不有初 鮮克有終107
4.1 以空間之由恢復誤刪數據文件案例109
4.2 以拯救之因強制恢復導致ORA-600 4000錯誤的案例133
4.3 以優化之名存儲優化導致表空間誤刪案例152
4.4 以安全之期159
4.5 以便利之機175
第5章 未雨綢繆 防患未然180
5.1 DBA四大守則182
5.2 DBA守則外四則183
5.3 各種慘痛的案例187
5.4 參考資料210
第6章 亡羊補牢 未為遲也212
6.1 數據篡改案例解析213
6.2 密碼安全與加密244
6.3 分析與恢復被篡改的敏感數據266
6.4 參考資料271
第7章 明察秋毫 見微知著272
7.1 一次小碰撞引發的災難ASM保護式文件離線引發故障273
7.2 又一次小碰撞引發的災難文件離線與歸檔日志缺失 的案例281
7.3 空間與文件離線離線表空間修復303
7.4 對寫文件錯誤的處置改進331
第8章 心存目想 三思后行339
8.1 TRUNCATE導致的災難核心字典表誤操作TRUNCATE340
8.2 腳本錯誤導致的災難數據庫整體被刪除故障353
第9章 千丈之堤 潰于蟻穴363
9.1 一個字符引發的災難大小寫字符疏忽導致的維護故障364
9.2 一個盤符引發的災難判斷失誤導致的誤格式化故障385
9.3 一個BEGIN引發的災難389
9.4 一個空格引發的事故404
9.5 一個壞塊引發的災難406
9.6 一個標志位的影響422
9.7 一個磁盤添加引發的故障通過AMDU恢復數據的 案例一則431
第10章 物盡其用 尺有所短439
10.1 關庫與關機強制關機導致的寫丟失故障441
10.2 從小恙到災難重建控制文件失誤導致的故障470
10.3 尺有所短，物有不足硬件故障導致的災難一則480
10.4 由性能問題而追溯的磁盤故障483
10.5 靜默錯誤引起的數據災難488
10.6 ORACLE的寫丟失檢測特性496
10.7 ORACLE 12.2的寫丟失檢測增強503
10.8 參考資料507
附錄A：BBED的說明509
附錄B：函數F_GET_FROM_DUMP:512
數據驅動，成就未來517
新書資訊