1 votes

sql se bloque et s'arrête presque constamment

On dirait que la journée d'aujourd'hui sera encore une fois nulle. Nous avons récemment mis à jour notre boîte sql avec un monstre complet, avec des tonnes de cœurs et de mémoire vive, mais nous sommes coincés avec notre ancien schéma de base de données qui est merdique.

Notre ancienne boîte SQL avait des problèmes, mais rien de comparable à ce que nous rencontrons avec la nouvelle, bien que le jour du déploiement, elle fonctionnait super rapidement, une semaine plus tard, c'est le désordre total...

Notre application .net utilisée par quelques centaines de personnes génère un grand nombre de blocages et de dépassements de temps sur la boîte SQL et nous avons du mal à comprendre pourquoi. Nous avons vérifié tous les index et ils sont aussi bons qu'ils peuvent l'être actuellement. Certaines des principales tables sont beaucoup trop larges et comportent un nombre stupide de déclencheurs, mais il n'y a rien que nous puissions faire pour l'instant.

Beaucoup de pids semblent être les mêmes pour les mêmes utilisateurs qui essaient plusieurs fois.

Ainsi, par exemple...

User: user1
Time: 09:21
Error Message: Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

User: user1
Time: 09:22
Error Message: Transaction (Process ID 76) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

etc....

Lorsque nous avons déplacé la base de données vers la nouvelle boîte, elle a été sauvegardée à partir de l'ancienne boîte et restaurée sur la nouvelle.

Si quelqu'un a des suggestions sur ce que nous pourrions faire, je lui offrirai plusieurs pintes.

2voto

Thecamelcoder Points 11

Il s'agit davantage d'un problème de développement. Vous pouvez consulter vos développeurs pour déterminer le niveau d'isolation des transactions utilisé.

Le niveau d'isolation par défaut de Microsoft SQL Server est Read Committed. Le développeur doit connaître et définir le niveau approprié pour la transaction. Il est généralement conseillé d'utiliser le niveau d'isolation le moins restrictif possible et d'éviter d'utiliser les niveaux d'isolation Repeatable Read et Serializable si possible.

S'ils utilisent un niveau d'isolation plus restrictif que le niveau par défaut, tel que Repeatable Read ou Serializable, l'application sera davantage prédisposée aux problèmes de verrouillage. S'ils utilisent un niveau d'isolation plus restrictif que le niveau par défaut, et qu'ils n'en sont pas conscients, c'est encore pire.

La première technologie d'accès aux données de Microsoft, Entity Framework, utilise par défaut le niveau d'isolation Serializable. Cela n'est pas très bien documenté ni divulgué. Si l'application utilise Entity Framework et que le développeur n'est pas au courant de ce fait, il peut vouloir revoir la conception de la base de données pour déterminer s'il peut définir le niveau d'isolation de la transaction sur Read Committed.

Plus d'informations :

FIXER LE NIVEAU D'ISOLATION DE LA TRANSACTION (Transact-SQL)
http://msdn.microsoft.com/en-us/library/ms173763.aspx

Transactions et connexions dans Entity Framework 4.0
http://blogs.u2u.be/diederik/post/2010/06/29/Transactions-and-Connections-in-Entity-Framework-40.aspx

1voto

the-wabbit Points 40039

Il s'agit d'un outil précieux pour l'analyse de votre charge de travail, qui comprend des outils permettant d'identifier les raisons des blocages.

De nombreux articles ont été rédigés sur ce sujet, celui-ci est suffisamment complet. Les documentation officielle sur MSDN contient également des informations, même si elles ne sont pas aussi bien rédigées.

0voto

benphane Points 180

Si vous avez les bons indices, il n'y a pas de bonne façon de résoudre ce problème sans corriger le schéma de la base de données et/ou les requêtes : en particulier, tests avec SNAPSHOT ISOLATION et READ COMMITTED SNAPSHOT . Il ne s'agit pas de solutions rapides.

Si cela ne vous dérange pas de transformer la nouvelle bête en un porc lent, vous pouvez désactiver le parallélisme . On ne sait pas dans quelle mesure il sera utile.

En fin de compte, les blocages fréquents sont le résultat d'une conception inadéquate de la base de données, et il n'y a aucun moyen d'y remédier.

0voto

jgv999 Points 56

Avez-vous au moins pu enregistrer les requêtes à l'origine des problèmes ? D'après mon expérience, très peu de requêtes sont responsables de la grande majorité des problèmes.

D'après les messages d'erreur, il semble que vous exécutiez SQL Server. Si vous utilisez 2005 ou une version plus récente, activez le drapeau de trace 1222. DBCC TRACEON (1222, -1) Cela devrait vous donner des informations sur les requêtes. Un mauvais schéma peut causer des problèmes, mais je n'ai jamais vu un mauvais schéma causer directement des blocages. Il existe généralement une solution de contournement. Une requête lente est bien meilleure qu'une requête causant des blocages constants.

Faites ressortir certaines des requêtes qui interfèrent, et nous pourrons peut-être vous suggérer des modifications.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X