我们的应用程序支持人员表示，其中一个应用程序出现故障可能是由于在一天中的特定时间（特别是每晚 08:30 pm 到 09:30 pm 之间）数据库中的一些异常活动/负载。没有提供切实的证据，但是他们有兴趣查看问题时间期间数据库中发生的任何事情的统计数据/图表，看看他们是否可以从中获得任何线索。或者至少，要确保数据库方面没有问题。
之前我曾告诉他们，跟踪会话可以帮助我们了解问题期间数据库中发生的情况。（也许我不应该这么说？）现在他们缠着我向他们提供跟踪数据，但他们不知道应该跟踪哪些事件。他们给了我一个模糊的要求，“请您提供好坏时期的统计数据，以便我们进行比较？”
问题是我也注意到应该包括哪些事件。
为了帮助他们解决这个问题，我也一直在考虑使用 MDW（管理数据仓库）。目前未启用。
这里有m个问题：
- 如果我最终决定启用 SQL Server 跟踪（除了当前活动的默认跟踪），我应该为会话定位哪些事件？
- MDW不是更好的选择吗？跟踪提供了什么（就性能洞察力而言）MDW 没有？
- MDW 是许可功能吗？（我个人不这么认为，但需要确定）
关于环境：
这是一个SQL Server 2008 R2数据库，等待明年上半年升级。这是一个生产数据库。
SolarWinds 用于监控我们的数据库。据我了解，它已经收集了大量数据（例如用户连接、活动会话、活动事务、延迟写入/秒等）。这些数据每 5 分钟收集一次。
我们团队中有 Oracle DBA，但没有其他 SQL Server DBA。这意味着不幸的是，周围没有其他人能够帮助我。
我也是这个环境的新手，对 SQL Server 不是很精通，至少在性能调优方面是这样，因为我一生中大部分时间都在做 Oracle。
这是一个非常广泛的问题，因为您没有具体细节。Tracing 和 MDW 不一定会在这里给你答案，这完全取决于什么
实际上的意思。首先，让应用支持团队提供该声明之外的任何错误消息、症状、详细信息或证据。如果他们没有报告任何错误或特定症状，那么就无法知道要跟踪什么 - 这可能是性能问题、没有错误处理的存储过程执行失败、两个会话之间的竞争条件影响了错误的数据顺序（隔离级别）或其他几十个问题之一。
如果他们提供了有关发生特定错误的信息，您可以使用 TSQL_Replay 模板配置跟踪，但在错误和警告类别下，也包括用户错误消息。使用Profiler 设置跟踪可能是最简单的，然后您可以将其导出到脚本文件并将其安排为问题期间的代理作业。这将捕获窗口期间的所有 TSQL 事件，您可以识别导致错误的操作以确定发生了什么。
如果是特定的性能问题（即这个应用程序进程/任务运行非常缓慢），那么您需要确定性能问题的原因。SolarWinds 数据将有助于确定不同资源（内存、CPU、IO）的高利用率，并查看sp_whoisactive，它是记录\捕获会话信息的好工具。您可以将 SQL 代理作业配置为在故障期间频繁运行并捕获会话信息并尝试识别遇到或导致报告的特定性能问题的会话。
最后，如果来自 Apps 的投诉更为笼统，即“性能只是在每晚 08:30 到 09:30 之间表现不佳”，那么 SolarWinds 将在此处用于查看正常时段与糟糕时段的性能指标和识别偏离基线的指标。
查看这篇关于SQL Server 中性能故障排除方法的文章，它是 SQL 性能调查的重要入门。
最后，关于您的具体问题：
TSQL_Replay 模板很好地覆盖了服务器上发生的 TSQL 活动，并且在您缩小问题范围之前将是一个很好的起点。
不同用途的不同工具。MDW 更像是随着时间的推移进行性能监控，跟踪可用于开发基线的统计信息。SolarWinds 可能已经收集了 MDW 可以提供的所有您需要的东西。
它适用于除 Express 之外的所有版本。