Microsoft 关于Trace Flag 4199的知识库文章有点令人困惑：
...任何可能影响查询执行计划的修补程序都必须由跟踪标志控制。除了修复可能导致错误结果或损坏的错误外，这些修补程序默认情况下处于关闭状态，并且需要跟踪标志才能启用修复。
注意：我假设“修补程序”是累积更新（又名“CU”）。如果我错了，请发表评论。
所以...让我们假设我正在运行最新的服务包。SP 包括以前 CU 中的所有修复。是否为 SP（甚至RTM）打开了修补程序？或者仍然需要跟踪标志 4199？
我将去现场为客户运行一些性能测试。他们有一个 Windows 故障转移集群，其中有一个 SQL Server 的集群实例。对于这篇文章，我们假设我的客户的 Windows 故障转移集群有两个节点，如下图所示。
我将运行服务器端跟踪（通过从 SQL Profiler 生成的 tsql 脚本）——我很乐意这样做。在我
EkTechready14.Redmond.com\MySqlInstance通过 SSMS 连接并启动跟踪后，我认为跟踪运行时哪个节点处于活动状态并不重要。你同意吗？我还将运行 Perfmon 来收集一些普通的统计数据。也许对于 Perfmon，哪个节点处于活动状态确实很重要。我应该从客户端访问点 (
EKTechready14.Redmond.com) 运行 Perfmon 吗？还是来自活动节点（或者MSDEPLOY60-01或MSDEPLOY60-02）？
我一直在努力寻找有关为组成员提供 SysAdmin 服务器角色的 Active Directory 组的最佳实践信息或任何建议。我在一份新工作中，我是 50 到 100 个 SQL 实例的唯一 SQL Server DBA。还有另一位（网络）系统管理员将具有 SysAdmin 服务器角色。将来可能还会有其他人（可能是也可能不是 DBA）。
我正在描绘两种选择：
选项 1：在 Active Directory 中创建一个组，根据需要将我自己和任何其他人添加到该组中，在 AD 组的每个 SQL Server 实例上创建 SQL Server 登录名，并为登录名提供 SysAdmin 服务器角色。
这很方便，并且具有一定的灵活性。但这似乎是一个巨大的安全风险。作为一名 DBA，我无法完全控制 AD 组的成员（或外）。目前，每个 SQL Server 实例都有少数具有 SysAdmin 角色的登录名。除了我、网络系统管理员和 sa 之外，我想将 SysAdmin 带离他们所有人。如果我完成这项任务并实施选项 1，我最终不会比我开始的地方好。
选项 2：在每个 SQL Server 上使用单独的 Windows 身份验证（AD 帐户）登录，并赋予每个 SysAdmin 服务器角色。
这不是很方便，但只有两个人/AD 登录具有 SysAdmin 权限。只要我们都没有将 SysAdmin 角色成员资格授予其他人，就应该有一定的顺序。
哪个选项是首选？还有其他我忽略的选择吗？