sql-server – 来自不同进程中相同临时表的锁的死锁

前端之家收集整理的这篇文章主要介绍了sql-server – 来自不同进程中相同临时表的锁的死锁前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我发现了一个似乎显示出我认为不可能的事情的僵局.死锁涉及两个进程:

1. process8cf948 SPID 63

>在临时表#PB_Cost_Excp_Process_Invoices_Work上执行ALTER TABLE.
>拥有表上的IX锁#BB_Cost_Excp_Process_Invoices_Work,对象ID为455743580

2. process4cb3708 SPID 72

>在临时表#PB_Cost_Excp_Process_Invoices_Work上执行UPDATE,它应该是它自己的表的唯一副本.
>拥有Sch-M锁定#PB_Cost_Excp_Process_Invoices_Work,使用相同的对象ID 455743580!

这应该是不可能的.我错过了什么吗? #Temporary表真的可以在这两个SPID之间重用吗?

这是在具有累积更新1(版本10.50.4260)的sql Server 2008 R2 Service Pack 2上.

完整的未改变的死锁痕迹如下.请注意这两个进程如何在具有相同表名的相同对象ID上运行#PB_Cost_Excp_Process_Invoices_Work_SNIP_0000000D8519:

12/14/2012 13:46:03,spid23s,Unknown,waiter id=process8cf948 mode=X requestType=wait
12/14/2012 13:46:03,waiter-list
12/14/2012 13:46:03,owner id=process4cb3708 mode=Sch-M
12/14/2012 13:46:03,owner-list
12/14/2012 13:46:03,objectlock lockPartition=0 objid=455743580 subresource=FULL dbid=2 objectname=tempdb.dbo.#PB_Cost_Excp_Process_Invoices_Work_________________________________________________________________________________0000000D8519 id=lock371705d00 mode=Sch-M associatedObjectId=455743580
12/14/2012 13:46:03,waiter id=process4cb3708 mode=Sch-M requestType=wait
12/14/2012 13:46:03,owner id=process8cf948 mode=IX
12/14/2012 13:46:03,objectlock lockPartition=3 objid=455743580 subresource=FULL dbid=2 objectname=tempdb.dbo.#PB_Cost_Excp_Process_Invoices_Work_________________________________________________________________________________0000000D8519 id=lock3139b4780 mode=IX associatedObjectId=455743580
12/14/2012 13:46:03,resource-list
12/14/2012 13:46:03,Proc [Database Id = 8 Object Id = 1857974987]
12/14/2012 13:46:03,inputbuf
12/14/2012 13:46:03,EXEC PB_ProcessExc_Costs_Submit_SP @SiteKey,@PWDate
12/14/2012 13:46:03,frame procname=PDICompany_218_01.dbo.DR_SubmitPaperwork_SP line=174 stmtstart=12912 stmtend=13018 sqlhandle=0x03000800cb72be6e500434018da000000100000000000000
12/14/2012 13:46:03,EXEC PB_ProcessExc_Costs_Create_SP

    -- Clean up work table
12/14/2012 13:46:03,frame procname=PDICompany_218_01.dbo.PB_ProcessExc_Costs_Submit_SP line=138 stmtstart=11890 stmtend=12012 sqlhandle=0x03000800428c1f1950f833018da000000100000000000000
12/14/2012 13:46:03,UPDATE #PB_Cost_Excp_Process_Invoices_Work
    SET PBCEPrcInv_RtlPkg_Item_Quantity = RtlPkg_Item_Quantity
    FROM #PB_Cost_Excp_Process_Invoices_Work
        INNER JOIN Item_Packages (NOLOCK)
            ON PBCEPrcInv_ItemPkg_Key = ItemPkg_Key
        INNER JOIN Retail_Packages (NOLOCK)
            ON ItemPkg_RtlPkg_Key = RtlPkg_Key

    -- Lookup pricebook cost
