Discussion :

[sihem_info]

bonjour a tous

Est ce que c'est normal d'avoir ce type d'erreur sur une opération du maintenance d'indexes de type réorganise

S'agit t'il d'un phénomène du deadlook et comment je peut le corriger ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Date and time: 2018-06-17 10:11:27
Command: ALTER INDEX [IX_DUPLI] ON [HN_PROD].[dbo].[PROD] REORGANIZE WITH (LOB_COMPACTION = ON)
Comment: ObjectType: Table, IndexType: NonClustered, ImageText: N/A, NewLOB: No, FileStream: N/A, ColumnStore: No, AllowPageLocks: Yes, PageCount: 4286, Fragmentation: 28.5348
Message 50000, niveau 16, ‚tat 1, serveur  prod1 , proc‚dure CommandExecute, ligne 152
Msg 1205, La transaction (ID de processus 188) a ‚t‚ bloqu‚e sur les ressources verrou par un autre processus et a ‚t‚ choisie comme victime. R‚ex‚cutez la transaction.
Outcome: Failed
Duration: 00:00:12
Date and time: 2018-06-17 10:11:39

merci pour vos aides

[Invité]

Est ce que c'est normal d'avoir ce type d'erreur sur une opération du maintenance d'indexes de type réorganise : OUI et NON. C'est sûr que ça pose un verrou sur la table, et si elle est grosse ça peut être long donc les conflits sont pas loin.

S'agit t'il d'un phénomène du deadlook OUI
comment je peux le corriger ?
Vaste question ! En tout cas, faire la maintenance d'index pendant les heures creuses est une bonne pratique.

[SQLpro]

Est ce que c'est normal d'avoir ce type d'erreur sur une opération du maintenance d'indexes de type réorganise ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

...La transaction (ID de processus 188) a été‚ bloquée sur les ressources verrou par un autre processus et a été choisie comme victime. Réexécutez la transaction.

Oui, le verrou mortel est une fatalité que l'on ne peut totalement éradiquer. Il résulte d'un interblocage qui, s'il était maintenu conduirait à une famine système et les deux processus attendraient jusqu'à la fin des temps... Il faut donc forcer l'annulation d'un des deux processus pour résoudre le nœud gordien...
C'est que fait SQL Server à travers une tache en toile de fond appelées request_for_deadlock_search...
SQL Server choisit toujours de "ROLLBACKer" le processus ayant le plus faible coût d'annulation (afin de résoudre le problème le plus vite possible).
Cependant il vous est possible de modifier ce choix en précisant, au niveau de la session, une priorité via le paramètre "DEADLOCK_PRIORITY".

Pour avoir plus d'information sur les deadlock, il faut utiliser soit une trace du profiler et demander à collecter le graphe de verrouillage, soit utiliser les événements étendu pour ce faire ou encore aller interroger la session "system health" à la recherche des verrous mortels passés.

Ensuite on aura tout loisir de comprendre l'interblocage et modifier le code ou la structure des objets afin de les minimiser.

A +