Wstawiałem dwa zestawy danych, używając minimalnego rejestrowania, do pustej tabeli sterty, używając dwóch zadań wykonywania SQL równolegle i za pomocą SQL o następującej formie.
INSERT INTO Table (TABLOCK) SELECT FROM ...
Po tym, jak zadanie trochę się zawiesiło, jedno z zadań SQL stało się ofiarą impasu. Poniżej znajduje się wyjście XML wykresu zakleszczenia.
Czy ktoś może wyjaśnić, co działo się pod maską?
<resource-list>
<objectlock lockPartition="0" objid="1586156746" subresource="FULL" dbid="7" objectname="dbo.TargetTable" id="lock7374a00" mode="IX" associatedObjectId="1586156746">
<owner-list>
<owner id="process9609dc8" mode="Sch-S"/>
<owner id="process9609dc8" mode="IX"/>
</owner-list>
<waiter-list>
<waiter id="process5e13048" mode="X" requestType="convert"/>
</waiter-list>
</objectlock>
<objectlock lockPartition="0" objid="1586156746" subresource="FULL" dbid="7" objectname="dbo.TargetTable" id="lock7374a00" mode="IX" associatedObjectId="1586156746">
<owner-list>
<owner id="process5e13048" mode="Sch-S"/>
<owner id="process5e13048" mode="IX"/>
</owner-list>
<waiter-list>
<waiter id="process9609dc8" mode="X" requestType="convert"/>
</waiter-list>
</objectlock>
</resource-list>
Sprawy stają się o wiele trudniejsze, ponieważ stwierdziłem, że w większości przypadków dwa zadania wykonywania SQL mogą działać równolegle z powodzeniem. Spróbuj poniżej:
Create table dbo.TablockInsert (c1 int, c2 int, c3 int)
--then issue the script in two Execute Sql Task in parallel you won't fail:
insert into dbo.TablockInsert(TABLOCK) SELECT 1, 1, 1
Ponieważ jedyną różnicą jest instrukcja SELECT ... FROM ..., wygląda na to, że instrukcja SELECT ... FROM ... może mieć tutaj wpływ na tryb blokady?