3

約 350 万行のテーブルがあります。データベースでロック パーティショニング [1] が有効になっています。テーブルは 1 日の間に多くの挿入を取得し、ロック パーティションで多くのデッドロックが発生しています。これらのタイプのデッドロックは、http: //sqlindian.com/2012/07/07/deadlocks-involving-lock-partitions/ で適切に説明されていますが、著者は、これらのタイプのデッドロックは非常にまれであると述べています。私たちの場合、それらはまったく珍しいものではないようです!

トレース フラグ 1229 を使用してロック パーティショニングを無効にすることもできますが、これはお勧めできません。これらのタイプのデッドロックを回避する方法、または状況をさらに分析して、これらの「まれな」タイプのデッドロックが非常に多く発生する理由を確認する方法について、誰かアドバイスはありますか?

[1] http://msdn.microsoft.com/en-us/library/ms187504(v=sql.105).aspx

更新: デッドロック グラフの例を追加

<deadlock>
  <victim-list>
    <victimProcess id="process5004748" />
  </victim-list>
  <process-list>
    <process id="process5004748" taskpriority="0" logused="0" waitresource="OBJECT: 5:1423344135:0 " waittime="3008" ownerId="2379819613" transactionname="user_transaction" lasttranstarted="2013-03-14T09:28:55.803" XDES="0x77ab8f950" lockMode="X" schedulerid="11" kpid="5416" status="suspended" spid="507" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2013-03-14T09:28:55.817" lastbatchcompleted="2013-03-14T09:28:55.807" clientapp=".Net SqlClient Data Provider" hostname="ExampleHost" hostpid="8664" loginname="ExampleUser" isolationlevel="read uncommitted (1)" xactid="2379819613" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
      <executionStack>
        <frame procname="" line="1" stmtstart="616" stmtend="1504" sqlhandle="0x020000002468011b993c824e2e0ce3fd2783a30e8e591641" />
        <frame procname="" line="1" sqlhandle="0x000000000000000000000000000000000000000000000000" />
      </executionStack>
      <inputbuf>
(@p0 datetime,@p1 bigint ...) INSERT INTO tblExample (Column1, Column2, ...); select SCOPE_IDENTITY()   
      </inputbuf>
    </process>
    <process id="processd4a988" taskpriority="0" logused="0" waitresource="OBJECT: 5:1423344135:10 " waittime="3008" ownerId="2379819595" transactionname="user_transaction" lasttranstarted="2013-03-14T09:28:55.663" XDES="0x2fe4323b0" lockMode="X" schedulerid="2" kpid="6756" status="suspended" spid="473" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2013-03-14T09:28:55.677" lastbatchcompleted="2013-03-14T09:28:55.667" clientapp=".Net SqlClient Data Provider" hostname="ExampleHost" hostpid="8664" loginname="ExampleUser" isolationlevel="read uncommitted (1)" xactid="2379819595" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
      <executionStack>
        <frame procname="" line="1" stmtstart="616" stmtend="1504" sqlhandle="0x020000002468011b993c824e2e0ce3fd2783a30e8e591641" />
        <frame procname="" line="1" sqlhandle="0x000000000000000000000000000000000000000000000000" />
      </executionStack>
      <inputbuf>
        (@p0 datetime,@p1 bigint ...) INSERT INTO tblExample (Column1, Column2, ...); select SCOPE_IDENTITY()
      </process>
  </process-list>
  <resource-list>
    <objectlock lockPartition="0" objid="1423344135" subresource="FULL" dbid="5" objectname="" id="lock5d745ae00" mode="X" associatedObjectId="1423344135">
      <owner-list>
        <owner id="processd4a988" mode="X" />
      </owner-list>
      <waiter-list>
        <waiter id="process5004748" mode="X" requestType="wait" />
      </waiter-list>
    </objectlock>
    <objectlock lockPartition="10" objid="1423344135" subresource="FULL" dbid="5" objectname="" id="lock55da8ea00" mode="IX" associatedObjectId="1423344135">
      <owner-list>
        <owner id="process5004748" mode="IX" />
      </owner-list>
      <waiter-list>
        <waiter id="processd4a988" mode="X" requestType="wait" />
      </waiter-list>
    </objectlock>
  </resource-list>
</deadlock>

更新 2: NHibernate によって生成された INSERT の追加

begin transaction with isolation level: ReadUncommitted

INSERT INTO tblExample
            (Column1,
             Column2,
             Column2,
             Column3,
             Column4,
             Column5,
             Column6,
             Column7,
             Column8,
             Column9,
             Column10,
             Column11,
             Column12,
             Column13,
             Column14,
             Column15,
             Column16,
             Column17,
             Column18,
             Column19,
             Column20,
             Column21)
VALUES      ('2013-03-14T12:47:26.00' /* @p0 */,
             NULL /* @p1 */,
             75 /* @p2 */,
             'Test Text with some characters' /* @p3 */,
             'Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22' /* @p4 */,
             2130706433 /* @p5 */,
             NULL /* @p6 */,
             NULL /* @p7 */,
             0 /* @p8 */,
             'Test Title' /* @p9 */,
             '11223344' /* @p10 */,
             0 /* @p11 */,
             '2013-03-14T12:47:26.00' /* @p12 */,
             0 /* @p13 */,
             '2013-03-14T12:47:26.00' /* @p14 */,
             'en' /* @p15 */,
             '2013-03-14T12:47:26.00' /* @p16 */,
             0 /* @p17 */,
             'SomeName' /* @p18 */,
             NULL /* @p19 */,
             917278 /* @p20 */,
             2805683 /* @p21 */);



select SCOPE_IDENTITY()

commit transaction
4

2 に答える 2

3

デューデリジェンスを前提として（つまり、調査を正しく行った）、パーティションロックではなくロックパーティションについて話していることを明確にしましょう。

残念ながら、できることは何もありませんが、最新の SP と最新の CU を実行していることを確認してください。できれば最新の製品バージョンで。この分野では多くの修正が行われました。SP に最新の SP と最新の CU を適用しても問題が解決しない場合は、製品サポートにお問い合わせください。

トレース フラグ 1229 を使用してロック パーティショニングを無効にすることもできますが、それはお勧めしません

コアはいくつありますか？いつでも試してテストできます。

于 2013-03-14T10:14:34.960 に答える
1

同様の問題があり、適切な調査の結果、主な問題は、row_lock と page_lock を有効にせずに作成されたいくつかのインデックスであることがわかりました。そのため、そのインデックスに影響を与える挿入、更新、削除操作により、テーブル レベルで X ロックが生成されました。並行操作はデッドロックとして終了しました。

SELECT name indexname,allow_row_locks,allow_page_locks
FROM sys.indexes
WHERE 1=1 
--and object_id = object_id('tablename') 
AND allow_row_locks = 0 
AND allow_page_locks = 0
于 2016-10-04T11:33:27.737 に答える