金融业DBA守则与案例----上篇

《金融业DBA守则与案例》----上篇

下面我来分享一下，在最近六年里，我管理操作商业银行核心生产数据库群的经验总结。这些年我们做了很多改变，上了很多版本，经历了很多故障，在各种得失冲突矛盾中，不断总结，我们DBA团队形成了自己特有的管理DB方法论，这些方法论总结成新的DBA守则，让我们后期的DB管理过程里，基本杜绝了故障的出现，也从而让我所在的银行缺失了一些“上媒体”的机会^_^&！因为这些守则更适用于有7*24小时在线需求的重要的系统，所以我给它起名叫《金融业DBA守则》

什么是守则？百度百科可以看到这些关键字“行为规范，行为准则，不强制遵守，保障作用”这些字眼，可以总结为：保障安全生产的，有可执行性的操作准则。

之前DBA界的前辈有总结一个DBA守则：

1备份重于一切；

2  rm是危险的；

3 三思而后行；

4制定规范；

很多dba都是学着这个守则一路走来，在各行业担任重要的管理db 职责！但是，随着管理实践，很多人都已经感觉到了，这个守则没有“可执行性”，比如我知道rm是危险的，我在rm一个文件之前想了又想，一再三思而后行，觉得完全没有问题，然后我rm执行完毕了，结果公司疯了，还是删除了不该删除的文件！这类案例比比皆是！守则和故障的关系应该是如下图所示

 

        理想的守则 <------------|------------> 故障

 

理想的守则和故障应该是一条线的两极，遵循守则就没有故障，出现故障一定有违背守则的行为！故障能检验守则是否有效，守则能让我们远离故障，坚持守则还能指明解决故障的最佳方案！百炼方成钢，我们炼出的“新型钢材”如下：

一：保证生产的可持续运行。

二：有效的备份重于一切。

三：任何变更可回退。

四：选择正确的时间窗。

五：生产无小事儿。

六：不拿生产做实验。

七：制定规范。

    我们逐条来讲解并配以故障案例！

在这里，我把最重要的一条守则放在了第一位，对于一个必须7*24小时不间断的生产DB系统，比如银行的核心交易系统，核心生产的可持续运行绝对是第一位的，没有比这个更重要的事情！备份坏了，可以再备份一个更漂亮的更帅气的嘛^_^&，如果银行的DB宕机了，而且不能持续提供服务，老百姓存的钱不能取出提供生活，很容易出现群体性事件，集体去砸银行，那只能怨自己不争气，不能怨政府呀！所以对于金融类系统，“保证生产的可持续运行”绝对是第一位的守则。为了实现它，我们可以用尽各种技术手段，哪怕用时间去换，用金钱去换，用人力去换，甚至紧急情况下提供有损服务去换取。我们先看最近发生的一个案例

案例一：监控报警，生产环境所有交易报错，报错英文含义是undo空间无法扩展。

接到监控室电话，DBA迅速通过SSH登陆生产OS环境，先查看所有文件系统空间使用情况，发现数据库空间是有空余的；然后登陆数据库，查看表空间使用情况，发现undo空间使用率100%，触发了单个datafile文件32G大小上限。下面的动作是：迅速为undo表空间增加一个datafile文件，这样所有交易就可以执行了，生产就“恢复”了，引起空间爆满的根本原因和解决方法后续再分析处理。从接到报警到恢复生产持续提供服务，只用了不到5分钟！临时处理方法为找到根本解决方案提供了时间。这就是坚持“保证生产的可持续运行”原则而采用的策略。之后查询出作恶进程，查询出此进程从哪里发来的在做什么内容，然后汇报给领导请求杀掉此作恶进程，并通知操作人不要再执行类似操作（一个人在不正确的时间执行了批量数据清理任务）。然后监控undo空间，发现最大扩展到48G就不再扩展，之后undo已用空间不断降低；以空间换时间，用一点儿存储空间换取了可持续运行，问题完美解决。

在另外一个DBA朋友分享的类似案例里，他们的监控报警：由于undo异常扩展导致文件系统空间超过80%闸值报警。他们竟然为了防止空间继续扩展而导致文件系统爆满，采取紧急措施：迅速的关闭数据库，结果引发了生产停机事故，所有飞机航班延误，老板都坐不住了，跑出来不得不限定他们：必须在30分钟恢复生产，否则看着办。第三方技术专家们采用了隐含参数（有时候技术专家会是个贬义词），快速释放和收缩undo空间，然后启动DB，问题解决！

在他们DB负责人自喜于专家对隐含参数的了解而能解决生产问题的时候！ 我们可以替航空公司感到悲哀，很明显这是个失败的管理案例，“保证生产的可持续运行”是必须坚持的原则和守则，要学会开动脑筋千方百计的不停机解决生产问题才是天道，被老板吼“必须30分钟恢复生产”，无论后续采用的技术手段多么的动人和美艳，都是以失败为前提！优秀的方案一定会有简单高效的特点！

