标签: trace-flags

那里有很多跟踪标志。有些有据可查，有些没有，还有一些在 2016 版本中找到了默认行为状态的方法。除了官方支持渠道、微软员工等，还有什么方法可以找到新的跟踪标志？

我已经在这里和这里阅读了 Aaron Bertrand 最近的几篇文章，但没有发现任何关于新跟踪标志的信息。

我将 mssqlsystemresource 的数据和日志文件复制到一个新位置，并像常规数据库一样附加它以浏览系统表和视图，但没有立即发现任何内容。我考虑过列出已知跟踪标志的列表，并循环遍历不在该列表中的数字，以查看 DBCC TRACEON 允许哪些，但想先在这里提出问题。

假设启用它们的 DBCC 命令必须检查某些资源以确保跟踪标志有效，那么它会到达哪里？是否有包含列表的 .dll 或其他系统文件？

我知道这个问题撒了一个广泛的网络，但促使它阅读的原因是阅读了具有特定预期行为的 Trace Flag 以及 2016 年没有产生所描述效果的新功能。我最初的想法是，也许数字以某种方式转置了，比如 7129 变成了 7219。我希望得到一个范围内的有效跟踪标志列表，比如 7000-7999，以寻找排列。将它们全部作为 DBCC TRACEON 标志和启动参数进行测试，再加上针对功能行为测试结果，将会非常麻烦。

在阅读了 Josh Darnell 的Unusual THREADPOOL Waits之后，一位 Twitter 用户提到有一个未记录的跟踪标志可以防止修剪空闲工人：

这个想法是，一旦 SQL Server 创建了足够的线程来为峰值工作负载提供服务，它就不应该在 15 分钟左右的不需要的工作线程之后修剪工作线程（将它们释放到操作系统）。

空闲的工作线程将继续使用资源（例如内存），但是THREADPOOL当突然需要更多工作线程时，不会出现等待的爆发。显然，这在使用 Always On 可用性组时会有所帮助。

这个未记录的跟踪标志是什么，它是如何工作的？

我的数据库在具有 32 个核心处理器的 SQL Server 2012 上运行。根据sp_blitz（Brent Ozar），我们需要启用跟踪标志 8048。

我们应该在 2012 年启用这个标志，还是只推荐在 2014 年以后启用？

建议每个 SQL 实例都打开 TF 1118

Paul 对使用跟踪标志 1118 的建议是什么？从 SQL Server 2000 开始，每个人都应该在 SQL Server 的所有实例上打开它。打开它没有任何缺点。 保罗·兰德尔

它记录在KB 2154845 中，虽然它确实影响所有数据库，但影响最大的是 tempdb

这意味着实例上每个数据库中的每个新分配的对象都会获得自己的私有 64KB 数据。Tempdb 通常是创建大多数对象的地方，因此它在那里发挥了最大的作用。 肯德拉·利特尔

我环顾四周，没有发现任何人反对使用它。那么，我们应该在创建新实例时将其作为我们流程的一部分，并在机会出现时将其追溯添加到现有 SQL 实例中吗？

我在 2014 年使用 SQL 2000，还没有在 2016 年上线。我们按照说明为每个处理器使用 1 个 tempdb，最多 8 个。

我阅读了一篇文章，解释了在 SQL Server 中设置处理器关联性所带来的不良副作用。

我了解到，在大多数情况下，SQL Server 的默认设置效果最好，因为当我们设置处理器关联性时，我们正在使调度程序受 CPU 限制。我这里有几个问题：

1. 当处理器关联性的默认设置效果最佳时，为什么需要显式设置处理器关联性？

2. 文章还指出：

   当跟踪标志 8002 打开时，调度程序不再绑定到 CPU。

   是否有理由说跟踪标志 8002ON就像默认Processor affinity配置一样，只是 SQL Server 可用的核心数量较少？

   例如，如果我们将 32 核处理器的处理器亲和性设置为 16 核（跟踪标志 8002 为ON），那么具有与其关联的 SQL 线程的调度程序是否只需16 cores切换？

3. 设置处理器关联性会限制 SQL Server 计划程序使用某些核心。此设置是否还会限制其他 CPU 密集型进程（例如 .NET 应用程序）的核心使用情况？

   我想说的是，如果对于 32 核 CPU，处理器亲和性设置为 16 核，那么 SQL Server 调度程序只有 16 核可供切换。如果是，那么另一个 CPU 密集型应用程序（例如 .NET 应用程序）又如何呢？.NET 应用程序是否可以在所有 32 个内核之间自由切换，因为它将依赖于 Windows 操作系统而不是SQLOS？

这只是我想象的一个假设场景。考虑到生产场景，我非常怀疑人们会在同一台服务器上使用 SSMS 和 CPU 密集型 .NET 应用程序。这将极大地影响性能并导致任何其他进程的 CPU 可用性不足。如果我在这里错了，请纠正我。

我试图了解跟踪标志 2861 以及它对琐碎查询的实际作用？

简介说：

SQL Server 通常不会缓存这些简单查询的计划，因为缓存计划的成本高于为此类简单查询生成新计划的成本。

这显然是不正确的，因为我运行的每个“琐碎”查询似乎都被缓存了。所以我想知道 2861 的意义是什么，除非我误解了一个微不足道的计划实际上是什么。当我查询缓存计划并且它说它是临时的和微不足道的时，我没有理由怀疑它。

希望有人能给我解惑。

我们的 SQL Server 2016 开发服务器在启动时设置了跟踪标志 10260。运行 SQL Server 2016 的其他服务器没有。
我搜索了高低，但未能找到有关该主题的任何信息。

这个跟踪标志有什么作用？

移除是否安全？

我们在 SQL Server 2012 中使用 4032 和 3605 跟踪标志来获取预期的日志输出。

现在，我们希望每天轮换日志文件，将其存档在 Amazon Glacier 存储设施中。

任何有关日志轮转的指针将不胜感激，

我们希望在服务器上永久启用跟踪标志。我知道在SQL Server配置管理器中有一个添加启动参数的选项。是否有任何选项可以通过程序/功能/其他解决方案在服务器重新启动后自动执行此操作？

我们希望向无法访问 SQL Server 配置管理器且没有sysadmin级别权限的团队提供跟踪标志（以及启用/禁用选项）的可见性。

我们正在考虑sysadmin在服务器重新启动后以组用户身份执行的作业（不确定是否可能）。DBCC TRACEON (7412) 作业可以有一个步骤，使用诸如等的代码执行过程。