5个需要采集数据库基线数据的理由

基线是度量变化的一个参考。基线常常用于医药领域。医生在为病人开药时，会测量病人的血压和心率，采集体重或者进行血液检查。在过了一段时间以后，医生会重



新采集同样的数据来观察什么指标发生了变化，以便充分评估药物的影响。


在IT领域，也存在同样的方式。DBA们也能够使用基线来衡量计划或者未计划的变化的影响。在最好的情况下，这些数据可以用来快速识别那些计划外的导致性能问题的行为。同时，采集基线最起码可以让DBA了解当前配置中存在的问题和制定未来的计划。

使用基线是个好方法，似乎每个DBA都明白它的价值。但不幸的是，还有很多公司并没有关于数据库的基线数据。这可能会有两方面的原因，一个启动成本，需要大量的时间和精力。如果打算推出自己采集基线的方法，必须对以下问题进行一个思考，并好好回答。

1，你要采集什么样的数据？(what)

2，你要在何时采集数据？(when)

3，你会使用什么方法来采集数据？（what method ，也就是how）

4，你将会把数据存放在哪里？（where）

5，你从采集的数据里面怎样得到数据库情况报告？（how）

6，你要怎样长期管理这些采集的数据？（how long）

这些问题需要一些思考并采取相关的对策。不过，似乎很多人常常都是喜欢生活在没有数据的世界里，而不是努力去获取数据。（很多决策都是基于历史数据而进行的）。

第二个因素是我们自己的被动性。如果对一个DBA问到，“你会采集基线吗？”，通常的答案是一声叹气，“不会”。造成这样的原因是很多的，有些DBA会说，手头有很多工作没做完；有些DBA会说，整天忙于救火和应对突发事件。归根到底，都是说没有时间或者精力来实施新的东西，例如部署采集数据库基线的方法。当然，也会有的DBA回答说，没想过主动实施采集基线的策略，因为觉得部署采集基线的活动需要花很多时间和精力，有时候还会吃力不讨好。

1，为什么呢？
最大原因应该是采集基线数据是件比较棘手的事情。DBA可能会意识到基线数据的价值，但是，很多公司并不会去买第三方工具来采集基线数据，因此，很多人都需要手工来采集基线数据。当打打算这样做的时候，我们也会遇到各种问题：从哪里开始？自己是否有足够的时间来进行？采集基线对我有多大帮助？在没有基线数据时，我已经能够解决问题了，真的还需要基线数据吗？

呵呵，这就是关键点了：我们真的需要基线数据吗？我不能很好的回答这个问题，但从每一个有基线数据的数据库实例来看，基线数据已经证明了其价值。也许，我们会遇到，在我们拥有基线数据时，遇到了一个问题了，但基线数据对该问题没有参考价值。但，我们也应该换一个角度来考虑，我们是否遇到过没有可参考数据的情况下来解决问题？如果有参考数据时，我们是否能更快速的解决问题呢？如果有参考数据时，我们是否可以为团队，为公司创造更大的价值？

事实上，基线数据可以让DBA的日子过得越来越舒服。因为：

1，你可以发现在某个东西成为一个问题之前发生了什么改变？
2，更容易排除故障
3，可以更容易的主动进行性能调优
4，可以让你了解当前环境和数据的变化趋势
5，可以提供更好的容量规划
。。。
2，该采集什么呢？
千里之行始于足下，要做一件事情时，可以从最简单的入手。因为可以采集的数据是很多的，如果不加以规划和甄别，很容易被海量的数据给淹没，不仅没有带来价值，反而增加了负担。因此，需要把重点放在哪些数据是最重要的，哪些数据可以帮助我们定位性能问题？同时，也要关注数据库在哪个时间段比较容易出问题？一般情况下，可以从以下几方面入手：

1，基本信息

2，系统使用信息

3，文件和数据库大小信息

4，Wait 统计信息

我们从SQL Server的基本信息开始，因为这些信息很容易被DBA改变，特别是在有多个DBA的可以访问SQL Server环境的情况下。经常会遇到某个人修改了某个值（如max memory allocated 或max degree of parallelism），而DBA却不知道这样的改变！而随着虚拟化大潮的来临，在虚拟化环境下，DBA们更容易遇到如从一个虚拟机迁移到另外一台主机时的一些莫名奇妙的问题，而这些通常都是配置问题导致的。

 

如果你知道一些基本性能监控计数器（如CPU，内存，磁盘延迟）、数据库连接和活动等的基线信息，在发生性能问题时，可以优先检查这些数据，看能否发现一些问题。特别是如果使用了脚本，就可以快速的获取当前的性能数据，并和正常的性能数据比较。最后，如果DBA管理多个数据库实例，这些对系统使用，安装异常，预算等的趋势信息，在与领导沟通汇报时，会更有用。

 

一旦知道了基本的设置和系统的使用情况，就可以采集文件和数据库的增长的基线数据了。一个DBA的主要和最重要的工作之一是，保持系统的可用性。因此，避免数据库运行的空间不足，采集基线数据是最快捷的方式，也是很重要的方式。最好的做法是通过采集当前的文件和磁盘的大小，计算出数据增长的趋势：通过这样做，会使计划磁盘空间或数据迁移时变得更加容易。如果系统数据库中的表的大小异常增长了，DBA可以深入了解这个相关的业务，了解应用程序是如何使用的，从而排除是否存在问题。

 

最后，除了了解CPU，I /O和内存的正常值外，还有一个很重要的，是看一个数据库服务器里的等待统计信息。每个SQL Server实例都有等待统计信息，而这些信息可以用于性能调优，通过它，可以了解基本的正常的等待统计信息，在需要的时候，也可以用来进行比较。

3，何时采集
 

一旦已经决定想要什么样的数据，必须决定采集的频率。数据太多，会占用额外的空间，太少，你不能很好的了解数据库到底发生了什么。采集的频率取决于数据本身，例如性能计数器可以每隔15秒。但捕捉事务日志文件的大小时，就没必要以15s作为采集间隔了。

 

另外，你需要确定是否需要查看最繁忙的时间段或正常营业时间或任何时间的数据。你还必须确定，会保持多久的数据。是否有必要将数据保存6个月，或一年？也许三个月的数据就足够了。只有你自己知道自己数据库的情况并进行管理。同样，也可以从简单的开始，这是比较直接的，例如仅在工作时间和捕获数据，只保留最后3个月的指标进行比较，到时候再根据实际情况，建立其他采集模式或扩大。

4，存放何处
根据经验，最好是创建一个单独的数据库来存储所有的生产库实例的基本信息。最好需要一个共享服务器来存放基线数据库，这样所有生产服务器上的数据可以被复制然后存储在基线数据库。同时应该定期备份该数据库，和采集，迁移，存储的脚本。并把查看基线数据信息当成的日常工作必不可少的一部分。

5，下一步
 

本文一系列的四个有关采集基线数据的文章。接下来的三篇文章，将逐步获得上述的数据采集的过程，并提供脚本。你的第一个任务是找到一个书库实例，在这里你可以建立一个基线数据库。你的第二个任务是致力于采集这些数据。开始行动吧，骚年？