ASP classique application connaît SQL Server “délais d'attente” et “SQL Server n'existe pas ou accès refusé”

Nous avons été voir à ce problème pour un certain temps maintenant et je suis vraiment d'essayer d'envelopper ma tête autour de ce qui en est la cause.

Une couple de fois par jour, nous allons voir les périodes où les pages web de commencer à jeter "[Microsoft][ODBC SQL Server Driver]Délai d'attente expiré", puis peu de temps après, les pages se lancer des "[Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server n'existe pas ou son accès est refusé."

Nous avons beaucoup de différentes applications qui se connectent à ce serveur de base de données. Il est en moyenne autour de 2 500 connexions simultanées de traitement en moyenne 10 000 transactions par seconde. La plupart de nos demandes n'ont pas de problèmes que ce soit, les problèmes semblent seulement d'arriver sur le serveur web. (Peut-être que c'est lié à la connexion de mise en commun?)

Je ne suis pas sûr de ce que d'attribuer ce problème. Le serveur SQL en question est largement maîtrisé pour le travail qu'il fait, et est équipé de licence par processeur. Donc, je ne pense pas que nous sommes à la recherche à une licence/problème de performance.

J'ai pensé que peut-être il y avait un problème de connectivité IP, alors j'ai changé la ConnectionString pour utiliser l'adresse IP et de couru quelques longue pings. Je me suis 0 paquets perdus entre le serveur Web et le serveur de Base de données.

L'ASP chaîne de connexion ressemble maintenant à ceci:

Provider=MSDASQL; Driver={SQL Server}; Server=10.0.100.100; Database=DBName; UID=WebUserName; PWD=WebUserPassword; ConnectionTimeout=15; CommandTimeout=120;

L'utilisateur est un non-utilisateur domaine de connexion utilisant l'authentification Sql Server. Donc je ne pense pas que c'est un domaine lié à la question. J'ai vérifié le journal de SQL server fichiers et n'avons rien trouvé qui que ce soit correspondant à ces incidents.

J'ai trouvé une autre question stackoverflow décrivant un comportement similaire, mais sans résolution.

Les Détails:

Web Serveur: Windows 2003 SP2, IIS 6.
Serveur de base de données: Microsoft SQL Server 9.0.4035

Quelqu'un a vu/résolu ce type de problème? Quelqu'un aurait-il des suggestions à l'endroit où je dois chercher la prochaine?

Merci!

-Zorlack

MODIFIER

Quelqu'un peut-il me dire quelle est la meilleure pratique consiste pour l'exécution de requêtes sql en classique à charge élevée asp? Voulons-nous essayer de tirer parti de regroupement de connexion?

En regardant le code, beaucoup ressemble à ceci:

Set objCn = Server.CreateObject("ADODB.Connection") 
objCn.Open(Application("RoConnStr"))
'do some stuff
objCn.Close
Set objCn = Nothing

Solution (par ScottE conseils)

Cet article décrit, à un tee-shirt, mon problème. J'ai fait le changement de registre et ensuite redémarré le serveur.

Problème Résolu!

Merci, j'ai eu ce problème aussi. On dirait le regroupement de connexion est un leurre. Quand je l'ai testé avec et sans regroupement de connexion, le serveur toujours créé des milliers de connexions TCP en état TIME_WAIT. Il semble que le pool de connexion vous permet de ré-utiliser les objets de connexion, mais il s'agit parfois de créer de nombreuses nouvelles connexions TCP entre les serveurs.

OriginalL'auteur zorlack | 2010-06-22

7

Est votre web app de la fermeture et de l'élimination (rien), de connexions de base de données?

Aussi, avez-vous essayé d'utiliser SQLOLEDB au lieu de ODBC? Peut pas penser à une raison pourquoi vous seriez à l'aide de ODBC ici.

voici ma chaîne de connexion sur un de très occupé asp classique application:
```
Dim strcConn
strConn = "Provider=SQLOLEDB; Data Source=someserver; Initial Catalog=somedb; User ID=someuserid; Password=somepassword"
```
Modifier

Je suis tombé sur ce blogue. Plutôt intéressant.

http://www.ryanbutcher.com/2006/02/classic-asp-on-2003-server-with.html

Ce sont les deux choses que je regarde: ODBC ajoute inutilement de l'abstraction à la connexion et à défaut de récupérer des connexions est un problème commun.
La plupart du temps, l'application ne permet pas de définir l'objet de connexion à rien lorsque vous avez terminé. Ma compréhension était à l'époque qu'en quittant l'objet de connexion est ok car il serait hors de portée quand la page a fini de rendre. À ce point de ne pas le regroupement de connexion?
Voir l'édition ci-dessus
la configuration de la connexion de l'objet = rien n'est plus une mémoire des bonnes pratiques de gestion de l'asp classique.

OriginalL'auteur ScottE
2

, J'ai résolu ce problème en recréant la procédure stockée!

Juste un simple DROP et puis CREATE arrêté les délais d'attente dans mon cas!

J'ai souffert de ce problème pour une semaine; un classique ASP dit "SQL timeout" quand je pouvais exécuter la même requête directe sur la base de données en moins d'une seconde. (Je n'ai pas vu le "n'existe pas" message.) L'ASP a très bien marché pendant un mois entier.

Un génie de mes amis a dit, "Allez par le biais de l'ASP utilise une mise en cache de l'exécution du plan, qui n'est pas très efficace. Essayez de laisser tomber et de recréer. Cela suggère votre procédure stockée pourrait le faire avec la ré-écriture pour la rendre plus efficace, car il pourrait se produire de nouveau."

Depuis le proc a été en cours d'exécution fine lorsqu'il est testé avec SQL Management Studio, je suppose que ça n'a pas utilisé le plan de mise en cache, mais l'ASP n'.

C'est une très très très bonne réponse qui doit upvotes! Travaillé avec l'ASP depuis des années et n'ont jamais touché à ce problème (heureusement parce que mon procédures n'ont pas causé de problème), mais c'est une très bonne info à garder à l'esprit! Merci!
Si le plan de mise en cache est le problème, vous pouvez résoudre ce avec moins d'interruption par le commandant de SQL pour réévaluer le plan de mise en cache de manière explicite: "exec sp_recompile 'Maprocédure' " Cela évite les problèmes liés à des changements inattendus des autorisations.

OriginalL'auteur Magnus Smith
0

La fois, j'ai eu de tels problèmes, a toujours eu pour pour avec quelqu'un qui tient les données de l'ouvrir dans une application client sans avoir commis un 'select' .. déclaration.

Ne sais pas si cela résout votre problème ici... quoique.

OriginalL'auteur Edelcom

Vous devez vous connecter pour publier un commentaire.