未雨绸缪，DBA四大安全守则及各种数据库灾难案例丨文末送书

导读：日前，我的新书《Oracle DBA手记4：数据安全警示录》(修订版)出版了，按照我一贯坚持的开源原则，今天分享书中的第五章节——DBA四大守则、DBA守则外四则、各类数据库安全的惨痛案例，希望可以帮助到读者朋友们。

此外，感谢博文视点对我一直以来的支持，并给这篇文章留言的读者赠送出三本书，文末有赠书参与方式，欢迎参与活动。

云数据库时代的技能升级

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

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

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

640?wx_fmt=jpeg

本书概要

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

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

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

本书目录

第1章知己知彼忘战必危
1.1危机四伏，数据注定泄露
1.2从罗维邓白氏案例看数据道德
1.3数据库管理员出售新生儿信息
1.4美国上千万信用卡信息疑遭盗取
1.5数据外泄主要来自内部
1.6GDPR带来的数据安全思考
1.7数据库的漏洞都会重来
1.8那些运维中的疏忽导致的数据风险
1.9参考资料
第2章运筹帷幄三十六计
2.1有效的备份重于一切
2.2测试环境和生产环境隔离
2.3禁止远程的和业务时间的DDL操作
2.4ORACLE数据库DEVOPS的三十六计
2.5参考资料
第3章合抱之木生于毫末
3.1ORACLE数据库软件发布序列
3.2DB LINK必须升级的预警
3.3SQL语句注入和CVE-2017-10282警告
3.4JAVA VM的反序列化
3.5从一次UPDATE的优化讲起
3.6一个逻辑坏块引发的灾难
3.7参考资料
第4章靡不有初鲜克有终
4.1以空间之由——恢复误删数据文件案例
4.2以拯救之因——强制恢复导致ORA-600 4000错误的案例
4.3以优化之名——存储优化导致表空间误删案例
4.4以安全之期
4.5以便利之机
第5章未雨绸缪防患未然
5.1 DBA四大守则
5.2 DBA守则外四则
5.3 各种惨痛的案例
5.4 参考资料
第6章亡羊补牢未为迟也
6.1 数据篡改案例解析
6.2 密码安全与加密
6.3 分析与恢复被篡改的敏感数据
6.4 参考资料
第7章明察秋毫见微知著
7.1 一次小碰撞引发的灾难——ASM保护式文件离线引发故障
7.2 又一次小碰撞引发的灾难——文件离线与归档日志缺失的案例
7.3 空间与文件离线——离线表空间修复
7.4 对写文件错误的处置改进
第8章心存目想三思后行
8.1TRUNCATE导致的灾难——核心字典表误操作TRUNCATE
8.2脚本错误导致的灾难——数据库整体被删除故障
第9章千丈之堤溃于蚁穴
9.1 一个字符引发的灾难——大小写字符疏忽导致的维护故障
9.2一个盘符引发的灾难——判断失误导致的误格式化故障
9.3一个BEGIN引发的灾难
9.4一个空格引发的事故
9.5一个坏块引发的灾难
9.6一个标志位的影响
9.7一个磁盘添加引发的故障——通过AMDU恢复数据的案例一则
第10章物尽其用尺有所短
10.1关库与关机——强制关机导致的写丢失故障
10.2从小恙到灾难——重建控制文件失误导致的故障
10.3尺有所短，物有不足——硬件故障导致的灾难一则
10.4 由性能问题而追溯的磁盘故障
10.5静默错误引起的数据灾难
10.6 ORACLE的写丢失检测特性
10.7 ORACLE 12.2的写丢失检测增强
10.8 参考资料
附录A：BBED的说明
附录B：函数F_GET_FROM_DUMP
数据驱动，成就未来

以下为摘取《Oracle DBA手记4：数据安全警示录》第五章的内容：

在企业数据环境中，已经有很多DBA因为疏忽而遭受了惨痛的教训。了解和学习这些案例，可以帮助我们熟悉常见的错误种类和错误条件，进而增强规范意识、建立约束制度及制定防范措施，规避和减少技术风险，保障数据环境的安全运行。

在数据管理阶段出现的问题，被定义到管理安全的范畴里。在这一阶段，如果企业缺乏足够的管理规范，就可能出现很多安全事故，诸如误删除、Trucate数据表等。
下图列举了管理安全范畴中可能涉及的诸多方面。

在本章中，我们将主要描述各行业DBA遭遇的管理安全问题。从这些现实案例中总结经验，吸取教训，进而未雨绸缪，防患于未然。这也是每个致力于企业数据运营的人的职责所在。

5.1 DBA四大守则

