我身边的一些数据库事故 (r5笔记第52天)

最近携程的数据事故闹得沸沸扬扬，不管是什么原因，问题终究发生了。在问题发生的时候，更关键的是解决方法和防范措施，一般在升级或者重大的生产演练中，我们都有一个lesson learn,就是总结问题，总结经验，防范规范。 除此之外，一线人员在各种重大活动中都发挥了重要的作用，我还是喜欢那句华为任正非的那句话：让听得见炮声的人指挥。其余我只能报以呵呵的态度了。 自己也抽空整理了一下自己经历的数据相关的重大问题和事故，一总结还真吓一跳。确认也有不少案例。很多都记录在自己的技术博客中了，想了解详细的内容可以参考一下。 对于这些问题，有些是自己犯过的，有些是同事犯过的，但是都产生了一定的影响，说出来没什么丢人的，能够坦诚布公的总结出来，就是希望自己身边的经历能够让这些看似简单的问题不要再犯。 案例1：一条sql语句把数据库弄宕 链接 http://blog.itpub.net/23718752/viewspace-1141131/ 这个案例听起来好像还真玄妙，是真实的案例。 就是在生产库中执行了alter system set sga_target=xxxG; 这样一个语句导致数据库直接宕机。当然问题的发生还是有一些前提条件的。最终发现和一个Oracle bug有关。 Bug 10173135 - Resize SGA_TARGET crashes instance with ORA-600 [kmgsb_resize_sga_target_1] (Doc ID 10173135.8) 看似简单的一个操作就能导致严重的问题。生产中的操作真是慎之又慎，很多特性的使用也是需要斟酌和考究的。不要抱有侥幸心理，没准就让你碰上了。所以在生产中执行的语句，几乎都会在其它环境中反复测试才会部署。 案例2：kernel配置把数据库弄hang http://blog.itpub.net/23718752/viewspace-1417471/ 这个 这个问题其实也是客户带着侥幸心理，结果没想到真出了问题，倒不是把数据库弄宕。但是系统反应极为缓慢，swap的交换非常频繁，最后发现是由于调整了sga等参数，但是hugepage的调整给漏掉了。 在启动数据库的时候其实也报出了hugepage的问题，但是没有引起重视。 ****************** Huge Pages Information ***************** Huge Pages memory pool detected (total: 30000 free: 27287) Huge Pages allocation failed (free: 29431 required: 32457) Allocation will continue with default/smaller page size ********************************************************** 所以问题放大之后，就产生了严重的影响。linux内核参数在很多时候会起到决定性的作用，所以影响不容小视。 案例3：使用图形工具操作失误 图形工具在生产系统中会极大的提高工作效率，但是有时候会产生一些误导，比如测试环境中的一些配置信息和生产中是完全不同的。但是通过图形界面可能很简单的点一下按钮就会产生极为严重的数据事故，这个问题发生在很多补丁的部署在测试环境中都没有问题，但是在生产环境中有一个配置略有不同，结果没有引起重视，一个按钮点下去，在后台做了很多的验证和连接操作，然后就开始了一些意料之外的大动作，比如re-create,比如drop操作。这个问题最后发现是由于配置的问题导致的，最后采用了基于时间点的恢复，很快得以解决。但是虽然之后知道配置问题解决了，但是使用起来还是会有很多顾虑，最后一致决定，采用控制脚本来完成，在生产环境中完全弃用了这个工具。 所以生产中的操作是重之又重。不确定不明白的地方一定要确认好。存在的隐患一定要提前规避。 案例4:数据库升级中的exp错误，险些导致回退 http://blog.itpub.net/23718752/viewspace-773852/ 这个问题印象实在是太深了，和原厂的人折腾了很久，问题在类似生产环境中反复演练了很多次，都没有发现，但是在生产中还是碰到了。问题看似是一个小问题，在使用exp 使用consistent=y的时候出现问题，结果导致系统中某一个服务处理不了。

exp APP_ROLLBK/APP_ROLLBK file=test.dmp tables=AAAAA  consistent=y
Export: Release 11.2.0.2.0 - Production on Tue Oct 8 08:30:08 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in UTF-8 character set and UTF8 NCHAR character set
About to export specified tables via Conventional Path ...
. . exporting table                  AAAAA 76 rows exported
EXP-00008: ORACLE error 1466 encountered
ORA-01466: unable to read data - table definition has changed
Export terminated successfully with warnings.

虽然最后得以解决，但是解决方案确实是有些牵强，就是purge recyclebin，即清空回收站。 mealink中的各种帖子都被翻遍了。各种bug和补丁都斟酌了，当时在场的那种压力可想而知，在紧绷神经近10多个小时之后，终于解决。也算是化险为夷了。 案例4:pl/sql性能问题导致升级差点失败 http://blog.itpub.net/23718752/viewspace-1172818/ 这个问题发生的也是意料之外，但是影响也很大，其实就是在升级前，从开发那边传过来一个补丁，在测试环境中测试通过，但是在类生产系统中没有测试，结果在部署的时候，pl/sql执行了好几个小时，给业务升级带来很大的影响，差点导致回退。 其实把pl/sql改为sql语句不到一分钟就能够搞定，但是因为这个临时的问题导致大家都有些手忙脚乱。 ..... 其实案例还有很多很多，就此就不一一赘述了。从上面的案例来看很多问题都是意料之外，都是一些细节因素导致的，产生的影响也很大，都需要引起注意。 最后来和大家说一个 我听过最离谱的数据事故，话说某个运营商的机房运转正常，但是突然有一天突然机房断电，最后应该是用UPS给顶上了，很多细节略去几百字，最后排查问题原因，发现是由于某个扫地大妈在拖地的时候不小心把某个插头给碰掉了。你说碰到这种问题，真是哭笑不得的感觉。