12/14/2012 13:46:03,frame procname=PDICompany_218_01.dbo.PB_ProcessExc_Costs_Create_SP line=25 stmtstart=2394 stmtend=3050 sqlhandle=0x030008003a082846321f46018da000000100000000000000
12/14/2012 13:46:03,executionStack
12/14/2012 13:46:03,process id=process8cf948 taskpriority=0 logused=0 waitresource=OBJECT: 2:455743580:0  waittime=3739 ownerId=707053534 transactionname=UPDATE lasttranstarted=2012-12-14T13:45:59.327 XDES=0x3c4502930 lockMode=X schedulerid=4 kpid=7276 status=suspended spid=72 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2012-12-14T13:45:58.337 lastbatchcompleted=2012-12-14T13:45:58.337 clientapp=PDI WCF Services - pdidb01-PDIMaster.cfg hostname=PDIWEB01 hostpid=2084 loginname=pdiuser isolationlevel=read committed (2) xactid=707053534 currentdb=8 lockTimeout=4294967295 clientoption1=673316896 clientoption2=128568
12/14/2012 13:46:03,EXEC dbo.PB_ProcessExc_Costs_CreateInvoiceWorkTable_SP
12/14/2012 13:46:03,frame procname=PDICompany_218_01.dbo.PB_ProcessExc_Costs_Submit_SP line=58 stmtstart=5782 stmtend=5894 sqlhandle=0x03000800428c1f1950f833018da000000100000000000000
12/14/2012 13:46:03,ALTER TABLE #PB_Cost_Excp_Process_Invoices_Work DROP COLUMN PBCEPrcInv_Filler
12/14/2012 13:46:03,frame procname=PDICompany_218_01.dbo.PB_ProcessExc_Costs_CreateInvoiceWorkTable_SP line=50 stmtstart=5382 stmtend=5538 sqlhandle=0x0300080025d75a14ffff4701969f00000100000000000000
12/14/2012 13:46:03,process id=process4cb3708 taskpriority=0 logused=0 waitresource=OBJECT: 2:455743580:3  waittime=3739 ownerId=707052778 transactionname=ALTER TABLE lasttranstarted=2012-12-14T13:45:58.517 XDES=0x5f48bce80 lockMode=Sch-M schedulerid=6 kpid=7212 status=suspended spid=63 sbid=0 ecid=0 priority=0 trancount=1 lastbatchstarted=2012-12-14T13:45:58.513 lastbatchcompleted=2012-12-14T13:45:58.513 clientapp=PDI WCF Services - pdidb01-PDIMaster.cfg hostname=PDIWEB01 hostpid=2084 loginname=pdiuser isolationlevel=read committed (2) xactid=707052778 currentdb=2 lockTimeout=4294967295 clientoption1=673316896 clientoption2=128568
12/14/2012 13:46:03,process-list
12/14/2012 13:46:03,deadlock victim=process4cb3708
12/14/2012 13:46:03,deadlock-list

UPDATE

有问题的计算机在任务管理器和设备管理器中显示16个处理器,因此启用了锁定分区,并且这两个锁定位于不同的锁定分区上.我不知道锁分区是否是造成这种情况的原因.

我也找到了this intriguing post on the CSS SQL Server Engineers blog.

更新2

临时表在每个存储过程结束时被删除.它们是使用模式创建#table,修改模式,插入,更新,选择,然后删除.使用此temp #table的公共过程有多个入口点,因此我们有一个中央过程来设置调用公共过程所需的列.否则,我们必须在所有入口点procs中复制相同的#table定义.

从多个客户端应用程序经常调用该进程.一些客户端应用程序从多个线程调用此进程.其他人一次运行一个.想想库存/会计软件,其中家庭办公室并行处理数千个商店的数据,而商店也自己运行相同的过程.因此,如果在启用锁定分区时这是一个罕见的问题,那么在我们较大的客户数据库中这种情况就不会那么罕见了.

更新3 – 2012-12-19

另一个客户在sql Server 2012 build 11.0.2100上遇到了同样的问题.我没有在累积更新说明中看到任何针对此问题的修复程序.研究.

更新4 – 2013-02-13

Microsoft已在以下更新中发布了此错误的修复程序:

> Cumulative Update Package 4 for SQL Server 2008 R2 SP2
> Cumulative Update Package 2 for SQL Server 2012 SP1

解决方法

原文链接:https://www.f2er.com/mssql/80314.html

猜你在找的MsSQL相关文章