通过分析所经历的各种案例，我们总结出了DBA生存四大守则，用于提醒DBA在工作中应当注意和遵循的内容，这些守则直至今天仍然具有其现实意义。

下面就是需要我们铭记于心的DBA生存守则。

1．备份重于一切

我们必须谨记，系统总是会崩溃的，硬盘总是会损坏的；如果没有有效的备份，迟早会有大麻烦。唯一会使DBA在梦中惊醒的事情是没有有效的备份。

DBA都应该在睡前想一想，如果那个没有备份的数据库，在今晚遭遇硬盘损毁，那么明天该如何去恢复数据和业务呢？

2．三思而后行

Think thrice before you act.

任何时候都要清楚地了解你所做的一切，否则宁可不做！

我们见过太多由于草率的操作导致的数据灾难。有时候一个回车、一条命令就会造成不可恢复的灾难。所以，你必须清楚地了解所做的一切，并且在必要时保护现场，以保证你的操作至少不会使事情变得更糟。

3．rm是危险的

要知道在UNIX或Linux环境下，执行rm意味着可能永远失去后面的东西，所以，必须要确认你的操作正确无误。

太多的人因为使用rm -rf悲痛欲绝了。当年写下这条守则，是因为在一个凌晨被一位朋友吵醒，他说因为误操作rm -rf删除了200GB的数据，并且没有备份。

我当时能告诉他的只有一句话：保持冷静，离开键盘，然后让你的领导知道这件事。

作为一名技术人员，当事情超出你的掌控时，最好的决定就是让更多的人知道这件事，通过共同的决策来制定恢复方案，以防止因为个人再次判断失误造成进一步的损失。

rm是危险的，以此类推，在数据库内部执行DROP、TRUNCATE、RESETLOGS等破坏性操作时，以及在数据库外执行DD、FORMAT等操作时，同样应当谨慎，小心一万次也不为过，疏忽一次就可能致命。

4．制定规范

良好的规范是减少故障的基础。所以，作为一名DBA，需要制定规范来约束开发人员甚至系统管理人员。这样可以规避误操作，减少数据库的风险。

而作为企业数据环境的管理人员，更应该从管理流程上制定规范，防止因管理流程不当而导致的数据安全问题甚至数据灾难。

在管理良好的数据库服务器上，rm -rf甚至是不被允许使用的。

作为DBA一定要严谨专注，在管理数据库的同时，要承担起数据责任，不能有丝毫的马虎和大意，草率的判断和轻忽的选择对数据来说很可能是致命的。

以上四大守则，愿与诸位DBA共勉。

5.2 DBA守则外四则

在本书第1版出版6年之后，当我再次思考这些重要的法则时，有两种情况十分清晰地跳跃了出来，虽然这两种情况其实可以包含在前面的四大守则之中。

1．数据库重做日志安全

在Oracle数据库中，重做日志的写入优先于数据文件。如果意外损坏数据库正在使用的日志文件，则数据库将遭受数据损失，面对这种情形，备份是无能为力的。

那么哪些情况可能导致日志损坏呢？大敌只有一个：误操作。

我们目睹了无数惨痛的案例，这些误操作包括如下情形。
•   在清理空间时，删除 .log 扩展名的所有文件，Redo日志被消灭
•   在主库同主机构建恢复环境时，遗漏了控制文件日志路径修改，RESETLOGS重置了主库日志
•   强制关闭数据库而导致的Redo日志意外损坏
当面对这种意外情况时，如果判断失误，会让情况变得更糟。此时，如果使用备份覆盖当前数据文件进行恢复，一旦Online Log没有归档，那么其中所有的事务都会丢失；如果保留当前数据文件，则丢失的数据仅限于最后提交未写入数据文件的内容。

那么如何规避这样的问题发生呢？

• 不要在生产环境下进行任何测试验证
即便是最专业的DBA，当修改控制文件时都可能有所遗漏。在主库同主机搭建备库或测试环境时，任何一个操作都是非常危险的，所以不要这样做。

• 不要批量清理任何日志文件
这个问题毋庸多说，在生产环境下进行任何操作都应该具备严格的规范。建议在建立数据库时，将Redo日志文件的扩展名改为 .dbf ，这样也许能躲过很多劫难。

• 不要覆盖任何未备份的文件
如果没有100%的信心，就不要试图通过restore恢复覆盖未备份的数据文件，因为一旦出现问题，就无可挽回了。

无数专业的DBA都曾在这个问题上遭遇“滑铁卢”，不同的数据库在日志原理上基本相同，确保日志安全就是确保数据一致性。DBA要切记。

2．数据库存储卷安全

在过去几年里，我亲眼目睹了很多与存储卷相关的数据灾难，将其归纳在这个守则中，典型情况有两大类。
• 对数据库存储磁盘误发出DD清除命令
• 将在用磁盘添加到其他磁盘组中

