了解数据库状态的关键：基线与容量

DBA在运维工作中遇到最难的问题是如何判断数据库是否存在某个问题，特别是在国产数据库大行其道的今天，这方面的知识都需要重新构建。DBA能力的提升也正是判断能力提升所加持的，今天我们就来聊聊这方面的问题。

对于各个阶段的DBA分析问题的主要方法，我简单总结一下，大概有四个阶段，每前进到一个新的阶段都说明DBA在能力上的断崖式提升。最初的时候，他们是根据现象来分析问题的。某个现象遇到过，那么就容易解决，如果没遇到过，可能就抓瞎了。

在这个阶段遇到问题，首先根据现象去脑子里分析，是否曾经遇到过类似案例，如果没有，那么只能去网上搜索，再解决不了，就只能去向高手咨询了。这是一个DBA技能的初级阶段，还没有形成比较有价值的知识库，因此解决问题往往要凭运气。这是DBA靠天吃饭的阶段。

随着DBA的能力的提升，分析问题不再是凭运气了。因为中级的DBA 已经对数据库的一些基本性的原理有所了解，因此不再仅仅依靠表象来分析问题，可以通过对内在原理的思考 定位问题了。这个阶段中，指标是十分关键的东西。某些指标异常说明了什么，哪怕自己还不是很清楚，也知道通过一些渠道去找到比较靠谱的答案了。

在这个阶段中，唯一麻烦的就是，如何判断某个指标的正常与否，在这方面的积累还不够，因此判断问题的准确性还不够。有时候分析问题如水银泻地，有时候又像遇到一个堰塞湖一样前进不得。

高级DBA对于上面的问题有比较标准的解决方案，那就是通过基线来分析问题。

什么是基线呢？说起基线，可能有很多朋友在脑子里立马会浮现出一张指标的折线图，上下各有一条线，这是狭义的“基线”，不过并不是我今天想和大家分享的“基线”。我个人认为“从数据库 运维的角度就系统而言，基线-BASELINE是某个运行状态在某个时间上的快照 ”， 某个指标、某个运维经验、某个现象都可以成为运维基线； 对于DBA，有价值的基线来自于长期运维的经验，并非仅仅对于某个指标的学习和理解。基线十分重要，因为基线是用于判别某个指标甚至某个现象是否正常的重要依据。

基线的积累十分困难，需要DBA经过长期的工作与思考才能逐渐丰富起来。哪些指标对于分析哪些问题有帮助，哪些基线的合理范围在哪个区间，哪些基线出现异常后可以使用的分析溯源方案有哪些，随着这些运维知识的不断积累，DBA的能力就会大幅提升。能够很好地利用基线去分析问题，是一个高级DBA的主要特征。

不过有些时候，基线也不见得能发挥作用了。比如有人问你某个系统，在2万IOPS下，IO延时是5毫秒，存储系统的状态是好是坏？某台服务器，HTTPS请求达到10万/秒，CPU使用率是20%，合理不合理？某个Oracle 数据库的library cache pin 等待时间是50毫秒，系统 共享池是否存在问题？当前的系统，数据表空间会不会在3个月内用满？

要回答这些问题，仅仅依靠基线就不够了，这需要容量方面的知识。 利用容量进行分析， 不仅仅考虑基线的问题，还需要 考虑系统的总体负载能力， 考虑数据库标准操作产生的资源消耗情况， 考虑不同硬件之间的容量差异， 考虑信息系统长期发展的可持续问题。 如果你 已经积累了足以应对日常运维工作中的容量知识，那么恭喜你，在这个领域内，你已经是专家级别的存在了。

比如说有这样一个案例，如上图的AWR数据。有一个系统， 8月2日CPU从早上7点30开始到下午5点30都基本上处于100%， 平时这个系统的CPU使用率不超过40%， 8月3日起未见异常。 如果DBA能够清晰地描述出上述问题，说明他已经初步掌握了基线分析的方法。我们如果再进一步利用基线的知识做分析，是可以完成问题定位的。

不过实际上，分析工作没那么简单，因为导致出现上述现象的可能性很多。我们需要利用自己所掌握的知识去做排除。上述问题，仅仅能够依靠现象进行分析的朋友可能就无从入手了。

而对于掌握了根据指标去分析问题的朋友首先会看到Library cache pin/lock等待事件延时很高。很容易就认为共享池问题可能是问题的关键。

而更高一层次的DBA懂得了以基线分析作为分析问题的方法。他会发现共享池问题虽然存在，但是占比不高，逻辑读过高可能对CPU使用率过高产生的影响更大。他通过比对正常与非正常时段的逻辑读指标，就可以找到更加准确的分析路径。

懂得 容量分析的专家则更加直接，从180W+逻辑读和每个事务1W+逻辑读这这些指标上，马上发现了其中的不正常，可以比仅仅懂得基线分析的高级DBA更快地找到问题的关键点。