Bonjour,
J'ai une application qui par moment se fige, soit complètement, soit... presque complètement.
J'ai dans un premier temps identifié quelques traitements susceptibles de provoquer une surcharge anormale, voir des dead locks, notamment en lançant des transactions monstrueuses inutilement.
Cependant, maintenant que ça semble "propre", j'ai toujours des soucis de blocages.
Quand j'interroge SQL Server, il me sort des choses un peu surprenantes au niveau des verrous.
Par exemple (SID 470), un select (pas bien complexe) qui est "suspended" alors que rien ne le bloque. Il tape sur une seule table, "FI".
=> Pourquoi être suspended si rien le bloque ?
Un update (SID 387) sur cette même table FI est bloqué par le select (SID 470)
=> Bon, admettons, même si ça me semble un peu bizarre que SQL Server pose un verrou dans ce cas. En soit ça me choque pas plus que ça.
Et là, tout fout le camp : un select (SID 157) sur une autre table qui n'a rien à voir : KM est bloquée par la session SID 387. Comment un verrou dans une table peut bloquer l'accès à une autre table, alors que les requêtes ne font aucune jointure ? (et qu'il n'y a pas de FK déclarée dans la base)
Avec ce genre de blocage de plusieurs tables à la fois par des transactions qui n'ont rien à voir les unes avec les autres, j'en fini par me dire que c'est pas étonnant d'avoir des plantages avec des deadlocks...
Je soupçonne dans un premier temps une base remplie raz-la-gueule et que SQL Server mélange tout dans les pages par manque de place.
Sauf qu'il y a 15 Go de libre dans la base... Donc ça semble un peu étrange que dans ces conditions SQL Server mélange les données de plusieurs tables dans une même page (sauf si par le passé la base était pleine peut-être ?).
Bon, on reste sur cette piste de verrou de page qui impacte plusieurs tables, et je cherche une solution :
- impossible de modifier les requêtes en READ UNCOMMITED ou autre verrou optimiste : j'ai pas la main sur le code pour ajouter des hints.
- impossible aussi de forcer un verrou à la ligne qui pourrait éventuellement résoudre mon souci
Question : est-ce qu'il existe un paramètre (au niveau base de données, ou session utilisateur via la chaine de connexion ODBC ou OLEDB, ou au niveau de l'instance) qui puisse par défaut exécuter les requêtes :
- avec un verrou à la ligne
- ou/et des verrous optimistes
=> Afin de réduire l'impact des select concurrents qui actuellement se bloquent mutuellement
Aussi, je remarque des COLLATE dans les requêtes.
Sauf erreur de ma part, c'est une piste pour expliquer les ralentissements, dans la mesure où :
- le collate en lui-même est lent
- ça empêche d'utiliser un index sur la colonne lue
Sauf que j'ai beau regarder, tout est en French_CI_AS : instance, tempdb, base de données, aucune info de COLLATE différent dans le DDL des tables.
=> Du coup, faire un collate vers le même charset est-il pénalisant, ou bien SQL Server, dans sa grande sagesse, l'ignore tout bonnement lorsqu'il est inutile ?
Merci d'avance pour vos réponses
Partager