如果在银行处理此问题，会迅速通知存储工程师马上就位，在空间达到95%以上时，把预留的应急存储空间拿来扩容（每个重要的系统，尤其核心系统必须预留应急存储，以便为了“可持续运行”进行紧急扩容），同步进行的是DBA马上查询定位作恶进程和作恶相关人，干掉造成undo异常扩展的进程，防止相关操作继续出现，空间自然会逐步释放！

还有一些DBA朋友管理的生产DB把生产的undo设定成固定大小，美其名曰为了防止异常的undo扩展导致文件系统100%宕机而设定的一优质策略，甚至为了寻求合适的固定大小值而四处寻求经验！这就是典型的削足适履，鞋子买小了，为了适应鞋子，把脚丫砍小点儿塞进去！殊不知这些完全违背了保证DB“可持续运行”的基本原则，当undo异常扩展到固定大小上限的时候，db等同于停止服务。如果老板知道花了很多钱购买的存储你不让使用而导致停止生产服务，老板会不会想拿刀砍死你呢？^_^&  没有应急预留存储，可以提神请购买呀，老板不肯买，说明这个生产不重要嘛，不需要7*24小时对外服务嘛！切莫做削足适履的事儿。

这些案例里，制定一个undo异常扩展监控，会是一个非常棒的策略。

 

下面讲述一个比较长的银行故障案例，这个案例发生时我们还未总结出《金融业DBA守则》，历史的一些案例在DBA团队中常常被提起，不断的争论和反复的刺痛自己，逐渐的对一些问题达成共识，才形成了我们特有的dba守则。下面就是一例：

案例二：银行核心表分析引发的一系列故障。

银行的核心主帐目系统，会在夜间零点开始跑日结账，把所有客户的账户余额都要计算一遍，还要运算出各种维度需求的日报表，一般00：00到3：00都是一天中服务器压力最大的时候！而oracle默认的统计信息收集策略，是从晚上22：00到第二天的6：00，为了防止给日结账带来更大压力，所以我们停掉了默认的统计信息收集策略，制订了每周六上午8：00做基于schemas收集的策略。

每周收集一次统计信息，这个策略本身没有问题，可是这里有个现象，oracle10g基于schemas的统计信息全收集，每周的执行用时长度都不同，这让我们不好判断，设定一个怎样的监控，用来发现统计信息收集出现异常，需要DBA介入分析。有时候要4个小时执行完，有时候要5，6个小时执行完毕。依据我们对业务的判断，系统每周业务变化量是相同的！ oracle原厂的技术专家说10g内部算法原因，这个功能做的不好用，建议采用基于表的统计信息收集！那好吧！但是我们没有立即再次改变统计信息收集策略！我们制订了如果运行7个小时（到周六15点）还未执行完毕，发出异常警告，需要DBA介入分析原因。

所以，问题就来了

银行核心生产毕竟是个OLTP系统，常年不用的数据不应该存储于OLTP系统！那时候正好在做数据清理的梳理工作，一些大表中常年不用的数据需要清理掉，并制定保留期限，比如保留1年的数据！先要手动清理掉1年之前的所有数据，之后开始通过程序自动做每天的日清理，正好有个很重要的大表--帐目交易流水，确认了需要先清理2000多万数据，为了保证这些数据可以迅速恢复，我们把清理的数据通过CTAS方式备份一个临时表，放在当前schemas中，计划保留一个月再删除！一个周五晚上我们上了这个版本，紧接周六开始统计信息收集（我们未意识到对统计信息的影响）！

周六下午15：00，接到报警信息，核心统计信息收集未能按时完成，需要DBA介入分析原因，生产问题默认都是我和DB组长来处理！我正好离开了深圳休长假，组长家距离公司需要打车1小时车程，不能迅速抵达现场，银行生产是物理隔绝的，杜绝通过VPN远程连接访问，必须亲自抵达现场进入保密室获得安全员认证才能登陆生产，只好先让一个居住地距离公司不远的DBA兄弟到公司查看问题（哎，他因为有过生产操作故障，不再允许碰生产），这兄弟15：30抵达现场，组长电话教他怎么查问题的方法，DB的情况，如果技术水平有限，那么沟通会是很难的，沟通很久也未获知统计进程为啥不能完成，卡在了哪里！也无法肯定他查询出的统计进程是不是准确的，有没有失误，银行的核心杀错进程可能就是账目的错误和大麻烦，组长未敢做出让他结束进程的决策！拖延到17：00问题没有进展，统计信息还在执行！组长决定亲自打车到现场，就在18：00到达现场的几乎同时，核心RAC单节点宕机重启！这是我6年来管理银行核心比较大的事故之一！还好，核心重启后，统计信息收集进程也就中断了。一般在每晚18点左右，银行的卡交易会冲进来，和统计信息收集一起，导致服务器压力过大而宕机重启！

