DBA眼中的基线与容量（下）

Posted 2021-04-29 DFC基石

DBA眼中的基线与容量（下）

下面我们来看看老白对基线的私家解释，此基线非彼基线，是老白从DBA的角度来看基线。

刚刚入门的DBA处理为你的时候往往是根据问题的表面现象，问题所表现出来的最为表层的东西去分析问题，比如从日志中发现一条信息，前台的一个告警等等。下面这张图就勾画出了一个刚刚入门的DBA的处理问题的路径。

基线是DBA对系统的看法和经验，这是老白在本文中要传递给大家的主要观点。从DBA的一个狭隘的视角去看基线，基线是为DBA运维服务的，是DBA本人对系统的看法。虽然我们能够通过工具采集并保存大量的基线数据，只有被充分理解的基线指标才对DBA的运维有较大的价值。而其他采集的基线指标，仅仅可以作为DBA分析问题时候所使用的数据而已。一个DBA在日常工作中，往往会把系统正常情况下的某些指标归纳为基线，供今后分析问题使用。某个系统的基线指标是通过运维过程中出现各种问题后的思考，不断的积累和完善的。

虽然基线的概念很简单，但是基线的管理是不简单的。理论上你可以把所有的系统指标都通过工具采集起来作为基线保存起来。但是这些数据你无法用来进行深度的分析，并形成有效的分析规则。实际上，只有少量的我们能够充分理解的基线指标对我们的运维才有价值。只有当我们能够明确某些指标出现问题后必然会产生某种后果，或者出现某种不良后果的概率是大概率，那么我们才能说这个基线对我们的运维是有极大价值的。因此如果我们要用基线来分析某个数据库的健康程度，并通过基线预警来实现故障的事先预知，那么你对某个数据库采集的基线指标数据不能太多，必须有针对性。如果你采集了上百个指标项，每天产生几十次预警，这么多的预警你是无法处理的，你唯一可以采取的措施就是忽略掉这些预警。久而久之，隐藏在里面的关键指标的预警也就会被你忽略掉，你可能会错失可以预先发现问题的机会。

如果你管理的是大量的数据库，那么你所需要采集和分析的基线数据是十分巨大的，如果仅仅通过手工手段来进行采集和分析，那么很难持久下去，因此如果要让基线管理常态化，必须借助自动化的手段来进行基线数据的采集分析和管理。

一旦你已经积累了足够量的数据，那么你就可以用来进行趋势分析，发现潜在的问题了。一旦你形成了对基线指标的”看法”，那么你就可以使用基线来进行系统预警了。一旦发现了违背基线规则的事件，你就需要进行闭环的管理，对于每个可疑的事件都进行分析，找到合理的解释。

采集数据库基线可以采用一些手工脚本，也可以使用自动化工具，比如oracle的EM。当然你也可以使用dbms_workload_repository.create_baseline直接把一个AWR数据保存为基线数据。被标志位基线的SNAP将不会在清理数据的时候被清除掉，而会长久保留。
如果你对AWR的基表比较了解，那么你也可以直接编写脚本从AWR的基表中去读取数据。当年白鳝的洞穴中的网友人生如梦就分析过AWR报告生成的所有脚本，并且写了一个文档，大家有兴趣可以去下载，这个文档最初是发在Oracle粉丝网上的。

在一些工具中，包含了大量的基线指标，其中包括Oracle的AWR，以及操作系统层面的NMON，OSW，GLANCE等。作为DBA我们最关心的肯定是ORACLE数据库的基线数据，既然AWR里面包含了最多的基线指标数据，那么我们应该把AWR数据长期保留下来。如果保留在生产库里，会导致AWR数据占用过多的空间。因此我们需要把AWR数据从生产库中离线下载下来，然后放到一个专门存储AWR历史数据的数据库中，长期保留下来。

方法很简单，首先我们可以去找一台服务器，一台2路的PC SERVER就足够用了，甚至你可以使用一台台式机来创建一个数据库。然后使用awrextr.sql脚本从生产库将需要转储的AWR数据导出到一个DMP文件中(这个脚本存放于?/rdbms/admin目录)。然后在目标数据库，使用awrload.sql将数据导入。一个数据库中可以管理多个数据库/实例的AWR数据，使用awrrpti脚本我们就可以选择某个数据库生成某个实例的awr报告，当然其他的awr报告生成脚本也有类似的带i的脚本。同时我们也可以通过自己定义的脚本去分析这些awr数据。

在这里我要再一次提一下当年人生如梦所写的一篇文章，分析awr报告的生成原理。人生如梦也是白鳝的洞穴的第一批成员之一，也是我相交甚厚的小兄弟。当年他要做这个分析的时候，我还冷嘲热讽，最后在长老和棉花糖的帮助下，历经数月，人生终于完成了对AWR报告生成脚本的全面分析。编写了“AWR报告内容生成SQL”这篇名字十分清淡但是内容十分详实的文章。在之后的SCN HEADROOM分析这件事里，老白还使用了一些人生如梦这篇文档里的脚本。