以上两种情况往往是级联的，很多灾难是在进行空间扩容时发生的。DBA找到新的磁盘，通过DD进行擦除，然后加入现有的磁盘组中。结果发现被擦除的磁盘是在用的数据库存储卷。

这是一种低级错误，但是在生产实践中层出不穷，造成非常严重的生产事故。

那么如何解决这类问题呢？

如果能够遵循相关规范和流程就能够避免（前提是有规范）。例如，在进行磁盘的破坏性操作时，明确根据记录去比对确认，确保被初始化使用的磁盘是空闲的；如果没有规范，DBA也应该对维护的数据库建立数据库基本信息档案，在进行重要变更时必须对比查询，以防误操作带来损失。

在Oracle 12c中，新特性ASMFD就被用于防范数据库之外的操作对数据盘的侵入破坏，这个特性在本书后面的章节中进行了详细介绍。

在《Oracle DBA手记 2》一书中，我的朋友——作者之一郭岳，在文章中曾经提出了几点DBA守则，我深以为然，并对其中两点略作引申，作为DBA守则外四则的第3点、第4点，收录在这里供大家参考。

3．高度的信息安全意识

本书的宗旨是安全，在数据安全的诸多方面里，信息安全是核心环节。DBA或相关技术人员能够接触到核心数据，虽然用于防范DBA获取数据的各种技术手段在不断发展，但是接触也就意味着责任，权利与责任从来都是如影随形的。能够访问、获取数据，并不意味着可以去利用和传播这些数据。DBA的职业道德要求大家只需完成责任范围之内的数据库维护即可，对于业务数据应当敬而远之，视而不见。

2011年，一则新闻触动了很多数据工作者的神经。陕西1400多万手机用户的信息被泄露，不法分子利用这些信息以短信推广等方式进行非法获利活动。对于运营商来说，拥有用户信息的同时也意味着要承担保护这些数据的责任，如果不能保障这些数据的安全，那么这些数据就可能被不法分子利用，去侵犯公民的个人隐私甚至经济利益。而对数据工作人员来说，接触数据的同时也要遵守职业道德和法律法规，坚决避免不必要的信息泄露和传播。

下面是这个案件的相关信息。

根据2011年9月23日的新闻报道，西安警方破获了全国首例非法出售、获取公民个人信息的案件。

据了解，这一案件导致陕西省近1400万手机用户的个人信息被泄露。

根据最后的破获结果，犯罪嫌疑人是一家科技公司的技术人员，他代表公司负责研发和维护陕西省某通信公司的计费经营系统。

2011年3月以来，他利用工作便利，多次侵入这家通信公司的用户数据库，盗取手机用户的个人信息。

2011年4月，他应另一嫌疑人的要求，再次侵入某通信公司客户数据库，窃取了西安、咸阳、铜川等7个地市1394万手机用户的个人信息。

据警方介绍，这1394万手机用户，占全省手机用户总量的60%~70%。这些信息被非法交易的背后，是利益的驱动，利益让4名犯罪嫌疑人形成了非法利益链条。警方同时指出，该案件的侦破，也暴露出通信运营商和为通信运营商提供技术支持的科技企业，都存在监督职责缺失的问题。

律师认为，盗取手机信息的技术人员，首先违反了民事法律规定，须承担相应民事赔偿责任。刑法修正案中也有涉及泄露、盗取私人信息的相关规定：非法泄露个人信息，最高可判三年有期徒刑。

国家机关或者金融、电信、交通等单位的工作人员，违反国家规定，将本单位在履行职责或者提供服务过程中获得的公民个人信息，出售或者非法提供给他人，情节严重的，处三年以下有期徒刑或者拘役，并处或者单处罚金。窃取或者以其他方法获取上述信息，情节严重的，依照前款的规定处罚。

5.3 各种惨痛的案例

我们曾经收集过DBA曾经犯过的各种错误，这些信息千奇百怪、五花八门。对于管理者来说，了解这些错误有助于制定规范、防范问题的发生；对于DBA来说，则有助于吸取教训，增长经验，防患于未然。

对于这些案例，我大多数都保留了原始的描述和记录，只做了一些简单的编辑整理和分类工作。这些案例收集自网络，与大家共为警醒。

[主备环境错误案例]

很多企业，或者很多DBA有一个不良习惯，就是他们常常忽视生产环境和测试环境的区别，他们甚至不做环境校验就草率地执行任务，结果造成很多不应该发生的灾难和错误。

下面是一系列因为混淆生产环境和测试环境而出现的错误。