谁也没有料到统计信息收集会导致宕机事故，出现事故是让人郁闷的沮丧的，我回来后一起来追溯问题的原因和讨论，原来统计信息收集在分析那张临时备份的大表，2000万数据，持续分析了8个小时未完工，直到宕机重启！如果早抵达现场，应该可以分析出来，并杀掉这个没用的但高消耗资源的进程，从而保证生产的可持续运行。无论什么理由，终究我们未能保证生产的持续运行，违反了第一条DBA守则。

出现上述问题，加上之前对统计信息收集时间不可控的问题，我们决定第二次改进统计信息收集方案，采用基于表的统计信息收集，依据表的命名规则，只收集业务表的信息。那么即使再出现临时备份表，也不会纳入统计信息收集范围。而且经过测试，发现基于表的统计信息收集才会真的每个表信息完整收集，从而用时很稳定。不会像基于全库的或者基于schemas，通过分析数据改变量来判定是否收集统计信息，而导致额外花费很多时间！不稳定的功能会让人对功能异常出现麻痹大意心理。不谨慎和麻痹大意是造成故障的一种原因！

虽然有意识到上述的改变可能会造成SQL执行计划的改变，但没有意识到可能会产生重大影响！这里我们违反了后来我们总结的一个DBA守则：不拿生产做实验。不充分的评估和测试，就是拿生产做实验，在拿银行的核心生产试错，后面我们为此付出了代价！

我们在一个周六上线新的统计信息收集脚本。紧接着的周一日间交易，似乎业务运行很稳定，我们心也放的稳稳的了！在下班时段，监控报警，核心数据库服务器CPU达到100%，同时全国各个分行电话过来告急，柜员尾箱无法结算，所有柜员不能结帐关门！

两个DBA迅速就位解决问题，第一个TOAD连入DB是非常缓慢的，我连入成功后，迅速找到大量活动的session都在运行同一个SQL，而且用时很长，请应用开发确认，这个SQL就是尾箱关门的SQL，问题基本可以推测是这个SQL执行计划发生了改变，运行时间过长，导致的CPU消耗过高。我批量杀死这些进程，然后不断的批量杀进程，让全国的柜员不能执行这个SQL！这样服务器CPU满载就降低下来，没有了宕机中断业务的风险，另一个DBA就可以顺利TOAD工具连入，查询这个SQL的执行计划问题，对这个SQL中的几个表收集直方图，之后执行计划再次发生改变，变得高效。再之后我就可以停止杀进程操作。电话给分行，确认尾箱可以关门了，全国各个分行的柜员尾箱结账可以关门！

从发现问题到解决问题，历时1.5小时，全国所有的分行都不能结账关门，也就意味着全国所有的押运运钞车都要等在各个分行门口，加班等待尾箱结账后才能运钱，武装押运本身就是个高度紧张警惕的工作，加班押运会需要额外支付200万/每小时，这就是这个故障我们最直接付出的代价和成本！

我们对领导的解释，我们是最优秀的DBA了，出现故障可以在第一时间最快的定位并解决问题，没有人能比我们做的更好；面对连续发生的两次故障，领导要求我们坚决杜绝再次发生错误，新统计信息收集方法是否还会导致故障，明天是否会发生更严重的问题，都是未知数，都是无法保证的。以前基于SCHEMAS的统计信息收集是在生产环境执行过很久的，是久经考验的，如果我们无法保证明天的安全，那么就必须回退到基于schemas的收集方法！我们无法保证明天，但是我们坚决不同意回退版本，计划在现有版本基础上修改个别表的统计信息收集方法，比如对引起故障的SQL表，增加收集直方图。    

在会议室几乎火药味的争吵中，管理层做出了让步，同意我们再向前闯一闯，面对勉强给予的信任，我们必须做好，如果再出错，那就彻底无法合作！我们第三次更改了统计信息收集脚本，对这次事故中主帐户相关表增加收集直方图！其实，这又有是在拿生产试错，新版本纠正上次错误并继续拿生产做实验！这是在赌博，赌输了，杀红了眼，又弄来筹码决定背水一战，已经是没了退路不得不赌。

还好庆幸的是，我们赌赢了，翻了本，所以我今天可以出来吹吹牛！在这个案例中，当CPU异常消耗达到百分之百的时候，杀掉作恶进程，提供有损服务，保证生产可持续运行的方法，无疑是成功经验！但是DBA一定不要学我们，拿生产做实验，最后把自己推到不得不赌命运的境地！这绝对是反面教材！所以我们总结，任何DB的改变，在测试环境充分测试，绝不拿生产做实验！对应dba守则第六条！

 

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23652549/viewspace-2130755/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23652549/viewspace-2130755/