Discussion :

[StringBuilder]

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

[escartefigue]

Possiblement la tempdb qui sature à cause de tris, regroupements ou autres opérations du même genre.

[StringBuilder]

Ok merci.

On va creuser dans cette direction.

[SQLpro]

Tout dépend du style de codage de l'application.... Si une application fait des transactions explicite, SQL Server ne verra que la requête actuellement envoyée... pas les autres. Ce n'est que si tu es dans des routines que tu aura toutes les requêtes. Ainsi dans ce type d'application, un blocage peu naître d'une requête précédente qui a déjà disparue de l'exécution, amis dont les verrous sont toujours en cours...

En gros, dans une application tu as une transaction explicite avec requête UPDATE qui pose des verrous exclusif sur T1, puis après un select sur T2 qui pose des verrous partagés sur T2, puis le COMMIT.... Tu verras donc que la dernière requête attend avec la libération des verrous de la précédente que tu n'as pus dans le cache si un autre processus la b loque par des verrous contradictoire....
Bref, il faut remonter à "avant"... par le profiler par exemple en traquant le session_id.

C'est pourquoi je préfère mille fois les procédures stockées !!!

A +