我们如何分析应用程序在 SQL Server 中所做的一切？

Question

我还不是 DBA，但这似乎是 DBA 类型的问题，而不是编程问题。

有人问我：

• 哪些查询调用最频繁？
• 在正常项目中它们被调用多少次？
• 他们需要多长时间来执行
• 我们是否能够从 SQL 中提取执行计划来显示它当前的运行情况？
• 我们的 SQL 中是否存在任何潜在错误（不可接受的脏读等）？
• 哪些表最常被写入？
• 最常读取哪些表？
• 对于一个普通项目，这些表通常包含多少行？

由于需要在实时环境中运行，这变得很复杂。我们的愿望似乎是自动化一些维护过程，以修复我们发现的任何问题，并为开发提供输入以阻止他们做坏事。

我的第一个想法是——招聘一名 DBA，可能是一名顾问。

然后，所要求的规模之大令我震惊。一个项目可能会持续数月，其中一台 SQL Server 和多台应用程序服务器共享任务。此输出的数据量将是巨大的，监视每个正在执行的查询的性能开销也将是巨大的。

有没有推荐的此类分析工具？

Answer 1

虽然这最初看起来像是多个问题，但您确实可以将其归结为“是否有用于此类分析的推荐工具？”。答案是“是”。提示片尾音乐、片尾字幕。

如果您想了解更多详细信息，答案是“视情况而定”。您的预算是多少，无论是购买工具（如果有必要）还是投入员工时间来学习、配置、维护和监控该软件（绝对必要）？您的所有示例是否都同样重要？单个工具能够回答所有示例或至少在单个输出中整理并呈现答案对于业务目标是否重要？这些信息的使用者是一个由开发人员组成的团队，他们将单独解决“他们的”问题，还是领导识别和分配痛点，还是经理优先分配资源，还是向利益相关者展示如何进行的PowerPoint演示？

有许多工具涵盖多个范围，例如价格、完善、灵活性、社区支持等等。我不知道为什么你认为数据量会很大——大多数用于完成你所描述的事情的工具都是 90% 从标准日志中过滤和聚合，加上 10% 的配置和元数据。大量输出通常是人们提前设置装置以回答任何人可能提出的每个可以想到的问题的结果，这在推介阶段听起来可能不错，但只是创建了一堆不同格式的、无法区分的难以解读的数据。同样，“监视每个查询的性能开销”不应该成为您描述的任务的问题，因为这也可以通过读取日志输出来获得。您的服务器已经在密切关注打开的线程和正在运行的进程，任何工具都将利用它。

从你的问题的背景来看，我推断你的公司没有专门的数据团队。如果是这样，狭窄的焦点是你的朋友。找到要回答的最重要的问题，例如“经常运行的面向客户的查询的最大瓶颈是什么？”。搜索一个工具、一个内置的 SQL 监控流程、或者一个公开可用的脚本（例如 Brent Ozar 的 sp_BlitzCache）来回答该特定问题，并围绕该问题建立一个流程：警报电子邮件、SSRS 报告或任何适合环境的内容将信息提供给可以据此做出决策的人员。对于非数据库专家的单个开发人员来说，这是一个可以实现的短期目标。然后回答下一个最重要的问题，并将该输出添加到您的流程中。一旦该流程的业务方面已经成熟，并且有多个人习惯于接收信息并根据信息采取行动，那么可能就是考虑使用第三方工具的时候了。

大多数第三方监控工具在某种程度上都是这一过程的高级版本，其中许多都很棒。但听起来您的环境目前没有资源或专业知识来充分利用这些工具，这意味着设置它们可能是一个漫长且令人沮丧的过程，最终会出现许多非常漂亮的屏幕，但这些屏幕大多仍难以辨认，并且很大程度上被忽视了。简而言之，监控工具很像人们在五金店找到的电动工具：功能强大、方便，每个有经验的用户都有自己最喜欢的工具，他们会花几个小时解释其原因。但它们并不能取代专业知识，如果用户不知道如何使用手动工具完成同样的事情，那么电动版本就是一条快速而昂贵的自残之路。