跟踪标志4199-全局启用？

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

当然，这似乎似乎是潜在的整体性能优势，我正在考虑在我们的非生产环境中在全球范围内启用它，并将其放置几个月以找出任何问题。

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

我们使用的是2008、2008R2，大部分使用的是2012。

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

TF启用了可能影响应用程序行为的新修复程序，但是对于新项目，回归的风险不是问题。对于从以前版本升级的实例，旧版本和新版本之间的差异是一个值得关注的问题，而且无论如何都必须应对计划回归，因此我更喜欢在启用TF4199的情况下与之抗衡。

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

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

我对该主题的搜索将我带到这里，所以我只想分享我最近在该主题上的经验。

我正在运行SQL 2014，因此我认为不必担心4199会很安全...但这不是真的...

如何诊断是否需要4199

如果您的查询似乎运行不佳，尤其是在您认为运行不正常的情况下，请尝试在其末尾添加以下内容，以查看它是否可以解决所有问题，因为您可能需要4199 （“启用所有查询优化器修复程序。”）

SELECT SomeColumn
FROM SomeTable    
OPTION(QUERYTRACEON 4199)

在我的情况下，我有一个前10个子句，它炸开了一个没有该查询就可以运行的查询，这使我认为正在发生一些麻烦，而4199可能会有所帮助。

大约4199

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

如果知道所需的修补程序，则可以逐个启用而不是使用4199。如果要启用所有修补程序，请使用4199。

好的，所以您要在全球范围内购买4199 ...

只需创建一个每天早晨运行的SQL代理作业，并使用以下代码行即可全局启用跟踪标志。这样可以确保是否有人将其关闭等，然后将其重新打开。此工作步骤具有非常简单的sql：

DBCC TRACEON (4199, -1);

其中-1指定DBCC TRACEON中的全局零件。有关更多信息，请参见：

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

“重新编译”查询计划

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

sp_recompile 'dbo.SomeTable'

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

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

因此，在我的情况下4199阻止了不良查询计划的创建，但是我还必须删除那些仍通过sp_recompile缓存的计划。从已知的受影响的查询中选择任何表，假设现在已全局启用4199并清除了有问题的缓存查询计划，则应该再次尝试该查询。

总结4199

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

我想与跟踪标记4199分享我的经验。

我刚刚完成了对运行SQL Server 2012 SP3的客户系统的性能问题的诊断。客户正在将报告数据库从生产OLTP服务器移至新服务器。客户的目标是通过OLTP查询消除对资源的竞争。不幸的是，客户说新的报告服务器非常慢。

在OLTP系统上运行的示例查询在1.6秒内完成。该查询计划在作为视图一部分的约2亿行表上进行了索引查找。

在新服务器上，相同的查询在10分44秒内完成。它在相同的约2亿行表上执行了索引扫描。

报告服务器数据是OLTP数据的副本，因此它似乎没有数据差异。

直到我回想起我们的软件（运行其OLTP系统）在启动时启用了某些跟踪标志时，我感到很沮丧。我记得其中一个4199是一个查询优化器修复程序。

我在客户的新报表服务器上测试了启用跟踪标记4199，并且报表查询在0.6秒内完成。（哇！）我禁用了跟踪标志，查询又在10分44秒内恢复完成。启用标志：回到0.6秒。显然，启用跟踪标志使优化器可以使用索引查找进入2亿行表的视图。

在这种情况下，跟踪标记4199启用的查询优化产生了巨大的差异。您的经历可能会有所不同。但是，基于这种经验，对我来说绝对值得启用。