一年多以后,我想让大家知道我的经验以及这个问题/主题的最终结果。
我开始自己创造东西。最初,我按照Tim Ford的文章使用CMV收集和存储历史SQL Server性能计数器数据进行整理,并使用我想要收集的任何数据对其进行了扩展。因此,我每天一次在每个Sql Server上运行几个存储过程,这些过程从DMV收集一些特定信息,并将结果存储在数据库内部的本地Server上。这包括索引使用情况,缺少索引,特定日志条目(例如自动增长),服务器设置,应用程序数据库设置,碎片,作业执行,事务日志信息,文件信息,等待统计信息等等。
另外,我将Brent Ozar的sp_blitz常规执行结果添加到此存储库中,以收集其他有价值的指示,以进行工作,改进和报告。
之后,所有数据都从那里收集到专用的监视Sql Server中,这样我就创建了一个捆绑存储,以存储有关所有服务器的性能相关信息,并将其用作调查和报告的基础。
然后,我创建了excel工作表,还使用报表服务进行了报表分析和解释。一些样本:
同样,我根据Fedor Georgiev 的文章“将性能数据收集到SQL Server表中 ”的启发,使用TYPEPERF配置了一些性能计数器监视。
在我的SQL Monitoring实例中,我触发typeperf来运行并以可配置的sampleinterval收集可配置数量的样本,并将结果存储在中央监控数据库中。
这使我可以观察长期性能值,例如:
经过一段时间使用它收集基线信息后,结果发现,必须花费大量维护工作来查找失败的作业,调试程序(例如,在数据库脱机的情况下,脚本失败),在更换服务器后维护设置...
同样,收集所有记录的数据库也需要维护和性能调整,因此需要做更多的工作来保持数据的有用性...
最终完全缺少的是能够实时观察发生的事情。在最佳情况下,我将能够说出数据收集器运行后第二天可能发生的情况。而且所有细节都丢失了。我无权访问死锁图,无法查看在可疑时间范围内运行的查询的查询计划。
所有这些使我不得不向管理部门收费,以花钱购买我自己无法创建的专业解决方案。
最终的选择是购买SentryOne,因为与其他产品相比,SentryOne具有说服力,并且提供了确定我们的痛点所需的大量信息。
最后的结论是,只要您没有一个小而基本健康的环境,我便建议任何寻求类似问题答案的人不要尝试自己创造东西。如果您有几个系统并且有很多问题,那么最好立即寻求专业的解决方案,并使用供应商对您问题的坚持,而不是花费大量时间和金钱来创建不太有用的东西。但是,这条路线仍然非常有趣,使我学到了很多我不想错过的东西。
希望您一旦遇到这个问题线程,对您来说都是有用的。
编辑2017年4月20日:
布伦特·奥扎尔(Brent Ozar)最近在Facebook上发布了以下文章,这是SQL Tiger团队采取的一种类似方法:https : //blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-baselining 报告释放的企业监控/