案例概述	案例详情
混淆生产与测试环境	最严重的一个数据库错误是，在生产环境下执行一个测试环境的脚本。结果导致用户无法连接数据库
混淆生产与测试环境	有一次本来要删除测试库，结果差点删除了生产库的一个表的所有数据，还好强行使用Ctrl+Alt+Delete组合键回滚了，一条数据都没有被误删除。当时确实是因为快下班了，比较累。以后不能在心急的时候维护数据库
混淆生产与测试环境	向测试库导入数据，不小心把生产库DROP了
混淆生产与测试环境	我犯过的错误也不少，很多情况是由于测试库环境跟生产库的不太一样，结果在测试库中没有出问题的脚本，在生产库里出问题了。所以在执行脚本时，还是要仔细检查一下，在生产库中的环境是否一致
混淆生产与测试环境	有一次把dmp文件导到生产环境中了，而它本应该在测试环境下
混淆生产与测试环境	为了给员工做培训，我把生产库的数据导入到了测试库上，但是不知道谁修改了机器上的盘点系统的配置文件，结果虽然显示的是测试库，实际上是生产库，在imp过程中其实已经表现异常了。但我没意识到，幸好，这个dmp文件的时间点只差2 h，当时的中间操作不多
混淆生产与备份环境	最惨的一次是和一个同事一起出差，那个同事不知道出于什么考虑，将主服务器和备份服务器的IP地址换了一下，但是tnsnames没做修改。当我准备重做备服时，使用了drop user cascade，把所有的用户都删除了。刚刚干完，所有科室上夜班的护士都开始给我打电话，说科室里的电脑全部不能用了。当时急得不行，还好习惯还不错，在前一天做了一个全库冷备，于是立刻进行了恢复，不过也丢失了一整天的数据

针对这些情况，有以下几个建议。

1．测试环境和生产环境应当处于不可互通的物理网络中

互通就意味着可以同时访问，也就可能带来很多意想不到的安全风险。企业应当将测试环境和生产环境部署于不可互通，或不可同时访问的网络环境中，避免因为错误连接而发生的数据库灾难。

分离部署一方面可以降低误操作的可能性，另一方面也可以屏蔽一些无关的访问可能，从而从网络链路上保证数据安全。

2．在执行任务之前确认连接访问的数据环境

通过查询数据库的视图（v$instance和v$database）就可以获得数据库的主机、实例名称等信息。

SQL> select instance_name,host_name from v$instance;	
	
INSTANCE_NAME    HOST_NAME	
---------------- ------------------------------	
ORCL             hpserver2.enmotech.com

在执行任何重要的任务之前，都应当明确确认连接的环境是正确的。这应当成为DBA的习惯。

3．避免打开过多的窗口，防止操作错误

在执行任务时，要保持尽量少的打开窗口。我经常见到工程师的桌面有众多凌乱的窗口同时打开着，混乱与错误同行，尤其是在通宵加班等情况下。

保持简洁、清晰的工作界面，是一个工程师应当具备的基本素质。

4．在执行重要任务时应保持良好的状态

良好的状态是高效率和高质量工作的保障。如果是夜间工作，应该保证有充足的睡眠，以清醒的头脑面对重要的工作；并且一定要避免在疲劳状态下连续工作，疲劳作战是对自己和数据的不负责任。

5．避免匆忙之下进行重要的工作或决定

很多误操作都是因为急着下班，急着回家，临门一脚导致的失误。所以当我们去执行一项工作时，应当保持平和的心态，避免仓促紧急地做决定。

6．测试环境和生产环境的密码不能相同

有些测试环境或非生产环境是利用生产环境恢复得到的，DBA往往在建立测试环境后，不去修改数据库用户的登录密码；通常，DBA也习惯在所有环境中设置通用的密码。这些习惯为系统带来了很多风险和不确定性。

我们建议用户在不同环境中设置不同的密码。这是因为一方面生产环境和测试环境面对的访问用户不同，密码相同则意味着生产环境的安全性完全得不到保障；另一方面，DBA登录不同的数据库如果使用相同的密码，就进一步增加了DBA在错误的环境下执行命令的可能性。

[业务高峰期误操作案例]

在维护生产环境时，尤其是负载极高的核心生产环境，我们需要注意的是，每一个操作都可能导致系统负载波动，甚至产生严重的性能问题。

下面这些案例就是一些因在业务高峰期进行贸然操作而导致的数据库问题。

