Interblocage / conflit de verrous (ORA-00060, 1213, 40P01)

Vous avez rencontré un interblocage (Oracle ORA-00060, MySQL 1213, PG 40P01, MSSQL 1205). Capturez le graphe, identifiez le schéma, empêchez la récidive. Les interblocages se résolvent par la conception — l'objectif est de réduire leur fréquence.

Capturez d'abord le deadlock graph

Quelles sessions (deux ou plus), quelles ressources, quels modes de verrou sont entrés en collision ? N'appliquez pas de corrections à l'aveugle sans avoir vu cela.

-- Check the trace file referenced in the alert log (deadlock graph). For history:
SELECT * FROM dba_hist_active_sess_history WHERE event LIKE 'enq: TX%' ORDER BY sample_time DESC FETCH FIRST 20 ROWS ONLY;

• J'ai le graphe — deux transactions verrouillent des ressources dans l'ordre inverse
• De nombreuses transactions s'accumulent sur une seule ligne/table (hotspot)
• Il y a des verrous de plage étendus (de nombreuses lignes sont verrouillées)

La requête qui verrouille utilise-t-elle un index ?

Sans index, un UPDATE/DELETE verrouille de nombreuses lignes (voire toute la table) pour satisfaire la clause WHERE → source d'interblocages. Vérifiez son plan.

EXPLAIN <the UPDATE/DELETE involved in the deadlock>;  -- type=ALL means a full scan, no index

• Pas d'index / elle fait un full scan
• Il y a un index, mais le conflit persiste

Cause racine : ordre de verrouillage inversé

La cause d'interblocage la plus fréquente : deux transactions accèdent aux ressources dans des ordres différents. Quand A→B et B→A se produisent en même temps, elles s'interbloquent.

Cause racine : index manquant → verrous étendus

Un UPDATE/DELETE sans index verrouille plus de lignes que nécessaire et rend les interblocages bien plus probables.

Cause racine : hotspot

De nombreuses transactions s'accumulent en même temps sur une seule ressource comme une ligne/clé de compteur.