web-dev-qa-db-ja.com

異なるプロセスの同じ一時テーブルのロックによるデッドロック

不可能だと思ったものを示すようなデッドロックを発見しました。デッドロックには2つのプロセスが関係しています。

1。 process8cf948 SPID 6

  • 一時テーブル#PB_Cost_Excp_Process_Invoices_WorkでALTER TABLEを実行します。

  • オブジェクトID 455743580のテーブル#PB_Cost_Excp_Process_Invoices_WorkのIXロックを所有しています

2。 process4cb3708 SPID 72

  • 一時テーブル#PB_Cost_Excp_Process_Invoices_Workに対するUPDATEでの実行。これは、テーブルの独自の一意のコピーであると想定されています。

  • #PB_Cost_Excp_Process_Invoices_WorkのSch-Mロックを所有同じオブジェクトID 455743580を使用！

これは不可能だと思われます。何か不足していますか？ #Temporaryテーブルは、これら2つのSPID間で本当に再利用されましたか？

これは、累積的な更新1（バージョン10.50.4260）が適用されたSQL Server 2008 R2 Service Pack 2にあります。

変更されていない完全なデッドロックトレースを以下に示します。 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,spid23s,Unknown,waiter-list
12/14/2012 13:46:03,spid23s,Unknown,owner id=process4cb3708 mode=Sch-M
12/14/2012 13:46:03,spid23s,Unknown,owner-list
12/14/2012 13:46:03,spid23s,Unknown,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,spid23s,Unknown,waiter id=process4cb3708 mode=Sch-M requestType=wait
12/14/2012 13:46:03,spid23s,Unknown,waiter-list
12/14/2012 13:46:03,spid23s,Unknown,owner id=process8cf948 mode=IX
12/14/2012 13:46:03,spid23s,Unknown,owner-list
12/14/2012 13:46:03,spid23s,Unknown,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,spid23s,Unknown,resource-list
12/14/2012 13:46:03,spid23s,Unknown,Proc [Database Id = 8 Object Id = 1857974987]
12/14/2012 13:46:03,spid23s,Unknown,inputbuf
12/14/2012 13:46:03,spid23s,Unknown,EXEC PB_ProcessExc_Costs_Submit_SP @SiteKey, @PWDate
12/14/2012 13:46:03,spid23s,Unknown,frame procname=PDICompany_218_01.dbo.DR_SubmitPaperwork_SP line=174 stmtstart=12912 stmtend=13018 sqlhandle=0x03000800cb72be6e500434018da000000100000000000000
12/14/2012 13:46:03,spid23s,Unknown,EXEC PB_ProcessExc_Costs_Create_SP

    -- Clean up work table
12/14/2012 13:46:03,spid23s,Unknown,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,spid23s,Unknown,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,spid23s,Unknown,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,spid23s,Unknown,executionStack
12/14/2012 13:46:03,spid23s,Unknown,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,spid23s,Unknown,Proc [Database Id = 8 Object Id = 1857974987]
12/14/2012 13:46:03,spid23s,Unknown,inputbuf
12/14/2012 13:46:03,spid23s,Unknown,EXEC PB_ProcessExc_Costs_Submit_SP @SiteKey, @PWDate
12/14/2012 13:46:03,spid23s,Unknown,frame procname=PDICompany_218_01.dbo.DR_SubmitPaperwork_SP line=174 stmtstart=12912 stmtend=13018 sqlhandle=0x03000800cb72be6e500434018da000000100000000000000
12/14/2012 13:46:03,spid23s,Unknown,EXEC dbo.PB_ProcessExc_Costs_CreateInvoiceWorkTable_SP
12/14/2012 13:46:03,spid23s,Unknown,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,spid23s,Unknown,ALTER TABLE #PB_Cost_Excp_Process_Invoices_Work DROP COLUMN PBCEPrcInv_Filler
12/14/2012 13:46:03,spid23s,Unknown,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,spid23s,Unknown,executionStack
12/14/2012 13:46:03,spid23s,Unknown,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,spid23s,Unknown,process-list
12/14/2012 13:46:03,spid23s,Unknown,deadlock victim=process4cb3708
12/14/2012 13:46:03,spid23s,Unknown,deadlock-list

[〜＃〜]更新[〜＃〜]

問題のマシンは、タスクマネージャーとデバイスマネージャーに16個のプロセッサを表示しているため、ロックパーティションが有効になっており、2つのロックは異なるロックパーティションにあります。ここで、ロックパーティショニングが原因であるかどうかはわかりません。

また、 CSS SQL Serverエンジニアブログのこの興味深い投稿 も見つけました。

更新2

一時テーブルは、すべてのストアドプロシージャの最後に削除されます。これらは、パターン#create、スキーマの変更、挿入、更新、選択、およびドロップのパターンで作成されます。この一時#tableを使用する共通のプロシージャへの複数のエントリポイントがあるため、共通のプロシージャの呼び出しに必要な列を設定する中央のプロシージャがあります。それ以外の場合は、すべてのエントリポイントプロシージャで同じ#table定義を複製する必要があります。

プロセスは、複数のクライアントアプリケーションから頻繁に呼び出されます。一部のクライアントアプリケーションは、このプロセスを複数のスレッドから呼び出します。他の人は一度にそれを実行します。ホームオフィスが数千の店舗のデータを並行して処理しながら、店舗も同じプロセスを実行している在庫/会計ソフトウェアを考えてみてください。したがって、ロックパーティショニングが有効になっているときにこれがまれな問題である場合、大規模な顧客データベースではそれほどまれではありません。

更新3-2012-12-19

別のお客様がSQL Server 2012ビルド11.0.2100で同じ問題を抱えています。累積的な更新プログラムの説明に、この問題の修正に関する記述はありませんでした。研究しています。

更新4-2013-02-1

マイクロソフトは、このバグの修正を以下のアップデートでリリースしました。

sql-serversql-server-2008deadlock
18
Paul Williams

この正確な問題は SQL Server 2008 R2でロックパーティション化が有効になっている場合、一時テーブルを変更するためにストアドプロシージャを実行するとデッドロックが発生します で発表されました。 SQL Server 2008 R2 SP2の累積的な更新パッケージ4 からリンクされています。

最後に、SQL Serverの修正の説明を読んで報われました。

15
usr

この問題に関してマイクロソフトとの訴訟を起こしました。マイクロソフトはこのバグがSQL Server 2012にも影響することを確認しました。SQLServer 2012 Service Pack 2で修正をリリースする予定です（この回答を書いている時点ではリリースされていません）。

Microsoftがこのサービスパックをリリースするまで、SQL Server 2012ユーザーは トレースフラグ1229 を使用してロックパーティションを無効にすることで問題を回避できます。

この問題は、16以上のプロセッサを搭載したマシンにのみ適用されることに注意してください。

ロック分割の詳細情報

Microsoftサポートに感謝します。彼らは非常に迅速で親切でした。

更新

バグは修正されました SQL Server 2012累積更新プログラム2 for SQL Server 2012 SP 1 。

4
Paul Williams