2009-05-27 8 views
0

Je rencontre un problème avec seulement 1 des 30 sites environ que nous utilisons sur un serveur Web W2003.Erreurs de délai d'attente SQL

probablement pour environ 25% de la journée, le site revient constamment: erreurs de délai d'attente SQL sur plusieurs connexions à SQL (via ODBC)

J'ai vérifié et mis à jour les pilotes ODBC à la dernière que je pouvais trouver (3.5.x?) Et je vérifie également le serveur SQL pour voir si cela a des problèmes (un autre serveur fonctionnant sur le même réseau connecté via Gb LAN)

Les fichiers journaux IIS renvoient "[Microsoft] [ODBC_SQL_Server_Driver] Timeout_expired"

J'ai rencontré le problème ce matin, j'ai donc essayé de redémarrer le serveur SQL pour voir s'il était un problème lié à la charge ou quelque chose - mais le site a continué à générer ces erreurs pendant environ 20 minutes après le redémarrage (même si tous nos autres sites fonctionnaient à ce stade) - puis il a cessé de temporiser et fonctionne à nouveau.

J'ai essayé d'étendre le délai d'attente des connexions SQL pour le site Web pour voir si cela a changé quelque chose, mais il ne semble pas avoir fait quelque chose.

Ce site fonctionne sans interruption depuis environ 3 ans sans problème et nous n'avons rien changé à nos serveurs depuis un certain temps - cela a commencé vers Noël, mais il est devenu de plus en plus régulier depuis.

J'ai parcouru tout le code pour m'assurer que DB Connections est ouvert/fermé correctement (Site est ASP classique), et fait en sorte qu'il n'ouvre pas trop de connexions simultanées - mais en vain et je suis commencer à manquer d'idées .... quelqu'un? Ma seule pensée est de passer à une connexion OLEDB au lieu d'un ODBC - mais avant cela, je voulais vérifier qu'il n'y avait pas quelque chose d'autre que j'ai manqué que je pourrais essayer en premier.

Merci à l'avance!

Carl.

+0

J'ai depuis installé quelques logiciels pour surveiller la performance de SQL qui m'a donné quelques informations intéressantes - mais je ne sais pas comment je peux l'utiliser efficacement .... My Seek Time Writes (Disk Wait Time, MS) semble prendre entre 60ms et 140ms - les rapports normaux sont d'environ 10-15ms. En outre, les lectures de cache (lectures logiques/lectures physiques) semblent être très mauvaises et les lectures physiques (RW par seconde) semblent être de l'ordre de 150 ms à 400 ms. À quoi cela servirait-il? Réponse sur une carte postale .... –

Répondre

0

Le plan de maintenance régulier de SQL Server est-il planifié (et en cours d'exécution), y compris la reconstruction des index?

0

Comme vous n'avez pas modifié le code, vos connexions ne présentent aucun problème.

Découvrez pourquoi les instructions SQL prennent autant de temps. C'est difficile de le dire plus simplement. Vous pouvez trouver que vous avez une situation de blocage entre votre code qui n'a pas changé, et une autre utilisation de la base de données, qui a changé. Mais vous devez aller traquer cela et ne pas toucher le code de travail qui n'a pas changé.

1

Vous mentionnez de modifier le délai d'expiration des connexions SQL, mais le délai d'expiration n'est pas clair: s'agit-il de la connexion à la base de données ou les requêtes sont-elles trop longues?

Un outil qui pourrait aider est Sql Profiler. Limitez-le à l'utilisateur ou à la base de données qui rencontre les problèmes. Si la longueur de la requête est un problème, cela devrait vous permettre de savoir exactement quelles requêtes sont en cours d'exécution.

Si la connexion elle-même expire, vérifiez l'activité actuelle dans Management Studio. Cela montre le nombre de connexions ouvertes; Si elles sont grandes, il y a probablement une fuite quelque part.Vous pouvez vérifier que dans le développement en cours d'exécution avec une chaîne de connexion qui contient:

MAX POOL SIZE=2; 

Cela entraînera des fuites d'épuiser rapidement le pool de connexion.

La suggestion de Mitch Wheat est très bonne, des statistiques inexactes peuvent vraiment détériorer les performances au fil du temps. Cette requête peut vous dire si vos statistiques sont à jour:

SELECT 
    object_name = Object_Name(ind.object_id), 
    IndexName = ind.name, 
    StatisticsDate = STATS_DATE(ind.object_id, ind.index_id) 
FROM SYS.INDEXES ind 
order by STATS_DATE(ind.object_id, ind.index_id) desc 
+0

J'ai depuis installé quelques logiciels pour surveiller la performance de SQL qui m'a donné quelques informations intéressantes - mais je ne sais pas comment je peux l'utiliser efficacement ... Mon temps de recherche (temps d'attente du disque, MS) semble prendre entre 60 ms et 140 ms - les rapports normaux se situent entre 10 et 15 ms. De plus, les lectures de cache (lectures logiques/lectures physiques) semblent être très mauvaises et les lectures physiques (RW par seconde) semblent être de l'ordre de 150ms à 400ms .... Qu'est-ce que cela veut dire? Répondez sur une carte postale .... –

+0

Vous pourriez regarder l'heure qu'un "lot d'exécution" prend. Si c'est moins de dix secondes, cela ne donne pas de délai au serveur Web. J'étudierais le nombre de connexions simultanées. – Andomar

0

Si ces choses ci-dessus ne fonctionne pas, je vérifierais votre utilisation fichier de page (PF) dans le Gestionnaire des tâches et voir où il en est. Vous pouvez obtenir des erreurs de délai d'attente de manque de mémoire virtuelle. S'il semble proche du sommet, envisagez de l'augmenter plus haut. J'ai eu beaucoup d'erreurs SQL timeout sporadiquement et dans différentes parties de mon application. Il s'est avéré que c'était un problème de performance. Je recommanderais au moins 4000mb de fichier de page en fonction de la quantité de RAM que vous avez sur votre serveur.

Questions connexes