这可能属于意见范畴，但我很好奇人们是否使用跟踪标志 4199作为 SQL Server 的启动参数。对于使用过它的人，您在什么情况下遇到过查询回归？
这似乎是全面的潜在性能优势，我正在考虑在我们的非生产环境中全局启用它，并让它静置几个月以找出任何问题。
2014 年（或 2016 年）是否默认将 4199 中的修复程序纳入优化器？虽然我理解不引入意外计划更改的情况，但在版本之间隐藏所有这些修复似乎很奇怪。
我们使用的是 2008、2008R2，主要是 2012。
我们的其中一台 SQL Server 最近报告了以下错误：
DATE/TIME: 2/25/2013 9:15:14 PM
DESCRIPTION: No catalog entry found for partition ID 9079262474267394048
in database 2. The metadata is inconsistent. Run DBCC CHECKDB to check for
a metadata corruption.
不到 15 分钟后，我连接到服务器并运行：
SELECT name
FROM sys.databases
WHERE database_id = 2;
返回'tempdb'。然后我跑了：
DBCC CHECKDB ('tempdb') WITH NO_INFOMSGS, TABLERESULTS;
没有返回任何结果，表明受影响的数据库没有问题。
数据库中的损坏如何导致上述错误消息DBCC CHECKDB但未报告问题？我假设如果页面校验和计算失败，导致页面被标记为怀疑引用该页面的任何对象将无法删除，但我一定是错的。
一旦页面被标记为“可疑”，如何将其标记为“不可疑”、“已修复”或“重用”，或者DBCC CHECKDB不报告相关页面有任何问题的任何内容？
编辑：2013-02-27 13:24
只是为了好玩，我试图在 TempDB 中重新创建损坏，假设 #temp 表是罪魁祸首。
但是，由于我无法SINGLE_USER在 TempDB 中设置该选项，因此无法用于DBCC WRITEPAGE损坏页面，因此我无法在 TempDB 中强制损坏。
而不是使用DBCC WRITEPAGE …
希望这有一个简单的答案，我错过了一些明显的东西。我有一个表，其中行数 * 行大小比表使用的实际数据空间小得多。
如果我运行标准报告“Top Tables 的磁盘使用情况”，我得到的数字是：
# Records Reserved (KB) Data (KB) Indexes (KB) Unused (KB)
33,245 32,962,192 31,070,264 144 1,891,784
这（除非我遗漏了一些东西）意味着每一行占用的空间不到 1MB！
表模式（我没有设计）是：
CREATE TABLE [MySchema].[MyTable]
(
[Code] [varchar](4) NOT NULL,
[SomeID] [smallint] NOT NULL,
[SomeID1] [smallint] NOT NULL,
[Updated] [datetime] NOT NULL,
[SomeId2] [int] NULL,
[SomeId3] [int] NULL,
[Somekey] [real] NULL,
[desc1] [char](12) NULL,
[colA] [real] NULL,
[someid4] [char](20) NULL,
[starttime] [real] NULL,
[endtime] [real] NULL,
[duration] [real] NULL,
[reason] [real] NULL,
[status] [real] NULL,
[category] [real] NULL, …这个问题什么是将 sql 08 空间数据放到地图上的最简单方法？（以及许多其他文章）推荐 Craig Dunn 的 Geoquery，但所有下载链接似乎都已失效。
SQL Server Managament Studio 的空间结果选项卡将显示单个数据集，这篇 MSDN 文章SQL Server 2008中的空间数据支持提到了一种UNION ALL用于显示叠加在地图上的点数据的解决方法：
SELECT geog, name FROM Mondial.dbo.city WHERE geog IS NOT NULL
UNION ALL
SELECT geog, cntry_name FROM SpatialSamples.dbo.cntry00
每当我尝试类似的事情时，我只会显示一个结果集。
SQL Server 2008 或 2012 中是否有内置的东西来做到这一点？