Ho un problema di deadlock con due transazioni che non accedono a nessun record comune. Non c'è anche l'escalation del blocco. Quindi non posso spiegare perché è possibile un deadlock.SqlServer 2005: problema di deadlock senza record condivisi
Il deadlock si verifica quando due tali operazioni vengono eseguite contemporaneamente:
begin transaction
update A set [value] = [value]
where id = 1; /* resp. 2 */
/* synchronize transactions here */
SELECT *
FROM
A inner join B on A.B_FK = B.id
inner join C on C.A_FK = A.id
WHERE
A.[value] = 1; /* resp. 2 */
rollback;
Queste sono le tabelle ei dati per configurare lo scenario:
CREATE TABLE A (
id INT NOT NULL,
[value] INT,
B_FK INT
primary key (id)
)
CREATE TABLE B (
id INT NOT NULL,
primary key (id)
)
CREATE TABLE C (
id INT NOT NULL,
A_FK INT
primary key (id)
)
INSERT INTO A VALUES(1, 1, 1)
INSERT INTO B VALUES(1)
INSERT INTO C VALUES(1, 1)
INSERT INTO A VALUES(2, 2, 2)
INSERT INTO B VALUES(2)
INSERT INTO C VALUES(2, 2)
Tabella A è nel bel mezzo di tre tavoli. Se cambio qualcosa nella query, ad esempio rimuovi una delle tabelle unite B o C, non esiste un deadlock. Lo stesso quando filtro da A.id anziché da A.value.
Il grafico di deadlock indica che entrambi desiderano impostare un blocco S sull'indice della chiave primaria della tabella A. Ancora: non c'è un'escalation di blocco.
sto usando SqlServer 2005.
- Perché queste operazioni in conflitto senza alcun accesso ai dati comuni? Qualcuno può spiegarlo?
- Cosa posso fare per evitarlo? Sto usando NHibernate e non posso cambiare facilmente la query.
- Potrebbe trattarsi di un problema SqlServer?
Grazie mille.
cosa significa "/ * sincronizzazione transazioni qui * /" significa? –
@Mitch: significa che eseguo la transazione 1 fino a questo punto, quindi eseguo la transazione 2, che attende sulla selezione, quindi eseguo la transazione 1 fino alla fine, che attende anche la selezione. –