Discussion :

[eamrf]

Bonjour,
J'ai un déclencheur sur une table dans un serveur SQL 2012. Quand j'essaie de modifier ce trigger (alter trigger ... ) ou même quand j'essaie de désactiver ce trigger, j'ai un message d'erreur "Delai de requete de verrou dépassé Erreur 1222".
Je fais un Exec sp_lock, j'ai un ObjId qui m'interroge Type=TAB Mode)Sch-S... que puis je faire ? pour identifier la cause du pb ? pour libérer ce verrou ?

[SQLpro]

Difficile de vous répondre sans voir le code de vos tables et du déclencheur.

A +

[eamrf]

C'est un trigger

Code :

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

1
2
3
ALTER TRIGGER [SYSADM].[ExportRL] 	ON  [SYSADM].[T_ITEM]
FOR UPDATE						
AS 	....

qui intercepte les update de colonne

Code :

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

1
2
3
	IF update(ID_ITEM_ORG) 
	BEGIN
....

La table a beaucoup de champs (oui je sais c'est laid !)

[SQLpro]

....

La table a beaucoup de champs (oui je sais c'est laid !)

Et c'est sans doute la cause de tous vos problèmes !

Commencez par modéliser correctement votre base et ce problème disparaitra !

A +

[eamrf]

Oui c'est certain !!

Un redemarrage du moteur peut-il libérer ce verrou ? en espérant qu'il ne réapparaisse pas ... plusieurs alter sur le declencheur ont été faits sans pb ...

[SQLpro]

On ne redémarre JAMAIS un serveur SQL. C'est la pire des imbécilité !

En aucune façon et pour quelques raisons que ce soit, une extinction des services SQL Server ou l’arrêt du serveur ou de la VM ne constitue une pratique acceptable.

En effet, l’arrêt du serveur SQL entrainent les problématiques suivantes :
1) Perte de la totalité des tables et des index mis en cache afin d’optimiser les accès aux données. Concrètement, toutes les données des tables et index devront être remontées du disque pour satisfaire les requêtes des utilisateurs, ce qui est 1000 à 10000 fois plus lent
2) Perte de la totalité des plans d’exécution des requêtes mis en cache afin d’économiser le calcul des plans de requêtes. Concrètement cela signifie que les utilisateurs devront affronter des surcroits de temps d’exécution afin que l’optimiseur recalcule ces plans puisqu’ils ont été effacés du cache.
3) Perte de la totalité des statistiques d’exécution des requêtes permettant de fournir un diagnostic de fonctionnement. Concrètement, cela ne permet plus d’investiguer dans ces statistiques et événements afin de savoir ce qui a pu se passer d’anormal dans le fonctionnement de SQL Server. De loin, ce problème est le plus critique qui soit :
a. en matière d’optimisation il est nécessaire d’avoir un recul de fonctionnement continu d’au moins 1 mois, (3 à 6 serait mieux) pour mutualiser les opérations d’amélioration à effectuer (pose de nouveaux index, de vues indexées, de colonnes calculées, récriture de requêtes….)
b. en matière de dysfonctionnement, ces statistiques permettent de comprendre ce qui a pu se passer afin de le corriger
4) Perte de certaines transactions. Lorsque l’on arrête une instance SQL Server, toutes les transactions en cours sont invalidées et un processus de ROLLBACK sera entamé au redémarrage. Problème, ce mécanisme appelé « RECOVERY » (récupération en français) peut être long, voire très long par malchance… une transaction qui est par exemple restée ouverte pendant longtemps et a fait pas mal de modifications….). Or pendant la phase de récupération, la base est inaccessible à tout utilisateur jusqu’à complète finalisation du processus… Dans le cas invoqué, il n’est pas rare que vos utilisateurs attendent plusieurs heures avant de pouvoir accéder aux données !
Comme vous n’êtes pas censé me croire, voici quelques textes qui parlent de la chose :
https://dba.stackexchange.com/questi...er-speed-it-up
https://www.sqlpassion.at/archive/20...s-a-good-idea/
https://stevestedman.com/2016/09/reboot-sql-server/

Il faut investiguer au moment du blocage via les DMV temps réel sys.dm_exec_... :

• connections
• sessions
• requests

Voir ce qui bloque et ne tuer que les processus fautifs bloquants !

A +