紧急修复

贝壳周四的时候收到消息，烟台的系统崩溃，于是在24小时之内走了一趟天堂和地狱间的旅行。
开始的时候，贝壳在查一些业务有关的资料。期间和一个同事开了几句玩笑，但是发现他一脸便秘的样子，和我说没空。贝壳很郁闷，怎么这么没面子？过了几分钟，事情就发展成贝壳也一脸便秘的没胆子了，原因是烟台的系统崩溃。由于远程无法连接，只能让客户去机房重起整个系统。可重起后也没有反应。于是贝壳怕了，马上通知了老板。老板马上做了决定，要我们当时飞去烟台，并且在几分钟内给我们搞定了机票。于是在贝壳头处理紧急问题的时候，就受到了"飞机-出租- 零反应"的待遇。
中间首先要感谢一下给我们做Oracle技术支持的纪锋老师，这次如果不是他的大力协助，恐怕问题不会这么快解决。我们在零时间往烟台赶的时候，纪老师也马上打车往机场走。我们是五点接到的问题通告，五点半就联络好了各种问题，乘公司的车子往机场走(主要怕下班高峰不好打车)。六点多点的时候，我们拿到了登机牌，去做安检，然后顺便讨论起问题原因。当时认为基本不可能是软件问题，因为软件问题重起后基本都可以解决，也不会弄的机器停机(这个最终被检验是正确的)。可能是维护问题或者硬件问题。按照机器安装时间来计算，硬件问题的可能居多(系统才刚刚交付几个月)。
飞机是8点50在烟台落的地，落地后我们心急火燎地坐出租往报社赶。车刚出机场，收到一个消息，问题消失了。我们顿时安心很多，要是问题继续出现导致更严重问题，怕我们全都吃不了兜着走。现在，虽然我们还要去找出根本原因，可总比被客户拷问着检查系统来的好的多。到了报业后，我们先检查了系统。第一个被发现的问题是备份机已经满了，怎么会这样？系统的设计容量是三年500G，按照现在的数据量估计，最高不会超过30G，可备份机上足足有100G的空间！我们倒推了数据，发现备份要用140G以上的空间。怎么会这样呢？
原因我们没有找到，不过按照纪老师给出的原因，是备份的时候大量的归档日志造成了数据量暴增。但是备份暴增怎么会造成系统不能访问呢？贝壳陷入了奇怪的感觉中。虽然直觉上觉得就是这个理由，但是实际上却无法确定。按照我和同事说的话，如果用这个理由来说服我，是无法说服的。但是如果在目前让我给出一个理由，恐怕只有这个了。当天比较晚了，因此没有进一步分析，只是让纪老师调整了备份策略就去睡觉了。
第二天，贝壳仔细检查了所有的系统日志，找到了真正引发错误的理由。Linux9号错误，原因是因为文件无法访问。可是，究竟为什么造成9号错误呢？又是为什么导致重起后错误不消失，过后错误又莫名消失呢？进一步分析日志找到了这后两个问题的理由，客户重起节点1未完成时，直接重起了节点2。RAC似乎在所有节点同时失效后无法自动重连，即使重起也不行，必须重起客户端。最后按照数据倒推，认定问题在本地磁盘耗尽上。只是开始为了检测数据库备份，执行了 crosscheck，释放了部分磁盘空间，因此查不出来。
从这次事故恢复来说，最大的问题在于客户那里没有人及时进行系统维护，最终导致了磁盘耗尽。因此说做一个系统简单，然而要长期维护系统，恐怕就没这么简单了。