跟踪标志 4199 - 全局启用？

Question

这可能属于意见范畴，但我很好奇人们是否使用跟踪标志 4199作为 SQL Server 的启动参数。对于使用过它的人，您在什么情况下遇到过查询回归？

这似乎是全面的潜在性能优势，我正在考虑在我们的非生产环境中全局启用它，并让它静置几个月以找出任何问题。

2014 年（或 2016 年）是否默认将 4199 中的修复程序纳入优化器？虽然我理解不引入意外计划更改的情况，但在版本之间隐藏所有这些修复似乎很奇怪。

我们使用的是 2008、2008R2，主要是 2012。

Answer 1

就个人而言，每当我为新项目构建新服务器时，我总是全局启用 TF4199。当我将现有实例升级到较新版本时，这同样适用。

TF 启用会影响应用程序行为的新修复，但对于新项目，回归风险不是问题。对于从以前版本升级的实例，新旧版本之间的差异本身就是一个问题，无论如何都必须处理计划回归，所以我更喜欢在启用 TF4199 的情况下与之抗争。

就现有数据库而言，只有一种方法可以知道：测试它。您可以在现有设置上捕获工作负载并在启用标志后重放它。RML Utilities 可以帮助您自动化该过程，如本答案中所述。

显然，该标志会影响整个实例，因此您必须测试位于那里的所有数据库。

Answer 2

我对这个话题的搜索把我带到了这里，所以我想分享我最近在这个话题上的经验。

我正在运行 SQL 2014，所以我认为我不必关心 4199 一点点是安全的……但事实并非如此……

如何诊断您是否需要 4199

如果您的查询似乎运行不佳，特别是当您认为不应该运行时，请尝试将以下内容添加到它的末尾，看看它是否能解决您的所有问题，因为您可能需要4199 （“启用所有查询优化器修复。” )

SELECT SomeColumn
FROM SomeTable    
OPTION(QUERYTRACEON 4199)

在我的情况下，我有一个 top 10 子句炸毁了一个运行良好的查询，这让我觉得发生了一些可疑的事情，而 4199 可能会有所帮助。

关于 4199

在新的主要版本发布之后创建的任何 SQL Server 查询优化器错误/性能修复实际上都被隐藏和阻止了。这是为了防止它们实际上可能损害其他理论上完美优化的程序。因此，尽可能安装更新，默认情况下不会启用实际的查询优化器更改。因此，一旦完成了单个修复或增强功能，如果您想利用它，4199 就成为必需品。随着许多修复程序的出现，您最终会发现当其中一个影响您时，您自己会打开它。这些修复通常与它们自己的跟踪标志相关联，但 4199 用作主“打开每个修复”。

如果您知道需要哪些修复程序，您可以逐一启用它们，而不是使用 4199。如果您想启用所有修复程序，请使用 4199。

好的，所以你想要 4199 全球...

只需创建一个每天早上使用以下行运行的 SQL 代理作业即可全局启用跟踪标志。这可确保如果有人关闭它们或等，它们会重新打开。这个工作步骤有非常简单的 sql：

DBCC TRACEON (4199, -1);

其中 -1 指定 DBCC TRACEON 中的 Global 部分。有关更多信息，请参阅：

https://msdn.microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396

“重新编译”查询计划

在我最近的尝试中，我必须全局启用 4199，然后还删除现有的缓存查询计划：

sp_recompile 'dbo.SomeTable'

https://msdn.microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396

重新编译存储过程找到与数据库对象（例如表）相关的任何查询计划并删除这些查询计划，需要下一次尝试运行类似的查询来编译它们。

所以，在我的例子中，4199 阻止创建错误的查询计划，但我还必须删除那些仍然通过 sp_recompile 缓存的计划。从受影响的已知查询中选择任何表，您应该再次尝试该查询，假设您现在已全局启用 4199 并清除有问题的缓存查询计划。

结论 4199

当您使用索引时，智能查询计划优化对于实际智能地使用这些索引变得很重要，并且假设随着时间的推移将发布对查询优化过程的一些修复，您通常可以安全地运行 4199 全局启用，只要您意识到某些新修复实际上可能无法与高度优化的数据库一起使用，该数据库在所述修复之前在先前环境中进行了如此优化。但是 4199 有什么作用呢？它只是启用所有修复。