Deadlock da blocchi su stesse tabelle temporanee in processi diversi

Ho trovato un punto morto che sembra mostrare qualcosa che pensavo fosse impossibile. Esistono due processi coinvolti nel deadlock:

1. process8cf948 SPID 63

Esecuzione di una tabella ALTER sulla tabella temporanea #PB_Cost_Excp_Process_Invoices_Work.
Possiede il blocco IX sulla tabella #PB_Cost_Excp_Process_Invoices_Work con ID oggetto 455743580

2. process4cb3708 SPID 72

Esecuzione in UPDATE sulla tabella temporanea #PB_Cost_Excp_Process_Invoices_Work che dovrebbe essere la sua copia unica della tabella.
Possiede il blocco Sch-M su #PB_Cost_Excp_Process_Invoices_Work con lo stesso ID oggetto 455743580 !

Questo dovrebbe essere impossibile. Mi sto perdendo qualcosa? Una tabella temporanea # è stata davvero riutilizzata tra questi due SPID?

Questo è su SQL Server 2008 R2 Service Pack 2 con aggiornamento cumulativo 1 (versione 10.50.4260).

La traccia completa del deadlock inalterato è di seguito. Notare come i due processi funzionano entrambi sullo stesso ID oggetto con lo stesso nome tabella # 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

AGGIORNARE

La macchina in questione mostra 16 processori in Task Manager e Device Manager, quindi il partizionamento dei blocchi è abilitato e i due blocchi si trovano su partizioni di blocco diverse. Non so se il partizionamento di blocco è una causa che contribuisce o no qui.

Ho anche trovato questo post interessante sul blog CSS SQL Engineers Engineers .

AGGIORNAMENTO 2

Le tabelle temporanee vengono eliminate alla fine di ogni procedura memorizzata. Vengono creati con il modello creare #table, modificare lo schema, inserire, aggiornare, selezionare e quindi rilasciare. Esistono più punti di accesso a una procedura comune che utilizza questo temp #table, quindi abbiamo un proc centrale che imposta le colonne necessarie per chiamare il proc comune. Altrimenti, dovremmo replicare la stessa definizione #table in tutti i proc del punto di ingresso.

Il processo viene invocato frequentemente da più applicazioni client. Alcune applicazioni client chiamano questo processo da più thread. Altri lo eseguono uno alla volta. Pensa al software di inventario / contabilità in cui l'ufficio domestico sta elaborando i dati per migliaia di negozi in parallelo mentre anche i negozi eseguono lo stesso processo. Quindi, se questo è un problema raro quando è abilitato il partizionamento dei blocchi, non sarà così raro sui nostri database di clienti più grandi.

AGGIORNAMENTO 3 - 2012-12-19

Un altro cliente sta riscontrando lo stesso problema su SQL Server 2012 build 11.0.2100. Non ho visto alcuna menzione di una correzione per questo problema nelle descrizioni degli aggiornamenti cumulativi. La ricerca.

AGGIORNAMENTO 4 - 2013-02-13

Microsoft ha rilasciato la correzione per questo errore nei seguenti aggiornamenti:

sql-server sql-server-2008 deadlock

— Paul Williams
fonte

@AaronBertrand: No, non vogliamo la memorizzazione nella cache della tabella #temp. Sarebbe abbastanza male sulla stessa connessione, e tanto meno viene riutilizzato tra i processi. Non ho un file .xdl, solo le informazioni di flag di traccia 1222.

— Paul Williams,

Stiamo eliminando esplicitamente queste tabelle #temp una volta terminate.

— Paul Williams,

Suggerirei comunque di acquisire e pubblicare il file .xdl da qualche parte in modo che altri possano dare un'occhiata più da vicino - avrà dettagli molto migliori.

— Aaron Bertrand

Posso confermare che qui è coinvolto il partizionamento dei blocchi. Questi post contengono alcuni dettagli sull'analisi dei deadlock che coinvolgono e dovuti alle partizioni di blocco. bit.ly/Ruzmym bit.ly/W7yuRK Ma non so perché entrambe le sessioni abbiano pubblicato lo stesso ObjectID.

— Roji P Thomas,

@SQLKiwi Grazie per aver esaminato il problema! Non ho pensato di bloccare l'hash delle risorse. Dato che si trova su un ID oggetto, sospetto che non sia così, ma sto solo indovinando. Il cliente ci ha segnalato deadlock per diversi giorni. Ho solo 1 giorno di traccia del deadlock, ma scommetto che questo è il deadlock che stanno vivendo. Stiamo aprendo un ticket di supporto con Microsoft per aiutarci a capirlo. Aggiornerò questa domanda man mano che imparerò di più.

— Paul Williams,

Abbiamo aperto un caso con Microsoft su questo problema. Microsoft ha confermato che questo errore riguarda anche SQL Server 2012. Stanno pianificando di rilasciare la correzione in SQL Server 2012 Service Pack 2 (non rilasciato al momento in cui stavo scrivendo questa risposta).

Fino a quando Microsoft non rilascia questo service pack, gli utenti di SQL Server 2012 possono aggirare il problema disabilitando il partizionamento dei blocchi tramite il flag di traccia 1229 .

Si noti che questo problema si applica solo alle macchine con 16 o più processori.

Ulteriori informazioni sul partizionamento dei blocchi

I miei ringraziamenti al supporto Microsoft! Sono stati molto rapidi e disponibili.

AGGIORNARE

Il bug è stato corretto in SQL Server 2012 Cumulative Update 2 per SQL Server 2012 SP 1 .

— Paul Williams
fonte