Drop过程语句的死锁

Question

我一直致力于通过多线程创建对象来提高数据库的安装速度(包含数千个对象).这导致了导致DROP PROCEDURE声明陷入僵局的不幸行为.

单线程部署需要很长时间(因为我们讨论的是很多数据库对象.当架构安装在几百个客户端时,转换架构并不是一件轻松的事情.).缓慢的部署阻碍了我们的开发/发布周期.

脚本包含以下代码

IF OBJECT_ID(N'myProc') IS NOT NULL
  BEGIN
    DROP PROCEDURE myProc
  END
GO
CREATE PROC....

第二个脚本包含

IF OBJECT_ID(N'myProc2') IS NOT NULL
  BEGIN
    DROP PROCEDURE myProc2
  END
GO
CREATE PROC....

这些程序完全不相关.没有依赖,所以每一个.

死锁图如下所示:

<deadlock-list>
 <deadlock victim="process6c3dc8">
  <process-list>
   <process id="process6c3dc8" taskpriority="0" logused="884" waitresource="OBJECT: 25:1949249999:0 " waittime="3834" ownerId="3008593" transactionname="DROPOBJ" lasttranstarted="2011-04-28T16:34:31.503" XDES="0xa882b950" lockMode="Sch-S" schedulerid="3" kpid="2588" status="suspended" spid="59" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2011-04-28T16:34:31.503" lastbatchcompleted="2011-04-28T16:34:31.503" clientapp=".Net SqlClient Data Provider" hostname="myPc" hostpid="7296" loginname="myLogin" isolationlevel="read committed (2)" xactid="3008593" currentdb="25" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
    <executionStack>
     <frame procname="adhoc" line="4" stmtstart="264" stmtend="352" sqlhandle="0x0200000092ebe0126e0f90268e2a5bf1eaba70a098515cd9">
DROP PROCEDURE myProc2     </frame>
    </executionStack>
    <inputbuf>
IF object_id(N&apos;myProc2&apos;) is not null
BEGIN
  PRINT N&apos;Dropping procedure myProc2 ...&apos;
  DROP PROCEDURE myProc2
END    </inputbuf>
   </process>
   <process id="processaa4242c8" taskpriority="0" logused="5800" waitresource="OBJECT: 25:1965250056:0 " waittime="3834" ownerId="3008596" transactionname="DROPOBJ" lasttranstarted="2011-04-28T16:34:31.503" XDES="0xab493950" lockMode="Sch-S" schedulerid="2" kpid="5768" status="suspended" spid="60" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2011-04-28T16:34:31.503" lastbatchcompleted="2011-04-28T16:34:31.503" clientapp=".Net SqlClient Data Provider" hostname="myPC" hostpid="8296" loginname="myLogin" isolationlevel="read committed (2)" xactid="3008596" currentdb="25" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
    <executionStack>
     <frame procname="adhoc" line="4" stmtstart="276" stmtend="370" sqlhandle="0x02000000f019293427b8052cc3d5d18be886f958c4b750a1">
DROP PROCEDURE myProc     </frame>
    </executionStack>
    <inputbuf>
IF object_id(N&apos;myProc&apos;) is not null
BEGIN
  PRINT N&apos;Dropping procedure myProc ...&apos;
  DROP PROCEDURE myProc
END    </inputbuf>
   </process>
  </process-list>
  <resource-list>
   <objectlock lockPartition="0" objid="1949249999" subresource="FULL" dbid="25" objectname="1949249999" id="lock87308e00" mode="Sch-M" associatedObjectId="1949249999">
    <owner-list>
     <owner id="processaa4242c8" mode="Sch-M"/>
    </owner-list>
    <waiter-list>
     <waiter id="process6c3dc8" mode="Sch-S" requestType="wait"/>
    </waiter-list>
   </objectlock>
   <objectlock lockPartition="0" objid="1965250056" subresource="FULL" dbid="25" objectname="myDatabase.dbo.myProc2" id="lock878d9e80" mode="Sch-M" associatedObjectId="1965250056">
    <owner-list>
     <owner id="process6c3dc8" mode="Sch-M"/>
    </owner-list>
    <waiter-list>
     <waiter id="processaa4242c8" mode="Sch-S" requestType="wait"/>
    </waiter-list>
   </objectlock>
  </resource-list>
 </deadlock>
</deadlock-list>

Answer 1

通过检查由DROP,CREATE或ALTER过程的不同命令取出的锁,我相信您可以通过更改您使用的模式来解决您的特定问题:

IF OBJECT_ID(N'myProc') IS NULL
    EXEC sp_executesql N'Create Proc myProc as RETURN 0'
GO
ALTER PROC myProc 
AS ...

当我看到DROP PROC取出的锁时,我看到:

• Sch-M锁取自resource_type ="METADATA.AUDIT_ACTIONS"和resource_type ="METADATA.PERMISSIONS"
• Sch-S锁定在sproc所指的桌子上
• 系统对象上的所有其他锁都是X或IX

当我看到锁定采取CREATE PROC时,我看到:

• 程序本身取出了Sch-M锁
• 在sproc引用的表格上简单地取出一个Sch-S锁(并且已经发布< - 更正)
• 系统对象上的所有其他锁都是X或IX

当我看到ALTER PROC拍摄的锁时,我看到:

• 程序本身取出了Sch-M锁
• Sch-S锁定在一个表格中,该表格是先前编译的sproc引用的版本(如果仅在新版本中将被简单地取出)
• 系统对象上的所有其他锁都是X或IX

因此,我认为您当前的死锁与访问MetaData资源有关,而这可以通过切换到ALTER模式来缓解.

然而,Sch-M和Sch-S锁仍然会以不同的方式发挥作用 - 如果你有其他的相互引用的sprocs,那么仍然可以实现不同的死锁.

附加评论:我很想知道为什么对象创建需要花费这么长时间.除了死锁之外 - 它实际上是在创建占用时间的存储过程吗？我的猜测是问题与表创建和填充有关,我想确保你配置了即时文件初始化,正确配置了数据文件增长设置,设置了恢复模型和/或日志备份,并且只是等待文件增长并在脚本运行时将其清零.