确定大量SP的表和影响

Question

当系统不受 CPU 限制并且 95% 的响应看到响应时间减少时，我试图找出导致某些响应时间增加的原因，当数据通过页面压缩进行压缩时。

因此，我所做的是将其追踪到系统中发生的单个进程，并对该进程进行概要分析以确定在此过程中触发了哪些 SP 和 UFN。我最初的想法是我可以单独运行每个 SP 和 UFN 并查看查询计划以查看发生完整扫描的位置，这可能需要从压缩中解压缩数据并可能导致等待触发。

所以我现在拥有的是：

• 使用参数的 SP 列表
• 运行 SP 的数据库
• 不受限制的管理员访问系统以重现问题
• 相关进程的配置文件跟踪

由于我必须对 35 个 SP/UFN 之类的东西进行分类，因此我想知道缩小原因的最有效方法是什么。根据我对系统的经验，我可以推断出某些 SP 比其他 SP 更有可能是罪魁祸首，但我想尝试以更科学的方式缩小范围。是否有任何工具或方法可以帮助我找出最有可能的罪犯？

如果我可以确定压缩时比不压缩时慢的对象，这将有助于我们了解页面压缩的策略。

Answer 1

科学方法基于定期收集过程和程序性能信息，无论是使用商业包还是更多的本土解决方案。您也可以从头开始从 Profiler 或扩展事件中收集信息。重要的是定期捕获数据，并使其易于使用（例如使用SSRS）。

可用的历史信息可以轻松跟踪性能随时间的逐渐变化、在资源需求增加之前预测它们、诊断突然变化以及识别和测试需要改进的领域。

关于后一点，我相信你的方法应该是这样的：

1. 在合理的时间段内建立良好的基线信息
2. 确定可能受益于压缩的区域
3. 在改进目标区域测试ROW和PAGE压缩
4. 在代表性工作负载上测试聚合更改
5. 优化或回归无益的更改
6. 实施变更并监控生产中的影响

这比事后试图在复杂代码中追踪性能回归要容易得多，而没有可比较的基线。

Answer 2

如果您确定这 35 个可编程项是经过时间和缓存计划的配置文件/事件的组合以及sys.dm_exec_query_stats 的罪魁祸首应该可以帮助您了解问题所在。

不过，@Paul 关于记录基线的评论很重要。