由于我们认为是tempDB内的争用，导致我们遇到了麻烦。
每当我们遇到问题时，我们的系统总是等待一个特定的资源：2：1：103，当我们查找它时（使用DBCC PAGE（2,1,103））跟踪回到object_id 75，这是系统表sysmultiobjrefs 。
为了解决这个问题，我们有时候可以避免在这个资源上等待悬挂的spids。在更糟糕的情况下，我们必须停止SQL并且启动它。
任何想法如何减轻这一点？
我们在带有128GB内存的四核/四核服务器上运行SQL 2005 SP3 x64。 磁盘也位于SAN上，每个磁盘上有自己的RAID 1/0驱动器上的日志/临时数据库/数据。
TempDB有16个数据文件（每个核心一个）和一个日志文件。
提前致谢。
你的SQL代码中有很多SELECT INTO语句吗？ 这将导致locking几个tempdb系统对象，直到SELECT INTO语句完成。
抢，
在我们的环境中，我们一直在处理他2：1：103的问题大约一个月。 如果这是一个选项，防止此问题的一种方法是定期重新启动SQL服务。 很多论坛对这个问题都没有明确的答案。 T1118旗帜在林芝牧师（MVP）和其他一些人的博客中提出的论点中并没有被称为有效的。
一个我个人看到问题发生和消失的生产场景是SQL服务器有机会将内存从24 Gb增加到27 GB。 在24GB时，在2：1：103上挂起了大约40个进程，而在数据库服务器上运行了一个不相关的任务作业。 我杀了这个任务，SQL开始从可用的30GB中获取更多的内存，Tempdb争夺在27GB之后大约一分钟左右逐渐消失在27GB。 这是你可以尝试自己testing的一个领域。 减less数据库服务器上其他服务的占用空间，并增加SQL的最大可用内存。
让我知道，如果你find任何其他的解决scheme相同。
辛格。
我意识到我在这里的晚会已经迟到了，但是我们的队伍本周以2：1：103的比赛进行了比赛。 本质上，对这个资源的争用表明与tempdb中的DDL操作的争用，并且是由创build/销毁太多的临时表或临时表variables引起的。 我在这个博客上有这个： 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来缓解。 关键是要么减less临时表和临时表variables的使用，要么评估它们使用的上下文以查看它们是否被caching。 请参阅http://technet.microsoft.com/en-us/library/cc966545.aspx以获得更好的细节。
你有没有检查过，以确保你不只是从交易上走彼此的工作僵局？ 您是否在locking发生时检查了运行/locking的SQL查询？
您是否尝试启用跟踪标志T1118？
来自MS的KB artikle
从文章引用：
注意跟踪标志-T1118也在Microsoft SQL Server 2005和SQL Server 2008中受支持。但是，如果运行SQL Server 2005或SQL Server 2008，则不必应用任何修补程序。
增加tempdb数据文件的数量至less等于处理器的数量。 另外，创build大小相同的文件。 有关更多信息，请参阅“更多信息”部分
SP2中的traceflag T1118曾经是一个性能问题，但是Ms发布了一个修补程序，它应该在SP3中修复，就像你的情况一样。
我同意mrdenny关于临时表是如何创build的，你不应该使用SELECT * INTO #x FROM TableA创build一个临时表，除非你有这样的WHERE子句：
WHERE 1 = 2
但我的build议是使用CREATE TABLE #x语法。 为什么？ 只要您的查询尝试获取您的数据以插入到临时表中，SQL就会在系统表中放置很多锁。 如果使用明显不会返回任何行或创build表语法的where子句，锁将会保持一段短时间。
/HåkanWinther