2010-06-22 22 views
7

Hemos estado viendo este problema por un tiempo y realmente estoy tratando de entender qué lo está causando.Aplicación ASP clásica que experimenta "tiempos de espera" de SQL Server y "SQL Server no existe o acceso denegado"

Un par de veces al día veremos períodos donde las páginas web comienzan a arrojar "[Microsoft] [ODBC SQL Server Driver] Tiempo de espera expirado" y poco después las páginas comienzan a lanzar "[Microsoft] [ODBC SQL Server Driver] [ DBNETLIB] SQL Server no existe o acceso denegado ".

Tenemos muchas aplicaciones diferentes que se conectan a este servidor de base de datos. Promedia alrededor de 2500 conexiones concurrentes que procesan un promedio de 10,000 transacciones por segundo. La mayoría de nuestras aplicaciones no tienen ningún problema, los problemas solo parecen ocurrir en el servidor web. (¿Quizás está relacionado con la agrupación de conexiones?)

No sé a qué atribuir este problema. El servidor SQL en cuestión está muy sobrecargado por el trabajo que realiza y está equipado con licencias por procesador. Entonces no creo que estemos viendo un problema de licencia/rendimiento.

Pensé que tal vez había un problema de conectividad IP, así que cambié el ConnectionString para usar la dirección IP y ejecuté algunos pings de larga ejecución. Obtuve 0 paquetes perdidos entre el servidor web y el servidor de la base de datos.

La cadena de conexión ASP ahora se ve así:

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

El usuario es un usuario que no sea de dominio que conecta con la autenticación de servidor SQL. Entonces, no creo que sea un problema relacionado con el dominio. Revisé los archivos de registro del servidor SQL y no encontré nada que corresponda a los incidentes.

He encontrado another stackoverflow question siguiendo un comportamiento similar, pero sin resolución.

Los detalles:

  • Servidor Web: Windows 2003 SP2 estándar, IIS 6.
  • base de datos del servidor: Microsoft SQL Server 9.0.4035

alguien ha visto/resuelto este tipo de problema? ¿Alguien tiene alguna sugerencia sobre dónde debería mirar después?

Gracias!

-Zorlack

EDITAR

Puede alguien decirme cuál es la mejor práctica es para realizar consultas SQL en ASP alta carga clásica? ¿Queremos intentar aprovechar la agrupación de conexiones?

Al analizar el código, mucho se parece a esto:

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

solución (por el consejo de Scotte)

This article se describe, a la perfección, mi problema. Hice el cambio de registro y luego reinicié el servidor.

Problema solucionado!

+0

Gracias, tuve este problema también. Parece que la agrupación de conexiones es una amenaza. Cuando probé con y sin la agrupación de conexiones, el servidor aún creó miles de conexiones TCP en el estado TIME_WAIT. Parece que el grupo de conexiones le permite reutilizar objetos de conexión, pero a veces crean muchas conexiones TCP nuevas entre los servidores. –

Respuesta

7

¿Está su aplicación web cerrando y eliminando (configurada a nada) las conexiones de la base de datos?

Además, ¿ha intentado utilizar SQLOLEDB en lugar de ODBC? No se puede pensar en ninguna razón por la que estaría usando ODBC aquí.

aquí es mi cadena de conexión en una aplicación ASP clásico muy ocupado:

Dim strcConn 
strConn = "Provider=SQLOLEDB; Data Source=someserver; Initial Catalog=somedb; User ID=someuserid; Password=somepassword" 

Editar

me encontré con este blog. Algo interesante.

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

+1

Estas son las dos cosas que consideraría: ODBC agrega abstracción innecesaria a la conexión y no recuperar las conexiones es un problema común. – Godeke

+0

La mayoría de las veces la aplicación no configura el objeto de conexión a nada cuando termina. Mi entendimiento en ese momento era que dejar el objeto de conexión alrededor estaba bien ya que saldría del alcance cuando la página terminara de renderizarse. En ese punto, ¿no se hace cargo la agrupación de conexiones? – zorlack

+0

Ver la edición anterior – zorlack

0

Las veces que tuve este tipo de problemas, siempre tenían que hasta Con alguien que tiene los datos abiertos en una aplicación cliente sin cometer un comunicado 'seleccionar ..'.

No sé si esto resuelve su problema aquí ... aunque.

2

He resuelto este problema mediante la recreación del procedimiento almacenado.
Sólo un simple DROP y luego CREATE detuvo los tiempos de espera en mi caso!

He sufrido este problema durante una semana; un ASP clásico decía "tiempo de espera de SQL" cuando podía ejecutar la misma consulta directa en la base de datos en menos de un segundo. (No vi el mensaje "no existe"). La ASP había estado funcionando bien durante todo un mes.

Un amigo mío dijo: "Pasar por ASP utiliza un plan de ejecución 'en caché', que no es muy eficiente. Intente dejar caer y recrear. Esto sugiere que su procedimiento almacenado podría hacer con reescribir para hacerlo más eficiente, ya que podría volver a suceder ".

Como el proceso funcionaba bien cuando se probó con SQL Management Studio, supongo que no utiliza el plan en caché, pero ASP sí.

+0

¡Esta es una respuesta muy muy buena que necesita votos ascendentes! He estado trabajando con ASP durante años y nunca he tenido este problema (afortunadamente porque mis procedimientos no han causado ningún problema) ¡pero esta es una muy buena información para tener en cuenta! ¡Gracias! – Digs

+0

Si el problema es el plan en caché, puede resolverlo con menos interrupciones ordenando a SQL que reevalúe el plan en caché explícitamente: "exec sp_recompile 'MyProcedure'" Esto evita problemas con cambios inesperados de permisos. – Bruce