Oracle DBA手记 4，数据安全警示录（修订版）

《Oracle DBA手记 4，数据安全警示录（修订版）》源于众多实践案例的总结，我们将大量的数据安全事件、数据库安全漏洞、Oracle数据库灾难恢复案例融合于一体，进行了详细的阐述和分析，并总结形成了指导企业规范运维、强化管理、规避灾难的指导原则。

《Oracle DBA手记 4，数据安全警示录（修订版）》通过概括总结形成的数据库运维原则，希望能够给企业运维管理者以警示，通过提前预防措施和规范化管理避免遭遇到书中描述的种种情形；此外，本书还通过复杂的Oracle数据库灾难恢复案例，深入阐述了数据库运行和工作的内部原理，希望能为读者的深入技术探索提供帮助。

《Oracle DBA手记 4，数据安全警示录（修订版）》既适合企业自动化和智能化运维的管理者参考，也适合深入学习数据库技术的读者学习探索。

盖国强

云和恩墨创始人，Oracle ACE总监。

盖国强先生是中国地区首位Oracle ACE和ACE总监，曾获评"中国首届杰出数据库工程师"奖，拥有近20年的数据行业咨询和实践经验，著有《深入解析Oracle》、《循序渐进Oracle》等技术书籍。盖国强先生于2011年发起创立云和恩墨公司，致力于以『数据驱动，成就未来』为使命，为企业和用户提供卓越的数据产品和服务。

云数据库时代的技能升级

超复杂数据库环境案例精粹

走向自动化、智能化的数据服务

安全+连续+高效+智能的解决方案实践

本书第一版最初写于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%的重量级处罚。

? 连续：连续运行是云时代和互联网时代的核心诉求，无连续就无发展，传统企业也渐渐走上了24×7不间断服务的道路上来，数据库的连续运行只是其中的一环。

? 高效：性能是支持业务高速增长、获得竞争力的关键，是成本和效率的核心。

? 智能：智慧智能是未来科技的必然发展方向，是企业竞争的制高点，是产品和技术演进的终极目标，信息技术的各个环节都在走向智能化。

如前所诉，今天数据库的竞争已经转移到了云，而云时代的数据库更多的是依托前两个时代的技术积累，继承其一致性、可用性，增强了在分布式、弹性伸缩、安全方面的能力，应云而生、为云而生，谁能够在云上掌握话语权，谁才能够在未来的云时代掌握数据先机。

然而无论在什么时代，云上还是云下，数据安全都是企业最重要的核心诉求，云时代安全问题更加突出，这样看来，本书在今天的意义远远超越了本书第一版。

产品理念

随着百花齐放的云数据时代的到来，我们发现企业面临的数据应用和运维形态正在变得更加复杂，下图中的数据库产品往往大量存在于企业生产环境中，企业的数据库品类往往从以前的两三种，增加到今天包含商业数据库和开源数据库在内的七八种，这对企业的技术管理能力带来了巨大的挑战。

所以我认为今天的企业数据平台建设，应当改变思想，从自底向上转变为自顶向下。所谓自底向上是指，先根据业务系统的需要引入各种数据库，再向上谋求统一和简化的管理；而自顶向下则是指，先构建平台化的数据管理能力，再引入能够统一管理收缩自如的数据库产品。

遵循数据管理平台化、统一化的思想，以及数据库运维自动化和智能化的思路，云和恩墨研发了融合多数据库管理于一体的zCloud云平台，只有真正具备了统一和自动化的管理能力，才能够应对云数据库时代复杂多样化的数据库环境。

谈到数据库运维就离不开性能，而性能的核心要素是应用。在应用层业务总是通SQL来访问数据，控制住SQL 也就控制住了系统的性能和稳定性，我们可以回想，以前DBA面对一个数据库时就曾经四处救火、焦头烂额，如果在云时代面临 5~10 种数据库将会是什么局面？

我们必须改变线上优化排障的局面，防患胜于救灾。

云和恩墨的 SQM （SQL 质量审核和性能管理）平台致力于在开发测试环节发现和解决SQL性能问题，通过自动化和智能化实现性能管控也就规避了线上救火。SQM的审核功能，正是总结了来自实践中的优化原则并内置到开发测试过程中的，以DevOps理念实现了预防性优化。

当然，本书反复强调对于企业数据环境而言，备份重于一切，有备方能无患，所以云和恩墨独立研发了ZDBM——数据库备份一体机产品，可以通过实时的在线Redo备份实现近零数据丢失的数据保护，帮助用户防范意外的数据损失。

云和恩墨的产品历程，就是我们团队用过去职业生涯的知识积累、用户实践不断思考的成果输出，这些产品中涵盖了本书所陈列的各种运维安全原则，我们期望通过思考输出的作品和产品化的能力，能够帮助更多的读者和企业规避数据运维和管理风险。而这些产品中有很多都已经通过SaaS或其他形式免费提供给用户，包括智能巡检平台Bethune，在线SQL审核和技术问答墨天轮，MySQL数据库一体机MyData 等等。

致谢

首先，我要感谢杨廷琨老师，在本书修订的过程中，他再次给予我很多真知灼见，并且提供了几个有趣的案例。他在技术方面的不断探究、沉稳敏锐，永远是我学习的榜样。

其次，我要感谢云和恩墨的技术团队，他们在面临压力、迎接挑战、排忧解难的过程中，践行了我们的理想和原则，不断为云和恩墨“数据驱动，成就未来”的企业理念添砖加瓦。

最后，我要感谢我的家人，虽然他们并不懂得这些技术内容的真实含义，但是他们与我共度了很多处理问题的艰难时光，给予我坚定不移的支持，并且永远是我奋斗的动力源泉。

最后的最后，我要感谢一直支持我的读者和客户们，正是你们的支持才让我继续保有分享开放的机缘，不揣浅薄，不断诉说。

但愿书中这些看起来似乎遥远的故事，能够警醒读者某些似曾相识的场景，并且永远不要面对这样的灾难。

盖国强（Eygle）

2019年3月3日　于北京

2012-01-20 初稿

2012-03-01 定稿　于北京

第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导致的灾难――核心字典表误操作TRUNCATE 340
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