从这篇文章的前言可以看出，人生如梦网友在编写这份文档的时候仍然对老白对他的冷言冷语依然怀恨在心。不过作为一个DBA，确实也需要这种精神。和人生如梦交往的那么多年里，第一次看他这么认真的做一件枯燥的事情，这件事做成对他在技术和职场上的成长都十分有价值，我想每个DBA都会经历这样的阶段，做成一件这样的事情，今后对你来说就没有什么困难的事情了。

基线采集之后就是使用了，基线的使用场景十分广泛，用于故障分析可以通过基线来缩小故障分析的范围，快速定位问题。而基线数据采集的数量到达一定量以后，基线就可以用于趋势分析了。趋势分析可以以周/月/年的周期来进行，这些分析可以让DBA和IT决策者了解信息系统的运行势态，资源的使用趋势等。对于一些持续恶化的指标，可以进行重点的针对性分析。

基线的另外一个用处就是预警，当基线数据采集到一定数量的时候，我们可以总结出基线变化的规则，并在监控系统中针对某些指标设置预警规则。对于违背基线规则，监控系统将主动推送报警信息。而对于违反规则的基线预警，IT部门需要组织相关技术人员进行分析，查找可能存在的疑点。对每个违反基线规则的事件，都必须找到合理的解释，做到闭环管理。

对于基线预警事件的分析基于某些监控规则，最为简单的监控规则就是阈值，而阈值的设置需要根据每个系统的实际特点去设定。不过阈值只是一种十分简单的以单一指标为监控对象的预警方法，而实际的生产系统相当复杂，某个指标出现变化的因素十分复杂，完全不能简单的用阈值来评判。

曾经有一些DBA试图通过复杂的规则引擎来设置更为复杂的基线预警规则，经过大量实践后发现，这些基于规则引擎的分析往往很难实现完全的人工智能，从本质上说，只是一些更为复杂的阈值而已，其准确度也十分难以保证。因此到目前为止，基线预警的最好方法还是阈值预警，人工分析的组合。超出规则定义范围外的基线指标都会触动报警，这样可以让每个疑点都会被运维人员第一时间捕获。

虽然阈值预警可以使用最为简单的方法，但是数据分析过程并不简单。指标数据的分析不能仅仅依靠某个指标的值来进行，很多指标之间是相关联的。比如共享池的问题，需要分析共享池使用率、平均每秒SQL解析的总量、硬解析比例、每秒SQL执行的数量、和共享池相关的闩锁的丢失率、SGA是否发生过RESIZE、library cache和字典缓冲的整体指标，以及执行和解析比较高的SQL的情况，才能有一个较为准确的判断。整个判断是十分复杂的，只能抽取出少量的可验证的规则，无法覆盖故障的较大范围。

我举个例子，我遇到过一个用户，他们的系统负载很高，每天一上班CPU使用率就超过90%，告警系统天天告警，搞得他们都无法工作，后来我们分析了一下他们的系统，其实有时候CPU使用率超过90%，系统并没有出现什么瓶颈，操作系统的R队列数量只是略微超过了CPU线程数。于是我就建议他们取消CPU使用率阈值报警，转而采用R队列阈值报警。当R队列超出CPU线程数2倍的时候开始报警，超出3倍严重报警。通过这样调整阈值报警，使阈值报警的有效性大大的提升了。

最后我们要来强调几点对基线预警的应用经验。虽然我们可以使用自动化工具来使基线的采集/分析/预警自动化，但是无目的的分析效果不佳。如果我们管理十多套系统，甚至几十套系统，每个系统每天都有1-2个违背基线的事件发生，那么我们所说的防患于未然或者闭环管理是否能够得到很好的落实呢？对于一般的DBA来说，每天处理2-3个基线预警事件还是可以接受的，如果我们每天面临数十个基线预警事件，那么我想对于绝大多数DBA来说，只能是虱子多了不愁，干脆不管了事。

因此说，基线的采集和预警不能贪多，只需要把能够充分认识的基线纳入预警范围就行了，不要追求量。正确的做法是开始时候仅仅设置能够分析道德基线指标的跟踪，随着对系统认识的加深，逐渐加入你发现的心指标。应该循序渐进，不要过分追多追全。

经过上面的讨论，我们已经初步弄清楚了日常运维的系统的基线问题，那么新的问题又来了，对于没有历史积累的系统，我们该怎么办？

