从物自身谈起

DBA做到深处，就没办法不去思考哲学问题了。我们经常会遇到一些灵魂的拷问，为什么我的系统会出问题？为什么负载差不多，昨天不出问题，今天就出问题了？为什么同样一条SQL，今天会出那么多死锁？这个现象与那个配置有关系吗？

实际上我本没有研究过任何哲学，“物自身”的概念还是几年前阅读《海伯利安》的时候在诗人的故事《海伯利安诗篇》里看到的。世界分为“显像”与“物自身”，我们平时看到的只是显像，即事物对我们的显现，而不是物自身。当然物自身这个康德提出来的哲学问题太深奥了，不在我今天的讨论范围之中。今天我们就这个话题引出这些年做数据库运维中遇到的一些问题，以及解决问题的一些方法。几年前，我看到“显像“与“物自身”这两个词的时候，有一种醍醐灌顶的感觉。回顾我这些年做过的运维与优化的案例，不乏用一些看似逻辑十分周密的长篇大论向用户解释各种不太合理的现象，也通过分析找到了一些当时认为是十分精妙的解决方法。DBA都会把追求问题的根因作为自己的追求，也会为自己编写过的故障分析报告感到自豪。不过对于那些问题我们真的找到根因了吗？还是像康德所说的，我们可以无限接近物自身，但是无法完全得到它。
实际上有时候我们解决了一个棘手的问题，我们认为已经发现了问题的真相，找到了根因。而本质上，很可能我们只是找到了一个和问题根因有关的关联点，通过调整使系统进入了一个新的平衡，从而让以前比较严重的问题变得不严重了，或者从表面上看不到了。想到这里，我惊出了一身冷汗，于是在后来的几年中，我不断的对以前认为十分经典的案例进行了仔细的推敲，特别是被我收录到三本书里的案例。按照“物自身与显像原则”的分析，我发现哪怕是我在书里描述的认为十分具有代表性的案例，大多数也都只是解决了部分的显像问题，而并没有真正勘透“物自身”。
比如说十多年前的那个券商的RAC经常有一个节点宕机的问题。当时经过分析，我发现是因为操作系统参数配置不合理，导致大量的内存被用于文件缓冲，导致偶发性的OS产生SWAP，当SWAP比较严重的时候，会导致CRS心跳超时，引起节点被踢掉。根据这一情况，我当时调整了VM参数swappiness和vfs_cache_pressure等，这个问题就解决了。
实际上SWAP也并不是根因，而只是一个现象。我通过调整参数，缓解了这个现象，从而解决了一个十分棘手的问题。实际上当时我还看到了一个现象，这个现象也写在我的报告里了，那就是每次宕机都是节点1，而节点2从来没宕过。节点1上跑了一个DSG，刚开始的时候运维服务商还想甩锅给DSG，最终被我否定了。今天再看到这份分析报告，我为我当时所犯的错误感到有些羞愧。实际上，节点1的FILE CACHE使用量巨大，导致OS换页的根源正是DSG大量的读写文件。在后来五六年中，我遇到过多起类似的故障，最终的根因都是和DSG/OGG之类的数据库复制软件有关的。只是上海这个案例是我第一次遇到，而且当时被认为是“完美的”解决了，所以让我疏忽了更深的原因。
那么上面的问题的根因就是DSG吗？真的是DSG搞出了问题吗？事实上也不是的，当操作系统升级到了RHEL 7以后，此类问题再也不容易出现了，因为RHEL 7对FILE CACHE以及VM的算法做了大量的优化，使之对Oracle CRS的支持更好了。同样，当CRS升级到11.2.0.4以后，哪怕OS还在使用RHEL 6，宕机问题也不会再出现了。
把这个案例重新拿出来分析，并不是为了说如何做更好的根因溯源。因为对于运维来说，根因溯源有助于更深入的解决问题，不过溯源的深度要把控好，根因也并不是一定要获得的。甚至有时候是不可得的。就像康德的物自身哲学问题，我们只能看到显像世界，无法达到物自身。另外一方面我们能够达到的与物自身的距离，也是和我们的技术能力和所投入的成本有关的。对于DBA来说，我们对相关的原理理解得越深，越准确，那么我们离根因也会越近。
2004年我给海尔做优化的时候，刚刚开始的时候我总是认为东软开发的HCSP系统存在很多问题，索引缺失，SQL写的很烂。每次开会都会拿东软的开发人员开涮。原本准备几天干完的优化项目变成了持久战，我每隔一段时间就飞到青岛，帮用户集中解决一些SQL的问题。刚开始的时候客户觉得优化工作十分有效，不过随着这项工作变成常态化工作，客户、开发商和我都觉得十分疲劳。业务不断在变化，几乎每个月都有一两次系统变更，SQL语句有很多是平台自动生成的，光靠不断的调整索引，使用outlines固化执行计划，让开发商改代码并无法让这套系统完全稳定下来。
于是有了那个当时在《ORACLE DBA优化日记》里的修改DB CACHE的HASH CHAIN BUCKETS参数的调整。这是因为经过一段时间分析，我发现无论哪条SQL出问题，都会产生大量的BUFFER BUSY WAITS，并且引发严重的CBC争用，使原本就比较紧张的CPU资源耗尽。通过调整DB CACHE的BUCKETS数量后，CBC争用改善了很多，不太容易引发严重的系统性能问题了。于是紧急救火的事情少了不少，SQL优化的需求也减少了不少，大家也都摆脱了每天提心吊胆过日子的阴霾。
现在回顾那次优化，实际上我们离对“物自身”的理解还有一定的距离，实际上，当年海尔HCSP系统的问题最主要的还是因为服务器资源严重不足的问题。虽然我们通过看似十分经典的优化很好的维持了当时系统的运行，让一台2路的HP N4000小型机支撑了全球8000多个维修服务站能够凑合完成每日的工作。不过如果我当时和客户提出扩容服务器就一定可以彻底解决这个问题，恐怕这个优化项目就没必要干的那么辛苦了。其实客户也问过我，如果马上申请资金扩容HP服务器，是不是能够解决这个问题。我当时的回答是，应用开发得不好，再好的硬件也解决不了问题。
事实上我当时的判断是错的，后来这个项目正好遇到一笔技改资金，直接用来把CPU扩大到了四路，内存也扩了2倍，之后系统就十分稳定了。而那时候HCSP系统服务的维修站已经超过12000家了，服务站的使用体验也比2005年我们优化项目结束时要好得多。
2007年的时候，HCSP系统又一次出现了CBC的问题，我再次来到青岛帮用户分析。最后发现居然是当年我调整的那个BUCKET参数引发的问题，正是因为这个参数存在，加大DB CACHE后，CBC的争用变得更严重了。删除这个参数后，系统就恢复正常了。
我们每次对“显像”的分析都可能是到位的，我们的处置也是立竿见影的，但是我们可能并没有真正的看到“物自身”，追逐“物自身”并不是必须的，有时候也可能无法真正看到它。不过不影响我们利用自身不断提升的能力来更接近它。这是我最终想表达的想法。