这可能属于意见范畴，但我很好奇人们是否使用跟踪标志 4199作为 SQL Server 的启动参数。对于使用过它的人，您在什么情况下遇到过查询回归？
这似乎是全面的潜在性能优势，我正在考虑在我们的非生产环境中全局启用它，并让它静置几个月以找出任何问题。
2014 年（或 2016 年）是否默认将 4199 中的修复程序纳入优化器？虽然我理解不引入意外计划更改的情况，但在版本之间隐藏所有这些修复似乎很奇怪。
我们使用的是 2008、2008R2，主要是 2012。
这是我的问题。我正在尝试通过完整还原将数据库移动到新服务器，然后通过快速差异备份/还原进行切换。我可以毫无问题地进行完整还原，但是在还原差异备份时，我收到以下警告：
消息 3127，级别 16，状态 1，第 1 行 恢复的数据库 'DatabaseName' 的文件 'Database_Log2' 处于失效状态，因为该数据库正在使用简单恢复模型并且该文件被标记为可读写访问。因此，只能通过分段还原来恢复只读文件。
数据库恢复并被视为联机，但由于此 DEFUNCT 文件导致任何备份操作失败，并出现以下错误：
消息 3636，级别 16，状态 2，第 1 行处理数据库 ID 10 文件 ID 6 的“BackupMetadata”元数据时出错。消息 3046，级别 16，状态 2，第 1 行遇到不一致的元数据。唯一可能的备份操作是使用 WITH CONTINUE_AFTER_ERROR 或 NO_TRUNCATE 选项的尾日志备份。消息 3013，级别 16，状态 1，第 1 行 BACKUP DATABASE 异常终止。
如果我在完整和差异上执行 RESTORE FILELISTONLY 都会给我相同的输出，这与我从源数据库上的 sys.database_files 看到的相匹配。服务器为 SQL2012 SP1，开发版。
我可以做一个完整的备份，然后立即做一个差异，并将这些文件还原到同一服务器上的不同数据库，并看到完全相同的问题，因此差异是如何创建的。如果我使用 RECOVERY 还原完整备份，则没有问题。我不知道这个文件是否曾经存在于这个数据库中，但完全有可能这个文件曾经存在并且很久以前被删除了。如果我在恢复的数据库上查询 sys.database_files，DEFUNCT 文件具有 drop_lsn 的值，这似乎证实了这一点。目前在源数据库中只有一个文件组 (PRIMARY)、4 个数据文件和一个日志文件。
有任何想法吗？
可能是一个快速的问题。
我们希望在我们的环境中测试几个跟踪标志作为启动参数，虽然我知道我们可以DBCC TRACESTATUS用来获取全局范围的跟踪标志，但它没有指定这是在启动时设置还是仅使用 -1 设置旗帜。解析 SQL 错误日志是唯一可用的方法吗？可能是某个地方的注册表项？
任何可以以编程方式解决的方法都是有用的。
谢谢阅读！