Lock partitioning deadlocks

Question

I have a table with around 3.5 million rows. Lock partitioning [1] is enabled on the database. The table gets a lot of inserts during the day, and I'm getting a lot of deadlocks on lock partitions. These types of deadlocks are described nicely at http://sqlindian.com/2012/07/07/deadlocks-involving-lock-partitions/ but there the author says that these types of deadlocks are extremely rare. In our case they don't seem rare at all!

I could disable lock partitioning with trace flag 1229, but that's not recommended. Does anyone have some advice about how to avoid these types of deadlocks, or how I could analyze the situation further to see why we are getting so many of these "rare" type of deadlocks?

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

UPDATE: Add example deadlock graph

<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>

UPDATE 2: Adding INSERT generated by NHibernate

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

Answer 1

Assumming due diligence (ie. you did the investigation correctly), and lets make it clear we're talking about lock partitioning, not partition locking.

Unfortunately there is nothing you can do but make sure you are running the latest SP and latest CU. Preferably on latest product version. There were many fixes in this area. If you apply the latest SP and latest CU for the SP and the problem persists, contact product support.

I could disable lock partitioning with trace flag 1229, but that's not recommended

How many cores do you have? You can always try and test.

Answer 2

We had similar issues and after proper investigation, found that the main problem were some indexes created without row_lock and page_lock enabled. So any insert,update,delete operation afecting that indexes generated a X lock at table level. Concurrent operations ended as deadlocks.

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