La consulta se agota desde la aplicación web, pero se ejecuta bien desde management studio
Esta es una pregunta que hice en otro foro que recibió algunas respuestas decentes, pero quería ver si alguien aquí tiene más información.
El problema es que una de sus páginas en una aplicación web se agota cuando llega a una llamada a un procedimiento almacenado, por lo que utiliza Sql Profiler, o los registros de seguimiento de su aplicación, para encontrar la consulta y pegarla en management studio para averiguar por qué se está ejecutando lento. Pero se ejecuta desde allí y simplemente arde a lo largo, volviendo en menos que un segundo cada vez.
Mi caso particular estaba usando ASP.NET 2.0 y Sql Server 2005, pero creo que el problema podría aplicarse a cualquier sistema RDBMS.
8 answers
Esto es lo que he aprendido hasta ahora de mi investigación.
. NET envía configuraciones de conexión que no son las mismas que obtiene al iniciar sesión en management studio. Esto es lo que verá si rastrea la conexión con Sql Profiler:
-- network protocol: TCP/IP
set quoted_identifier off
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls off
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed
Ahora estoy pegando esos ajustes encima de cada consulta que corro cuando inicié sesión en sql Server, para asegurarme de que los ajustes son los mismos.
Para este caso, probé cada configuración individualmente, después de desconectar y volver a conectar, y encontró que cambiar arithabort de apagado a encendido redujo la consulta del problema de 90 segundos a 1 segundo.
La explicación más probable está relacionada con el rastreo de parámetros, que es una técnica que Sql Server utiliza para elegir lo que cree que es el plan de consulta más efectivo. Cuando cambia una de las configuraciones de conexión, el optimizador de consultas puede elegir un plan diferente, y en este caso, aparentemente eligió uno malo.
Pero no estoy totalmente convencido de esto. He intentado comparar los planes de consulta reales después de cambiar esta configuración y aún no he visto la diferencia muestran ningún cambio.
¿Hay algo más en la configuración de arithabort que pueda hacer que una consulta se ejecute lentamente en algunos casos?
La solución parecía simple: Simplemente coloque set arithabort en la parte superior del procedimiento almacenado. Pero esto podría llevar al problema opuesto: cambiar los parámetros de consulta y de repente se ejecuta más rápido con ' off ' que 'on'.
Por el momento estoy ejecutando el procedimiento 'con recompile' para asegurarse de que el plan se regenera cada vez. Está bien para este informe en particular, ya que toma tal vez un segundo para recompilar, y esto no es demasiado notable en un informe que tarda 1-10 segundos en regresar (es un monstruo).
Pero no es una opción para otras consultas que se ejecutan con mucha más frecuencia y necesitan regresar lo más rápido posible, en solo unos pocos milisegundos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-04-04 14:38:01
He tenido problemas similares. Intente configurar la opción con "CON RECOMPILAR" en el sproc create para forzar al sistema a volver a calcular el plan de ejecución cada vez que se llame. A veces, el procesador de consultas se confunde en procedimientos almacenados complejos con muchas ramificaciones o sentencias de casos y simplemente extrae un plan de ejecución realmente subóptimo. Si eso parece "solucionar" el problema, probablemente necesitará verificar que las estadísticas estén actualizadas y/o desglosar el sproc.
También puedes confirme esto perfilando el sproc. Cuando lo ejecuta desde SQL Managment Studio, ¿cómo se compara la IO con cuando lo perfila desde el ASP.NET solicitud. Si muy mucho, solo refuerza que está tirando de un mal plan de ejecución.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-11-01 18:01:36
¿Te has encendido? ASP.NET ¿ya rastreaste? He tenido una instancia en la que no fue el procedimiento almacenado SQL en sí el problema, fue el hecho de que el procedimiento devolvió 5000 filas y la aplicación estaba tratando de crear ListItems de base de datos con esos 5000 elementos que estaba causando el problema.
Usted podría mirar en los tiempos de ejecución entre las funciones de la aplicación web, así como a través de la pista para ayudar a rastrear las cosas.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-08-13 18:22:10
Pruebe esto en un cuadro de ensayo primero, cámbielo a nivel de servidor para sql server
Declare @option int
Set @option = @@options / 64
Exec sp_configure 'opciones de usuario', @opción
RECONFIGURAR
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-08-13 16:19:24
El mismo problema que tuve con SQL reporting services. Intente comprobar el tipo de variables, Estaba enviando un tipo diferente de variable a SQL como enviar varchar en el lugar donde debería ser entero, o algo así. Después de sincronizar los tipos de variables en Reporting Service y en stored procedure en SQL, resolví el problema.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-03-15 06:59:08
Intente cambiar el valor de tiempo de espera SelectCommand:
DataAdapter.SelectCommand.CommandTimeout = 120;
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-08-13 15:52:35
Podría intentar usar el comando sp_who2 para ver qué proceso en cuestión está haciendo. Esto le mostrará si está bloqueado por otro proceso, o si consume una cantidad excesiva de tiempo de cpu y/o e / s.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-09-09 01:35:47
Tuvimos el mismo problema y esto es lo que descubrimos.
El tamaño de registro de nuestra base de datos se mantenía en el valor predeterminado (814 MB) y el crecimiento automático era del 10%. En el servidor, la memoria máxima del servidor también se mantuvo en la configuración predeterminada (2147483647 MB).
Cuando nuestro registro se llenó y necesitó crecer, usó toda la memoria del servidor y no quedó nada para que se ejecutara el código, por lo que se agotó el tiempo. Lo que terminamos haciendo fue establecer el tamaño inicial del archivo de registro de la base de datos a 1 MB y el servidor máximo memoria a 2048 MB. Esto solucionó instantáneamente nuestro problema. Por supuesto, puede cambiar estas dos propiedades para adaptarse a su necesidad, pero esta es una idea para alguien que se encuentra con el problema de tiempo de espera al ejecutar un procedimiento almacenado a través de código, pero se ejecuta muy rápido en SSMS y las soluciones anteriores no ayudan.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-11-25 18:02:38