Sto creando un caso di prova per dimostrare un determinato scenario di deadlock e richiedere alcune informazioni su ciò che sta accadendo. Ho una tabella di heap, denominata conviventemente HeapTable. Questa tabella viene aggiornata in modo similare da 2 transazioni.
Transazione 1:
BEGIN TRAN
UPDATE HeapTable
SET FirstName = 'Dylan'
WHERE FirstName = 'Ovidiu';
WAITFOR DELAY '00:00:15';
UPDATE HeapTable
SET FirstName = 'Bob'
WHERE FirstName = 'Thierry';
ROLLBACK TRANSACTION
Transazione 2:
BEGIN TRAN
UPDATE HeapTable
SET FirstName = 'Pierre'
WHERE FirstName = 'Michael';
ROLLBACK TRAN
Spengo prima la transazione 1, seguita da vicino dalla transazione 2. Come previsto, la transazione 1 richiederà alcuni blocchi esclusivi, insieme ad alcuni intenti esclusivi. La transazione 2 entrerà e richiederà un blocco di aggiornamento sullo stesso RID:
spid dbid ObjId IndId Type Resource Mode Status
55 5 711673583 0 RID 1:24336:10 X GRANT
57 5 711673583 0 RID 1:24336:10 U WAIT
Sono stato un po 'sorpreso di vedere la seconda transazione chiedere un blocco di aggiornamento sullo stesso RID, dal momento che pensavo che questo indicasse un singolo record ed entrambe le istruzioni di aggiornamento gestiscono dati diversi. Mi aspettavo invece un conflitto a livello di pagina.
Quando il secondo aggiornamento della transazione 1 prende il via nella transazione 2 verrà visto come vittima del deadlock con conseguente rollback della transazione 2 e completamento della transazione 1.
Qualcuno può spiegarmi perché la seconda transazione richiederebbe un blocco degli aggiornamenti sullo stesso RID pur aggiornando un record diverso?
So come risolvere questo problema (ad es. Con un indice). Non sto cercando una correzione, in realtà sto cercando una spiegazione del perché 2 aggiornamenti che gestiscono record diversi in un heap vorrebbero bloccare lo stesso RID. Sto usando l'isolamento impegnato nella lettura. Non ci sono indici non cluster sulla tabella.