案例概述	案例详情
在业务高峰期进行统计信息收集	由于客户业务系统上线后存在部分性能问题，就对一个表做了dbms_stats操作。造成一个SQL语句（涉及多个大表）执行计划改变（性能特别差）。主机基本瘫痪了2 h。最后给SQL语句加hint才解决了问题
在业务高峰期进行DDL操作	有一次，在schema A下的一个表上增加一个字段（对于schema A来说增加这个字段是不会有问题的）。但是一加上去，系统load却立即开始狂飙。原来是在schema B 下有一个包，里面引用了schema A 的这个表，之前没check倚赖关系，结果这个包编译不过去就被大量进程尝试编译。最后只有kill所有相关进程重新连接才得以恢复。这次的教训就是进行任何DDL操作都需要check这个对象可能被引用的对象，并延伸到任何频繁被访问的SQL语句
在业务高峰期进行索引维护操作	Oracle 9i的库，由于需要move tbs来降低HWM（High Water Mark，高水位线），然后再做alter index rebuild online，脚本连续执行了一个过月都没事。某一天突然发生了问题，在alert log中无报错，应用访问数据库效率却奇低，查了很多原因，未见异常，但是已经造成业务中断3h。在得到客户同意后，做了数据库全备份，重启数据库解决了该问题。事后发现其实在之前有一个trc文件生成，在该文件的代码中，发现一个类似于object id，就去查object id，果然是被重建的索引。估计是rebuild online时失败，到白天业务高峰期SMON还在清理临时段，因此造成业务堵塞
在业务高峰期进行索引维护操作		还有一次，也是做rebuild online，但是估计中途失败了，再次做rebuild online时报ORA-8106错误。按照oerr指示，进行RENAME SYS_JOURNAL_nnnnn 表，数据库一下子猛报ORA-600错误，且切出来大量的udump文件，于是重新RENAME，ORA-600错误不再报，但是估计SMON又开始忙活。8点开始业务高峰到来，再次堵塞。一直等到11点，SMON清理完毕，才恢复正常。教训：（1）做rebuild online时一定要谨慎！特别是大表的索引！（2）不要全信oerr提示
在业务高峰期进行索引维护操作		有一次，应用管理员自作主张在一张表上又建了一个索引，没过几分钟，tuxedo的队列就开始阻塞，某一应用变得特别慢。检查了一下，相应的应用几乎都在同一条语句上停留时间较长，于是DROP新加的索引，问题解决
在业务高峰期进行索引维护操作		入职第1天，说是客户那边的查询很慢，需要解决方法。于是就做了一个优化脚本dbms_stats，加 index。后来发现查询快了，但是整个业务流程却慢了，又被投诉，原来这是一个业务和查询混合使用的系统。总结：在动数据库之前一定要知道数据库的具体用途，在给数据库加东西时，一定要多了解
在业务高峰期进行DDL操作		有一次在业务繁忙时给一个最基础的表加了一个字段，导致全公司的程序停止了半个小时；另一次是准备将测试机重启，结果却将生产机重启了

续表

案例概述	案例详情
在业务高峰期进行DDL操作	有一次，开发人员给了一段脚本，就是给账户表的某个字段修改长度（alter table account_t modify...），我直接在生产库上执行了。结果大部分存储过程都失效，全省业务暂停2h
分区维护导致的索引故障	Oracle 9i的RAC，7×24业务，在删除一个分区表的分区时，没有加update global indexes，导致索引失效；甲方要求用delete，但是delete时，有个有千万记录的大表，和另外一个小表名字很像。结果删除大表时没有加条件限制，很久都没有结束，然后终止，这时一个实例crash了，不久另外一个也crash了。业务停止了两个多小时，重启后好了

DBA经常在深更半夜工作，而且有时是连续作战。为了防止因疲劳引起的误操作，在工作前要先把步骤理一遍，具体到每一个命令。如果有测试环境，要先在测试环境下执行一遍。然后就照着这个步骤做，最好是复制粘贴。操作时，要关闭其他SHELL窗口，将操作窗口的日志保存。这样操作过程都可以记录下来，如果在操作过程中发生意外，也不至于漏掉要做的步骤，总体操作是可控的。工作完成后，写报告也比较方便。

强烈建议使用ISO 9000的管理方法：记下要做的，按所写的做，写下所做的。

种种案例表明，我们应当严格遵守生产环境的维护守则，以避免产生不必要的业务影响和数据灾难。

1．高峰期禁止在数据库中执行DDL操作

DDL操作会导致一系列的SQL重解析、依赖对象失效等数据库连锁反应。一旦SQL重解析集中出现，系统必然会经历负荷峰值；如果系统繁忙，可能会就此挂起；DDL导致的依赖对象失效，甚至无法编译通过，可能长时间影响业务系统的正常运行。
所以，在生产环境中，应当严格禁止高峰期的DDL操作，避免因为操作不当或考虑不周带来数据库灾难。

2．慎重进行统计信息收集和索引创建等

