Question

怎样查出SQLServer的性能瓶颈

Answer 1

自定义性能监控

在这一点上，我假定你已经阅读了，或者至少浏览了所有监控步骤的建议。我猜你也许读了一些，但那些真正不适合于你。既然大部分的SQLServer安装稍微有点不同，那么这是有意义的。因此我建议你为你特定的环境自定义这个监控，添加或删除一些步骤使其更适合你的需求。

使用Word或Excel维护你的监控列表

当你对你的每一个SQLServer进行监控时，你需要一个方法去记录结果。当你有大量的选项时，从这一系列的文章里复制适合的监控列表到你的Word或Excel文档作为起点是比较快速的方法。你可能要为每个服务器创建一个单独的监控列表。如果你决定为你的监控表格使用Excel的话，你能输入所有的监控列表项目作为行，每一个监控的服务器作为单独的列。这样你能快速的查看每个SQLServer的结果。

设置SQLServer和数据库的优先级

如果你管理大量的SQLServer和数据库，你也许不知道从哪儿开始性能监控。理论上，你应该设置SQLServer和数据库的优先级，一些需要立即进行最多的性能监控，而其他的则不必进行那么多的监控。这会帮助你决定从哪儿开始。最可能的是，你将不会立即监控全部。相反，要在能监控的时候监控，按照从最重要到最不重要的顺序进行。

谨记性能监控的关键

当对SQLServer进行监控的时候

，记住目的是分辨并纠正容易的问题。但是，正如你所料，你将可能也分辨出一些更难于解决的问题。为了帮助你更好的管理有限的时间，你现在需要着眼于那些容易的问题，把困难的问题留到容易的问题先解决完之后。所以在你执行监控和分辨问题时，按照难易程度分类设置它们的优先级，将困难的问题留待你有足够时间处理它们的时候。

不要过早行动

当你执行监控时，你可能会急于对偶然遇到的问题进行纠正和修改。大多数情况下，那样做可能不是问题。但理论上，最好先执行监控，然后基于你的发现，决定正式动手解决你分辨出的问题，然后系统地实现它们。

一个推荐步骤，但或许会招来很多疑问

理想情况下，如有很多的时间，在服务器上执行一个性能基准是一个好的想法，然后执行监控，做任何需要的更改，再执行另一个性能基准去看看有什么情况发生。这会立即让你知道你所做的是否有帮助，大多数情况下，没有做正确的事。虽然这个建议被强烈的推荐，也许从时间来看不很实际。但如果你有时间的话，应该认真考虑。

另一个推荐步骤，但或许也会招来很多疑问

在执行监控之后，你也许发现在单个的SQLServer上所有需要的更改仅只有一两个，但在其他SQLServer上，也许需要做一打的更改。如果有那么的更改要做，不要立刻全部实现它们，仅仅一次一个或几个的更改也许是一个明智的选择。这样，你能够看看每个或每批更改对服务器产生的效果。如果你一次做了很多的更改，那么遇到问题时，你将不会知道是由哪个更改引起的问题，这要求你回滚所有的更改，然后一个一个的测试它们直到找到问题所在为止。

这个建议不会有太多疑问

如果你要做更改的服务器是有紧要事务的生产服务器，你要对你做的更改倍加小心。理论上，你应该在生产服务器应用更改之前在测试用的SQLServer上测试所有的更改。如果你不实践，那么每次仅做一个更改，确信如果有任何问题你知道怎样回滚更改。另外，试着选取一天中不很忙的时候做更改，万一有问题的话。

有一个取消计划

你因监控而做出的大多数更改应该能够很容易的回滚。但一些也许不那么容易。在那些情况下，你需要有一个万一需要的取消计划。例如，在你做出任何关键的更改之前备份系统和用户数据库。那样，即使出现问题，你也能将你的服务器恢复到更改之前的状态。我不是吓唬你不要做更改，但你总应该有所准备。

记录所有更改

当你基于性能监控做出更改时，确定你对所有的更改做了记录。这样，即使后来有什么问题，你也能更容易的找出错误所在。最容易记录下你的更改的方法可能就是把它们添加到你的监控表格里，或者其他你用来收集监控信息的文档里。

每年都要执行SQLServer的性能监控

许多SQLServer（并非全部）随着时间而改变。设置改变，打了SP补丁，甚至数据也改变了。所有的这些都会影响性能。确定你SQLServer最优性能的最好方法是做一个手工的性能监控。