Тупики від замків на тих самих тимчасових столах у різних процесах

Я знайшов тупик, який, як видається, свідчить про те, що я вважав неможливим. У тупику задіяні два процеси:

1. process8cf948 SPID 63

Виконання ALTER TABLE у тимчасовій таблиці #PB_Cost_Excp_Process_Invoices_Work.
Володіє замком IX на таблиці #PB_Cost_Excp_Process_Invoices_Work з ідентифікатором об'єкта 455743580

2. process4cb3708 SPID 72

Виконання в UPDATE на тимчасовій таблиці #PB_Cost_Excp_Process_Invoices_Work, яка повинна бути власною унікальною копією таблиці.
Володіє замком Sch-M на #PB_Cost_Excp_Process_Invoices_Work з тим самим об'єктом ID 455743580 !

Це, мабуть, неможливо. Я щось пропускаю? Чи справді # Тимчасова таблиця була повторно використана між цими двома SPID?

Це на SQL Server 2008 R2 Service Pack 2 із накопичувальним оновленням 1 (версія 10.50.4260).

Повний незмінний слід тупику знаходиться нижче. Зверніть увагу, як обидва процеси працюють на одному ідентифікаторі об'єкта з тим самим іменем таблиці # 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 процесорів у диспетчері завдань та диспетчері пристроїв, тому розділення блокування увімкнено, а два блокування - на різних блоках блокування. Я не знаю, чи блокування розділення є причиною, що сприяє тут, чи ні.

Цю інтригуючу публікацію я знайшов і в блозі CSS SQL Server Engineers .

ОНОВЛЕННЯ 2

Тимчасові таблиці видаляються в кінці кожної збереженої процедури. Вони створені за допомогою шаблону створюють #table, змінюють схему, вставляють, оновлюють, вибирають, а потім відміняють. Існує кілька точок входу до загальної процедури, яка використовує цей temp #table, тому у нас є центральний прок, який встановлює стовпці, необхідні для виклику загального проц. Інакше нам доведеться повторити одне і те ж визначення #table у всіх документах точки введення.

Процес викликається часто з декількох клієнтських додатків. Деякі клієнтські програми викликають цей процес з декількох потоків. Інші виконують його по одному. Подумайте, програмне забезпечення для інвентаризації / бухгалтерського обліку, де домашній офіс паралельно обробляє дані для тисяч магазинів, а магазини також самі виконують той самий процес. Отож, якщо це вкрай рідкісна проблема, коли розділення блокування блокування увімкнено, воно не буде таким рідкісним у наших великих клієнтських базах даних.

ОНОВЛЕННЯ 3 - 2012-12-19

У іншого клієнта виникає такий самий випуск у версії SQL Server 2012 11.0.2100. Я не бачив жодної згадки про виправлення цієї проблеми в описах сукупного оновлення. Дослідження.

ОНОВЛЕННЯ 4 - 2013-02-13

Microsoft випустила виправлення цієї помилки в таких оновленнях:

sql-server sql-server-2008 deadlock

— Пол Вільямс
джерело

@AaronBertrand: Ні, ми не хочемо керування таблицею #temp. Це було б досить погано в тому ж самому зв’язку - тим більше, що повторне використання між процесами. У мене немає .xdl-файлу, просто прапор сліду 1222.

— Пол Вільямс

Ми явно видаляємо ці таблиці #temp, коли закінчуємо з ними.

— Пол Вільямс

Я б все-таки запропонував захопити та розмістити файл .xdl десь, щоб інші могли уважніше ознайомитись - він матиме набагато кращі деталі.

— Аарон Бертран

Я можу підтвердити, що тут включений розділ блокування. У цих публікаціях є детальна інформація про аналіз тупикових ситуацій, що стосуються та блокують розділи. bit.ly/Ruzmym bit.ly/W7yuRK Але я не знаю, чому обидва сеанси розмістили один і той же ObjectID.

— Roji P Thomas

@SQLKiwi Дякуємо, що подивились на проблему! Я не думав про хешування ресурсів блокування. Враховуючи, що він знаходиться на ідентифікаторі об'єкта, я підозрюю, що це не так, але я просто здогадуюсь. Замовник вже кілька днів повідомляє нам про тупикові місця. У мене є лише 1 день відстеження тупикової ситуації, але я думаю, що це тупик, який вони відчували. Ми відкриваємо службу підтримки з Microsoft, щоб допомогти нам розібратися. Я оновлю це питання, коли я дізнаюся більше.

— Пол Вільямс

Ми порушили справу з Microsoft щодо цієї проблеми. Microsoft підтвердила, що ця помилка впливає і на SQL Server 2012. Вони планують випустити виправлення в пакеті оновлень 2 для SQL Server 2012 (не випущений у той час, коли я писав цю відповідь).

Поки Microsoft не випустить цей пакет оновлень, користувачі SQL Server 2012 можуть обійти проблему, відключивши розділ блокування через прапор трассировки 1229 .

Зауважте, що ця проблема стосується лише машин, які мають 16 або більше процесорів.

Більше інформації про блокування розділення

Дякую за підтримку Microsoft! Вони були дуже оперативними та корисними.

ОНОВЛЕННЯ

Помилка виправлена в накопичувальному оновленнях 2 для SQL Server 2012 для SQL Server 2012 SP 1 .

— Пол Вільямс
джерело