统计信息收集和索引调整是优化数据库的常用手段。可是要切记，在业务峰值期间进行统计信息收集，或收集之后导致不可预期的执行计划改变，都可能使数据库瞬间停滞；而贸然添加的索引，也有可能导致其他SQL执行计划的恶化。

所以，在生产环境中，统计信息的收集或索引的增减，都应当是非常慎重的。要避免因为考虑和或测试不周全而带来额外的麻烦。

[备份级误操作案例]

我们曾经反复强调：备份重于一切。但很多人在执行备份时，也会遇到因备份而导致的误操作故障。

下面是一些与备份相关的误操作和灾难的案例。

案例概述	案例详情
无备份导致数据损毁	我以前的顶头上司因为手下的DBA没有做备份，资料全部损毁，而引咎辞职了
tar操作覆盖文件	在执行tar -cvf *.log操作时，把前面几个online redo log 打包进了最后一个online redo里面，幸好不是当前日志
tar操作覆盖文件	tar cvf 后面两个参数写反了，结果前面的数据文件丢失了
误操作tar覆盖数据	半夜加班，系统上线和数据迁移一起做，在开始前进行了冷备份，当上线和数据迁移要完成的时候，不知道怎么想的，就解压tar把当前数据文件覆盖了，幸好及时意识到并中止了解压，并且被覆盖的数据文件也没有数据。于是赶快把数据文件离线，删除，重建
导出备份覆盖数据文件	在做exp导出时，导入到了user.dbf文件里，还是在生产库中，结果生产服务器宕机了3天才恢复好
备份时文件缺失	数据库运行在非归档模式下，冷备时少了一个文件，过了几天恢复数据库，用当时的冷备文件进行恢复，结果数据库运行不了。丢失的文件还包括很多重要的应用字典数据，最后只好重新输入这些字典数据
断电导致数据丢失	有一次通知半夜停电，因为懒得去动数据库，就没有备份。结果第2天早上，磁盘阵列启动不了了。丢了周五一天的数据
误操作覆盖导出文件	有一次做数据库的重建工作，按用户要求导出所有的数据。突然，在做一个导入操作时，鼠标粘贴出了一个导出。结果一个大的dmp文件变成了0KB。还好，在另外一个目录里有一个全库的导出文件。教训：以后所有重要的导出数据，必须全部是400
误操作覆盖导出文件	在imp时错用了exp，结果把原来的dmp文件覆盖了，数据丢了。幸运的是数据不太重要
在导入数据库时发生误操作	将配置好的用户信息导入到生产库中，结果由于生产库中两个用户名太像，就导到了正在用的那个用户下，导致存储过程失效，业务中断

总结这些故障，我们有下面几点经验。

1．所执行的操作系统命令需要经过测试

很多操作系统级别的命令在执行时都具有一定的风险，如rm、mv、tar等，如果不理解这些命令的具体含义和参数的意义，就可能犯下无法挽回的错误。

所以，对于需要执行的每条命令，都要经过测试，确保其有确定的输出结果，然后才去执行它。如果对某个命令没有把握，那就永远不要去执行它。

2．执行备份并进行备份检查

很多企业觉得有了备份就高枕无忧了，可是备份和有效备份是两回事。我们一定要检查备份成功与否，备份是否有效，这样才能保证在危急关头有“备”无患。

3．使用文档手册，完善操作流程

在执行任务之前，准备文档手册，通过测试验证其可行性。并且在执行命令时按照文档操作，确保不会节外生枝。

俗话说：台上一分钟，台下十年工。只有在台下做好准备，在台上的一分钟表演才能流畅完美；而如果台下只花一分钟准备，那么台上的收尾恐怕就要“十年工”了。

所以，要多做些准备工作，磨刀不误砍柴工。

[进程级别误操作案例]

很多维护工作涉及进程级别的一些操作，强制终止进程是很多DBA都做过的事情，不过一旦出现失误，终止的进程出现问题，就会为数据库带来麻烦。

最常见的是误终止了后台进程，还有进程跟踪生成的大量进程转储信息引发空间耗尽。
下面是一些常见的案例。

