sqlserver性能调优(性能基线).docVIP

 HYPERLINK /topics/390311827 \t /topics/_blank 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管理多个数据库实例，这些对系统使用，安装异常，预算等的趋势信息，在与领导沟通汇报时，会更有用。?一旦知道