DBA生存警示：业务高峰误操作案例及建议

编辑手记：对于资深的老DBA们，他们在漫长的职业生涯中养成了很多稀奇古怪的守则，以在复杂多变的环境中“幸存”，这源于无数血泪的教训，我曾经在《数据安全警示录》一书收录了大量现实案例，现在整理分享给大家，共为警示。

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

案例分享



业务期间DDL操作

2004年某一天下午五点左右，在schema A下一个表上增加一个字段（对于在schema A范围来说这个字段增加当时不会有问题的），一加上去，系统load立即狂飙......结果在schema B下有一个包，里面有饮用schema a的这个表，没check依赖关系以为A和B之间没有联系，结果这个包编译不过去被大量进程尝试编译，最后只有杀掉该相关应用所有进程重新连接才恢复。

这次故障导致我们一个无故障最长时间的团队免费去海南旅游三天的机会丧失。

业务期间DDL操作

刚工作一年的时候，开发了一段脚本就是给账户表某个字段修改长度（alter table account_t modify...），我当时太累了，发了的脚本也没有说明何时操作，我就直接在生产库上执行了。可想而知，大部分存储过程都失效，全省业务暂停2小时，嘿嘿。。。领导之后就给了我“破坏王”的称号。

业务期间DDL维护

没有犯过错的DBA不是好DBA，但经常犯错的DBA也不是好DBA。

我大的错误没有犯过，只有两个算是小一点的错误。一次是在业务繁忙的时候给一个最基础的表加一个字段，导致全公司程序停止半个小时；另一次是准备将测试机重启，结果将生产机给重启了。

业务期间统计信息收集

客户业务系统上线后由于存在部分性能问题，我对一个表做了dbms_stats......造成了一个SQL（涉及多个大表）执行计划改变（性能特差），主机基本瘫痪了两个小时。最后给SQL加hint才解决问题。

业务期间索引维护操作

我遇到的严重事故：其实也不是人为造成的。Oracle 9i的库，由于需要move tbs来降低hwm，然后再做alter index rebuild online，脚本连续跑了一个多月都没事情。某天突然发生问题，alert log中无报错，应用访问数据库效率奇低，查了n多原因，未见异常，但是已经造成业务中断3小时。得到客户同意后，做完数据库全备，中午12点重启数据库解决该问题。

事后发现其实在凌晨两点的时候有一个trc文件生成，看里面一堆的天书代码，发现一个好像是object id，object果然是被重建索引，估计是rebuild online的时候失败，到白天业务高峰期间smon还在清理临时段，因此业务堵塞。

防范建议

1.在高峰期禁止在数据库中进行DDL操作

DDL操作会导致一系列的SQL重解析、依赖对象失效等数据库连锁反应：一旦SQL重解析集中出现，系统必然经历负荷峰值，如果系统繁忙，可能就此挂起；DDL导致的依赖对象消失，甚至无法通过编译，可能长时间影响业务系统正常运行。

所以，在生产环境中，应当严格禁止高峰期的DDL操作，避免因操作不当或考虑不周带来的手忙脚乱或数据库灾难。

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

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

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