案例概述	案例详情
误终止后台进程	有一次一个session占用内存很大，由于该session id比较大，所以当时以为是用户进程，于是kill掉了，结果库立刻崩溃了。查看日志后才知道这是一个后台进程。现在做任何操作都要确认无误后再敲回车键
误终止后台进程	有一次tuxedo服务出现严重堵塞。我一看是数据库的TX锁堵塞，于是查找所堵塞的session，然后找出它们的PID，在操作系统上直接kill了。结果其中有一个是数据库的核心进程（这个进程产生了TS类型的enqueue，而不是TX类型的enqueue，当时没有仔细看）。数据库立刻崩溃了，于是马上重启数据库，重启服务，但业务还是中断了10 min。以后再怎么着急，也要先确认一下将被kill的session是否是用户进程
进程跟踪空间被占用	有一次对一个操作进行跟踪，但是找不到它的SID。后来弄了个SYSTEM级别的跟踪，因为应用是tuxedo类型的长连接。结果第2天客户udump下的日志达到了20GB，数据库hang住了。
进程跟踪空间被占用	应用是tuxedo，进程很多。我想跟踪应用操作的SQL语句，于是做了alter system级别的跟踪。后来忘了关闭这个跟踪。第2天，发现磁盘满了，导致数据库hang了5 min，给客户造成了很大损失

这些案例给我们的警示如下。

1．明确区分后台进程和用户进程

数据库的后台进程是维持数据库正常工作的必要进程，如果误操作kill了重要的后台进程，那么数据库可能会立即崩溃。所以一定要注意区分后台进程和用户进程的区别。
通常数据库的核心后台进程是SMON、DBWR、LGWR、CKPT、PMON等，一旦异常终止就会导致数据库崩溃。

2．要反复确认后再执行操作

对于终止进程的命令，要反复确认后再执行。并且要注意，如果进程正在执行特定的操作，例如索引重建、TRUNCATE数据表等，意外中断可能导致严重的数据库内部错误。

所以，应当通过系统级别的跟踪命令对进程堆栈进行跟踪确认后再进行操作，并且要在强制终止进程时，做好应对异常的准备。

[数据文件误操作案例]

在数据库的文件维护中，如果处置不当，也可能带来很多灾难，本书就包含多个与文件离线相关的复杂案例。

下面是一些DBA犯下的与文件相关的错误。

案例概述	案例详情
误操作同名文件导致数据被覆盖	有一次在AIX下给客户RENAME datafile，由于文件太多，就转移到Windows下用Excel编辑。然后做了一个脚本去RENAME，结果有两个数据文件名字相同，只有大小写不一样。在Excel里为了使文件名清晰，用了一个UPPER函数，RENAME以后，mv 脚本就把其中一个覆盖了。还好有备份，最后恢复了5h
误操作同名文件导致数据被覆盖	两个磁盘都有一个相同的datafile，要求腾出一块磁盘来，我直接mv过去将一个datafile overwrite了，然后这个表空间就挂了
误操作更名文件	有一次把生产环境下的/oradata下面的datafile通过mv误更名了，幸好发现及时。又mv回来了。还有一次，进行数据的跨平台迁移。在导入用户下的数据时。因为之前写好了导出脚本，一个是新写的，一个是旧的，结果在复制时搞混了。其中一个用户数据导出重复，而少导了另一个用户。导完后，也忘记再确认一次，就把这个磁盘分配给了另一台服务器使用。并进行了格式化操作。幸好，这个用户下面没有数据。后来，从另一个相似的数据库中，导出了这个用户，并导入到新的数据库中，才没有酿成大祸
误操作裸设备导致数据被覆盖	在表空间添加datafile，用的是raw device，结果误用了一个已存在且在使用中的raw device。然后另一个datafile就被覆盖了，更不幸的是恰巧前几天的备份没成功，没法恢复

续表

案例概述	案例详情
误操作裸设备错误	由于系统用的是raw device，在添加一个数据文件时，事先没有检查LV是否存在，简单地看了当前的数据库中的数据文件所用的LV序号，就以简单序号+1 的方式添加了。结果正好没有这个LV，Oracle或UNIX操作系统当作一般的文件来创建了。由于是创建在/dev/vgxx 中，所以这时搞得UNIX的根目录没有了空间。这个数据文件刚创建完成，其他用户就无法登录了。更不幸的是已经断开了这个操作系统的连接，新的连接又无法创建。不幸中的万幸是有一位同事正好有一个连接还在上面，所以就马上过去直接su-了
误操作数据库错误	由于同时打开多个窗口，把加入A数据库的数据文件加入到了相似的B数据库中
误操作覆盖文件	做Standby时把Standby DB的数据文件复制到主库里，覆盖了主库的SYSAUX01.DBF

总结这些案例，带给我们的警示如下。

1．文件命名需要遵循规范

在Windows系统上的文件名不区分大小写，这一和UNIX系统截然相反的做法，使很多Windows用户在UNIX系统上犯了不少错误。

所以，对于数据库文件来说，一定要遵循统一的命名规范，避免发生因为不规范带来的故障。当添加文件时，需要根据规范进行添加，以维持命名的一致性和规范性。

2．对于裸设备的处理要反复确认

由于裸设备上的文件在文件系统中不可见，所以在处理裸设备文件时一定要反复确认，确保遵循正确的操作步骤，按文档、按规范进行操作。

