记得在我初中高中的时候，中午还能回家吃饭，每天12：38左右的《今日说法》就是我们必看的节目，看完节目，一点刚过点，稍微睡一会就开始下午的课了。所以法制节目伴随了我的很多时光。看到了各色案件也看到了人生百态，有些当时看不明白，现在再来看是完全不同的感受。
法制节目确实很有意义，一线的干警非常能吃苦。在分析问题方面，我有时候都会有一种错觉，感觉DBA处理很多问题，排查的思路和警方破解一个谜题，侦破案件很相似，很多时候思路都是相通的，都是在有限的信息和资源的情况下，抽丝剥茧，逐步还原事情的真相。
我看在各大网站论坛中，曾经的一批法制迷们发起了一个话题，那就是选出自己印象最深刻的一个案件，有些同学很有心，都整理了出来，我看到很多人都在说一个盲区监控50米的案例，是在2014年8月的一个节目，那个时候我在干吗呢，我查了下，当时还在用脚本分析足彩。
我们来简单说下这个案件背景：
2012年年底的一天，一个年轻的女子李红在福建厦门街头，一条前后都有摄像探头的马路上突然神秘的消失了；消失之后，李红的银行账户却被人用手机查询过。报警人是李红的弟弟，因为他姐姐的两个手机都关机了。民警花费了大量的时间和精力做了地毯式的走访和调查，但是这个盲区内压根找不到任何李红的信息，警方甚至找来了环卫工人，对附近的下水井盖都做了摸排，还是没有任何证据发现。
所以这个案件就可以反向推理一下，这样一个监控盲区，李红从商场换表离开后，就近的商业区，路口都没有出现，很可能是被绑架到车里离开了。而一旦是绑架，在一个商业区很可能会听到喊叫或者挣扎的声音，但是经过仔细的排查，没有任何的报警信息，没有任何的异常信息。
但是案件的方向是基本明确的，李红很可能是被绑架，通过其他的车辆离开了现场，那么车辆就会分为出租车和私家车，出租车在下午两点的时间段里，总共有20辆左右，很快排查完毕。而私家车就相当难以排查了，因为那个时间点附近，路口有近1000多辆车经过，这个排查难度就相当大了。
警方尝试从几个电话入手，虽然发现了一些嫌疑人，但是经过确认和本案无关，由此一来，整个案件进入了一种山穷水尽的地步。
在这一点上，民警耐心，缜密的思维让人佩服，他们的分析很在理，根据这个商业区的路况情况，只有一个方向走向，而且50米的盲区没有公交车站，所以可以排查李红乘坐公交车离开的可能性，再者这里是双向12车道，中间有高架桥，有护栏，在盲区50米内没有可供掉头的路口，所以是一个单行车道。
到了这里，如果你是负责这个案子的警察，你该怎么分析，你知道这个时间段里的1000辆车里很可能就有一个是嫌疑车辆，但是这个分析难度极大，有什么好的办法能够甄别出嫌疑车辆。
这个不是靠外观，而是靠时间。警察的这个分析思路虽然听起来比较土，但是绝对有说服力。
他们和交管部门做过确认，这个时间段里没有任何交通事故，所以道理是通畅的，而假设车辆的速度为60km/h,那么经过这个路口（两个探头的距离）需要花费的时间大概是30秒左右，如果这个时间段里有车辆停下来，肯定会额外花费更多的时间，所以警方就逐个开始落实这方面的信息，很快就锁定了一个车辆。发现这个车辆比其它的车辆多出来了近20秒。
有了这些信息，能够定位到更具体的信息，处理问题就会顺利很多，后面的案件处理虽然也是多了些周折，但是也是惊心动魄。
我们在处理数据库的问题的时候，如果碰到类似的问题，其实思路也是相通的。
我来举一个真实的例子，一个数据库宕机的问题分析，在一套X86平台的数据库服务器，配置了64G内存，SGA配置了40G，平时的负载也比较平稳，但是有一天凌晨突然发生了宕机事故，整个问题影响范围也很大，涉及到一些活动的拉收情况，但是发现的时候还是有些晚了。整个问题后期的处理和分析中，我们都有很大的压力，而且我个人也很内疚。
但是问题后期的分析已经过去了很多天，数据库的快照保留期限已经超过期限，也就意味着被系统删除了，我们无法得到那个时候数据库层面具体的信息。而系统日志层面，我们能够看到的就是一个oom的报错，然后就没有然后了。
对此我做了一些分析，排查了当时的一些日志，当时的数据库连接信息在OOM崩溃前会在系统日志中打印出来，我可以清晰的看到有1000多个数据库连接，作为DBA，我对这套环境的连接情况还是比较熟悉的，以前的连接数大概是200个左右，但是近期的连接数暴增，翻了近5倍。这是不是造成整个宕机的原因呢，要说是还是很牵强，因为很多应用中1000个连接其实还是很正常的。那么问题出在哪里，如果是连接数的问题，为什么再早几天就没问题。
这种问题我相信我自己也会问自己，怎么能够解释得通呢。首先来说说宕库的原因，Oracle的5大必备进程，SMON,PMON,DBWR,LGWR,CKPT,如果任何一个出了问题，一定会自动停掉实例。所以初步的方向很明确，是PMON被kill了，而造成的原因是MMON进程。
再进一步，我分析了这段时间内这个数据库启动的日志，终于发现在上一次启动的时候HugePage没有能够正常开启，但是通过 /proc/mem|grep Huge查看大页的分配，却能够看到大页应开启了。
所以问题的初步结论就很明显了，由于Hugepage没有生效导致系统性能变差，大量的短小连接频繁调用导致产生了阻塞，内存使用率变高，SWAP争用更加严重，最后PMON进程被清理掉，导致数据库实例宕机，这样下来，一个配置问题最终变为了性能问题，最终变为了监控问题，逐步上升变为了业务问题。
虽然排查的过程信息非常有限，但是能够得到一个较为清晰，切可信的症结真是难上加难。运维无小事，事事小心用心，细节决定成败。
这一点上，还是深深的佩服这些一线的民警英雄。