对于一套我们以前没有接触过的系统，如果需要我们去分析哪些指标是正常的，哪些指标是不正常的，那么我们就需要考虑很多的问题。比如我们了解一个类似的系统是IBM P750 32核的，这套系统的大体处理能力是我们掌握的，但是我目前面对的是一台4路的PC SERVER，也是32核的，它的处理能力相当于P750的几分之几？这就涉及到不同CPU之间的容量模型问题，如果我们已经了解不同CPU之间的容量差异，那么我们很容易对这个案例进行类推，通过类推虽然不能很准确的掌握一些指标，但是大体可以推算出一个初略的指标。

DBA也经常会遇到这样的问题，一个新上线的存储，领导问你这个存储大体上能提供多大的处理能力，这件事虽说很复杂，但是也不是没有办法，我们可以通过fio，vdbench，或者orion等测试工具对划好的Lun进行测试，从而得到一个大体的指标。但是如果这件事放在设备采购之前，IT部门需要了解我们配什么样的存储才能满足业务系统的需求，那我们该怎么办呢？如果我们去看存储设备厂商标称的性能指标，那么我们就可能吃大苦头了。存储厂商的标称容量都基本上是实验室的极限容量，需要配备满配的存储机头及磁盘扩展柜，这种配置往往和我们采购的配置是完全不同的。在这种情况下，需要我们根据每块盘的IOPS能力以及盘的数量，CACHE命中率等去初步推算采购存储的IO处理能力，同时考虑到机头、前端接口的带宽和处理能力，考虑配置机头和前端通道的数量。

如果我们的存储系统升级后，业务反而慢了，我们该如何去分析呢？这里分享一个案例，有个客户，存储换了新的存储，标称的性能远远高于原来的老存储，盘的数量也配备的比原来多，按理说存储割接后系统性能会有较大的提升。没想到存储更换后，所有核心业务模块都慢了30-50%。到底是什么引起的呢？老白分析了下，发现SQL的执行计划和buffer gets都没啥变化，但是IO等待时间变长了。为什么会这样呢？通过仔细比对发现，老存储使用的是600G的3.5寸的15000rpm sas盘，而新存储使用的是900G的2.5寸10000rpm sas盘。虽然存储厂商宣称2.5寸的10000rpm的SAS盘的IO延时与3.5寸的15000 rpm的SAS盘性能相当，但是实际上这两种盘的IO延时是有差异的，10000rpm的盘IO延时要多30%左右。如果你了解这些盘之间的性能差异，你就很容易找到问题的根本原因，否则你可能要陷入四处推诿的不利局面中。

上面列的是一些对于DBA来说很有用的系统级容量基线，比如一块15000rpm的SAS盘的IOPS指标我们可以估算为150-200（悲观值，乐观值可以按300 IOPS估算）;而这样一块SAS盘的IO延时大约为3毫秒左右，考虑到CACHE和IO路径延时，我们认为一块物理磁盘的IO延时大约在2-5毫秒之间，当然15000rpm的盘的IO延时要比10000rpm的IO延时低一些。

我们在估算存储的IOPS指标的时候，需要考虑CACHE的命中率，而这个命中率指标对于OLTP系统来说，大约是60-70%之间，我们可以根据乐观值和悲观值来选择一个合适的值。

另外在RAC INTERCONNECT方面，在千兆网络环境下，流量最高可以达到80M/秒，在万兆环境下，可以达到800M/秒，当然达到这个指标的情况下，RAC已经出现了较为严重的GCS/GES等待。一般情况下，千兆网络下，如果没有做网卡绑定或者多心跳线设置，RAC INTERCONNECT网络流量超过60M/秒就是较为危险的了。

下面我们来看一组数据库容量的基线。对于OLTP系统来说，一般来说DB CACHE的命中率会在95%以上，而目前随着内存容量越来越大，一般的OLTP系统的DB CACHE命中率都在98%以上，甚至高达99%以上，对于低于99%的CACHE命中率的系统，你就可以看看是否存在加大DB CACHE，进一步提高CACHE命中率的优化可能。

    而对于一般的OLTP系统而言，db file sequential read等待事件占总的等待的比例应该超过50%，甚至更高。而事实上，我们看到的绝大多数系统的CPU TIME都占了较大的比重，这是因为我们的系统中存在大量长时间执行的SQL。而单块读的平均响应时间应该在4毫秒左右，对于负载不是特别高，存储系统性能很好的系统，这个指标可能在2毫秒左右，甚至更低。对于一般系统而言，如果该指标小于10毫秒就可以认为基本正常，超过20毫秒会对系统产生较大影响。

Log file sync指标对于系统的写入操作性能十分关键，正常情况下，该指标在4毫秒左右。对于一些高端存储，由于写缓冲很大，所以这个指标可能相当小，可以达到1毫秒，甚至小于1毫秒。这个指标如果变得很差的话，可能会导致整个数据库的性能下降。
Ave global cache get time(ms)指标能够直接反映出RAC节点之间数据交换的性能。这个指标一般也是1-4毫秒，业务高峰期的平均指标如果超出20毫秒，那么说明RAC INTERCONNECT的性能存在较为严重的问题。