此外，系统管理员和数据库管理员要加强沟通，明确哪些裸设备在用及其用途。曾经有一个案例，裸设备被误操作格式化后，才发现有数据文件存储于裸设备上。

3．如果有可能尽量选择ASM或文件系统

由于裸设备已经退出Oracle的支持序列，所以应当适当的将裸设备上的数据库转移到文件系统或ASM上。ASM是较好的选择，但是仍然需要专业的学习和维护才能够被良好地使用；而文件系统对于普通用户来说是方便维护的。

根据不同的用户选择合适的技术非常重要。

[误关闭生产库案例]

很多DBA还经历过误操作关闭主机或生产库的情况，这种误操作绝对是刻骨铭心的，往往一个回车键按下去，就为时已晚。

下面是一些典型的因误操作而关闭主机和服务器的案例。

640?wx_fmt=png

总结这些常见的案例，我们得出以下警示。

1．尽量避免层层跳转的服务器登录方式
虽然很多企业的数据环境通常都要经过层层跳转才能够访问，但是不可避免地，跳转的次数越多出错的可能性也就越大。所以应当尽量减少跳转次数，禁止从一个主生产节点跳转到另一个主生产节点。

在操作时，也应当通过hostname等方式确认所连接的服务器主机是否正确。

2．完成操作后尽快退出生产服务器

当在生产服务器上完成工作后，应当尽快退出，以防止因其他工作的干扰而出现误操作。尤其是当离开计算机时，应当退出或锁定操作界面，防止他人误操作。

3．经常确认服务器、数据库和路径标识

应当经常确认主机名称、当前路径、数据库名称等信息，防止无意识的误操作。尤其是当重新或临时接触操作终端时，如果不能明确看到服务器或数据库标识，则应当首先查看这些信息。

下面这些常见的命令行操作应当成为DBA的下意识的“条件反射性”操作。

[oracle@hpserver2 ~]$ hostname	
hpserver2.enmotech.com	
[oracle@hpserver2 ~]$ pwd	
/home/oracle	
[oracle@hpserver2 ~]$ ps -ef|grep smon	
ora11g    1484     1  0  2011 ?        00:02:05 ora_smon_eygle	
oracle    5200 14397  0 15:14 pts/3    00:00:00 grep smon	
[oracle@hpserver2 ~]$ id	
uid=505(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)

[系统存储级误删除案例]

除了在数据库层面上，在主机、操作系统、存储层面上也有很多典型案例。如果不够谨慎，在主机网络层面上的误操作也可能对系统产生致命的影响。

下面是一些操作系统和存储级别的误操作案例。

案例概述	案例详情
误发出系统命令	在HP UNIX Oracle 10.2上，用root账户登录后，建立了一个新主机用户，然后执行了hostname -a。但是和uname -a搞混了，hostname -a 直接把主机名改成了-a。 listener是监听主机名的，现在找不到主机了，就连续报错，后台trc文件也连续报错，很快日志占满了文件系统。好在是测试环境的数据库，不是正式的
误格式化在用存储	存储厂商过来划分存储，不小心将已经在用的盘重新划分了，导致2个应用测试库和一个培训库瘫痪。万幸的是没把在一个阵列上的生产库也删除掉
误切换生产存储	某天下午，本来是对灾备端的盘柜做HA切换，却对生产端的盘柜进行了手动HA切换，当时有20多套数据库系统在上面运行，还好赶快又切换了回来
误清空在用磁盘	在RAC环境下，DD裸设备时，本来只打算清空data diskgroup，结果不小心清空了所有的raw disk，ocr和vt当场挂掉了，还好是在测试环境下
误关闭UPS电源	一不小心把UPS电源关了，导致主机停电，幸好数据库可以正常启动起来
误关闭存储电源	有一次，当数据库的RAC配置成功后，用户不小心把存储电源拔了，结果只能重做，幸好没重要数据
误操作损坏文件系统	在Linux系统下，在文件系统没有卸载的情况下，使用了fsck命令，导致文件系统损坏，所有数据全部丢失在Linux系统下输入fsck，然后直接按了几下回车键，导致Linux系统挂掉，数据库也挂了
存储维护危险误操作	有一次在cx700的存储Navisphere管理界面配置一个存储；一位同事打开了生产环境下的一个存储的IE窗口；我接手过来后，看到这个存储的配置与我打开的一样，就开始执行STORAGE GROUP操作。还好另外一位同事看主机名不对，制止了我继续删除的动作
误操作执行系统命令	在生产环境下增加节点，一位同事在生产机上执行了pvid=yes ，导致数据丢失，最后奋战两天重新安装了RAC