我们一直在遇到我们认为是 tempDB 内部争用所导致的麻烦。
每当我们遇到问题时，我们的系统总是在等待一个特定的资源：2：1：103，当我们查找它（使用 DBCC PAGE（2,1,103））时，会追溯到 object_id 75，即系统表 sysmultiobjrefs。
为了解决这个问题，我们有时可以通过杀死等待该资源的挂起的 spid 来解决问题……在更糟糕的情况下，我们必须实际停止 SQL 并重新启动它。
关于如何缓解这种情况有什么想法吗？
我们在具有 128GB RAM 的四核服务器上运行 SQL 2005 SP3 x64。磁盘也位于 SAN 上，日志/临时数据库/数据分别位于各自的 RAID 1/0 驱动器上。
TempDB 有 16 个数据文件（每个核心一个）和一个日志文件。
提前致谢。
答案1
您的 SQL 代码中是否包含大量 SELECT INTO 语句？这将导致锁定多个 tempdb 系统对象，直到 SELECT INTO 语句完成。
答案2
抢，
在我们的环境中，我们已经处理他的 2:1:103 问题大约一个月了。防止此问题的方法之一是定期重新启动 SQL 服务（如果可以的话）。许多论坛都没有针对此特定问题的明确答案。Linci Shea（MVP）和其他几个人在博客中提出的论点中，T1118 标志并未被称为有效。
我亲眼目睹问题发生并消失的一个生产场景是，当 SQL Server 有机会将内存从 24 GB 增加到 27 GB 时。在 24 GB 时，大约有 40 个进程挂在 2:1:103 上，而一个不相关的任务作业正在数据库服务器上运行。我终止了该任务，SQL 开始从可用的 30 GB 中获取更多内存，在 Tempdb 争用达到 27GB 后大约一分钟左右，Tempdb 争用逐渐消失在 27GB 上。这是您可以尝试自己测试的一个领域。减少数据库服务器上其他服务的占用空间并增加 SQL 的最大可用内存。
如果您找到其他解决方案，请告诉我。
辛格。
答案3
我知道我来晚了，但我的团队本周遇到了 2:1:103 问题。本质上，此资源上的争用表示与 tempdb 中的 DDL 操作争用，并且是由创建/销毁过多的临时表或临时表变量引起的。我在博客中提到了这一点http://www.mattwrock.com/post/2011/09/10/Latch-waits-on-21103-You-are-probably-creating-too-many-temp-tables-in-Sql-Server.aspx跟踪标志 T1118 或向 tempDb 添加文件不会缓解此处的争用。关键是减少临时表和临时表变量的使用，或者评估它们的使用上下文以查看它们是否被缓存。请参阅http://technet.microsoft.com/en-us/library/cc966545.aspx详情请见此处。
答案4
您是否尝试过启用跟踪标志 T1118？
文章引述：
注意：跟踪标志 -T1118 在 Microsoft SQL Server 2005 和 SQL Server 2008 中也可用且受支持。但是，如果您运行的是 SQL Server 2005 或 SQL Server 2008，则无需应用任何修补程序。
将 tempdb 数据文件的数量增加到至少与处理器数量相等。此外，创建大小相等的文件。有关更多信息，请参阅“更多信息”部分。¨
SP2 中的跟踪标志 T1118 曾经存在性能问题，但 Ms 发布了修补程序，应该会在 SP3 中修复该问题，就像您的情况一样。
我同意 mrdenny 关于如何创建临时表的观点，你永远不应该使用 SELECT * INTO #x FROM TableA 创建临时表，除非你有一个如下的 WHERE 子句：
其中 1=2
但我的建议是使用 CREATE TABLE #x 语法。为什么？只要您的查询尝试获取要插入临时表的数据，SQL 就会在系统表中放置大量锁。如果您使用显然不会返回任何行的 where 子句或 create table 语法，锁将被保留一小段时间。
/哈坎·温瑟