SQL 性能问题 - 首先正确配置服务器还是一一解决问题？

Question

这适用于 SQL Server 2012。

我正在对 Dynamics AX 环境中的整体性能缓慢进行故障排除。一切都很慢 - 应用程序本身、报告、临时等。马上，我可以看到没有配置 SQL Server 的最佳实践 - MAXDOP、tempdb、特定于 Dynamics 的跟踪标志和索引/碎片化维护。我很确定存在低效查询、缺失或非最佳索引等。

我花了一点时间查看等待统计数据，但现在我想知道我是否应该首先应用所有推荐的最佳实践（DynamicsAX 的行业标准最佳实践），然后解决缓慢的问题，或者深入研究每个问题一个，并在它到来时解决它？我知道有些人会说，在您确定需要翻转开关之前，不要开始翻转开关。

你会如何处理这种情况？

Answer 1

关于这一点，有几件事要说，Dynamics AX 性能不一定总是由 SQL Server 缓慢引起的，尤其是当您说“一切都很慢”时。

在 Dynamics AX 中遇到性能问题时，我倾向于使用以下方法：

• 首先从查看所有涉及的服务器上的资源开始（cpu 压力、内存压力、页面预期寿命……）
  • 每个 AOS、Client 和 Citrix 至少需要 4 个内核
  • AX 对 CPU 延迟非常敏感，请确保您的 CPU 在 BIOS 中设置为高性能。如果你说一切都很慢，即使是简单的形式，我的直觉也表明情况并非如此。
  • 不仅在 SQL Server 上，而且在所有涉及的组件上执行标准检查，例如磁盘延迟等。
• 然后根据最佳实践验证所有 SQL Server 设置是否正确
  • 正确的跟踪标志
  • 正确的索引/统计维护
  • 最大DOP
  • 最大内存设置
  • ...
• 查看所有相关的数据库属性（如果它们是根据最佳实践设置的）
  • 自动更新统计
• 通过检查缺失的索引和缓慢的查询来检查数据库设计
  • 使用已知的 DMV 查询（我倾向于喜欢Glenn Berry 脚本）
  • 使用DynamicsPerf记录 dmv 数据如果您联系支持人员，这将是他们让您安装的第一个工具
  • 将慢查询记录到SQL 语句跟踪日志中，以便您可以将它们与代码中的调用堆栈相关联
• 查看应用程序设置中的已知问题（编号规则、数据库日志等）
  • 查看Premier Field Engineers发现的前 10 个问题

一旦您的设置可以正常工作并且某些进程仍然很慢，请使用Trace Parser对在此过程中运行的每段代码和查询进行精确计时。这应该可以帮助您解决或至少解释为什么剩余的过程很慢。