除了了解系统级的指标外，我们还需要了解SQL的容量基线。某类常见SQL在不同并发情况下，可能消耗的CPU资源等都是我们需要去研究的。比如图中是某个用户的一个典型的统计操作的SQL，在不同并发用户下的CPU资源开销。通过这个SQL可以推算某个模块可能的CPU资源消耗。除了这种典型的业务SQL外，我们还需要充分掌握某些典型特征的SQL的容量基线。比如通过主键访问某张表的，通过范围扫描访问的、插入数据的，修改数据的，等等等等。

下面的案例是一条SQL在不同的并发量情况下消耗的CPU资源的情况，在一定范围内并发量和CPU消耗指标之间是一个接近于直线的二次曲线。我们可以通过拟合工具找到这条曲线的相关参数，用这些参数来预估我们无法在压测环境下模拟的并发量下的CPU消耗指标。

针对业务模块也是一样的掌握业务模块的容量基线也有助于我们今后进行容量的估算，作为企业级用户，也需要建立自己的企业典型模块的容量字典。

当然，针对服务器的容量字典也是企业级客户需要去采集的。我们必须知道企业正在使用或者将要使用的硬件的容量字典，从而能够在规划或者采购设备时有比较准确的参考。下面这个不同服务器之间的能力指标是几年前的，但是其参考意义到现在还是很大的。

上面这张图上显示了不同类型的服务器的容量模型，从这里我们可以看出某8路服务器和某中端小型机之间的性能对比情况。通过这些数据我们可以建立起不同服务器CPU容量模型的数据，今后对于我们进行服务器容量估算是十分有帮助的。

看着老白罗列的各种数据，似乎系统级的容量基线采集也不是什么难事。不过不同类型的应用系统，在容量级基线上可能有较大的表现差异，而对于SQL容量模型，一些复杂SQL的容量基线是较难采集的和相互推算的。比如sql的单次执行消耗的CPU是否超过一个CPU周期，可能在采集的结果数据上会有较大的差异。

所以说，较为准确的系统级基线是需要日积月累，甚至需要经过实验室的严格的科学分析才能获得的。这些数据都是企业最为宝贵的财富之一。

基于我们积累的系统级容量基线以及业务容量基线，我们可以建立企业级的容量模型。容量管理的原理很简单，就是根据业务容量推算服务容量，根据服务容量推算资源容量。基于完善的字典，我们甚至可以直接从业务需求跳过服务需求，直接推算资源容量。

业务容量就是我们业务部门十分清楚的业务量，比如我们要新增用户多少，每天有多少用户变更资料，每年的业务量增长多少等等。通过这些业务容量指标，我们需要推算出服务容量，也就是说通过业务容量推算出要调用我们系统中的服务的数量，比如登录系统最高的并发量，查单最大的并发量等等。再通过服务容量来推算出我们最终所需要的硬件资源的容量，比如说CPU，内存，IO，存储，网络，等等。

对于一个企业来说，可以从系统的非功能性需求推算每个业务模块的并发访问需求，从而通过业务模块访问的SQL去推算各种资源的消耗。这是一种最为朴素的容量评估方法，从原理上可行，不过从实际操作上看，难度较大，并且需要消耗大量的资源去进行分析。因此对于企业级的容量管理来说，建立各种容量字典至关重要。

对于一个大型企业来说，如果需要进行容量管理，必须建立起企业级的硬件容量字典、功能点容量字典和业务模块的容量字典，通过这三个字典可以精确的推算出企业信息系统建设的投资规模。这个内容已经超出了DBA关心的容量的范围，在这里只是简单带过，不做细致的分析了。

综上所述，容量与基线是DBA进行精益化运维所依仗的重要工具，因此掌握一些系统基线与容量的知识有助于DBA提升自己的管理能力，也有助于把数据库运维从无序化逐步提升到标准化，再提升到精益化和自动化、智能化的阶段。

今天和大家分享了一个DBA管理中的中高级的问题，就是基线管理与容量管理的一些基本的概念。基线与容量是普适性的概念，对于DBA/系统管理员/软件开发人员，他们对这两个概念的理解会有所不同。老白从一个DBA的狭隘的角度认为只有充分理解的基线指标才对日常工作有至关重要的帮助。因此作为日常运维的DBA来说，把更多的精力放在这些能理解的基线指标的总结和发现上，会更加有价值。当然平时你能保留更多的细节数据当然是更好的事情，但是不要追求多，而要追求有价值。这也是一个老DBA在这些年工作中的一点感受。

扫码关注哦！