sp3 - sql server 2017
La consulta se agota desde la aplicación web pero funciona bien desde el estudio de administración (8)
¿Ya has activado el rastreo de ASP.NET? Tuve una instancia en la que no era el procedimiento almacenado SQL el problema, era el hecho de que el procedimiento devolvió 5000 filas y la aplicación intentaba crear elementos de lista vinculados con los 5000 elementos que causaban el problema.
También puede consultar los tiempos de ejecución entre las funciones de la aplicación web a través del seguimiento para ayudar a rastrear las cosas.
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 tiene una de sus páginas en una aplicación web que se agota cuando se trata de una llamada de procedimiento almacenado, por lo que usa Sql Profiler, o los registros de seguimiento de la aplicación, para encontrar la consulta y pegarla en el estudio de administración para calcular nuestro por qué está funcionando lento. Pero lo ejecutas desde allí y sigue ardiendo, volviendo en menos de un segundo cada vez.
Mi caso particular fue el uso de ASP.NET 2.0 y Sql Server 2005, pero creo que el problema podría aplicarse a cualquier sistema RDBMS.
Pruebe a cambiar el valor de tiempo de espera SelectCommand:
DataAdapter.SelectCommand.CommandTimeout = 120;
pruébelo primero en una caja de transición, cámbielo en un servidor para el servidor sql
declare @option int
establecer @option = @@ opciones | 64
exec sp_configure ''opciones de usuario'', @option
RECONFIGURA
Podría intentar usar el comando sp_who2 para ver qué proceso está haciendo. Esto le mostrará si está bloqueado por otro proceso o si usa una cantidad excesiva de CPU y / o tiempo.
He tenido problemas similares. Intente configurar la opción "WITH RECOMPILE" en sproc create para forzar al sistema a volver a calcular el plan de ejecución cada vez que se llame. Algunas veces, el procesador de Query se confunde en complejos procedimientos almacenados con muchas ramificaciones o declaraciones de casos y simplemente extrae un plan de ejecución realmente poco óptimo. Si eso parece "arreglar" el problema, probablemente necesite verificar que las estadísticas estén actualizadas y / o desglosar el sproc.
También puede confirmar esto mediante el perfil del sproc. Cuando lo ejecuta desde SQL Managment Studio, ¿cómo se compara el IO con cuando lo perfila desde la aplicación ASP.NET? Si lo hacen mucho, solo refuerza que está tirando de un mal plan de ejecución.
Mismo problema que tuve con los servicios de informes de SQL. 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 el procedimiento almacenado en SQL, resolví el problema.
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 las que obtiene cuando inicia sesión en Management Studio. Esto es lo que verá si olfatea 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 ejecuto cuando estoy conectado al servidor sql, para asegurarme de que la configuración sea la misma.
En este caso, probé cada ajuste individualmente, después de desconectar y volver a conectar, y descubrí que cambiar arithabort de apagado a encendido reducía la consulta de problemas 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, al parecer eligió uno malo.
Pero no estoy totalmente convencido de esto. Intenté comparar los planes de consulta reales después de cambiar esta configuración y aún no he visto el diff mostrar ningún cambio.
¿Hay algo más sobre la configuración de arithabort que podría ocasionar que una consulta se ejecute lentamente en algunos casos?
La solución parecía simple: simplemente pon el set arithabort en la parte superior del procedimiento almacenado. Pero esto podría conducir al problema opuesto: cambiar los parámetros de consulta y de repente se ejecuta más rápido con ''apagado'' que ''encendido''.
Por el momento estoy ejecutando el procedimiento ''con recompilación'' para asegurarme de que el plan se regenere cada vez. Está bien para este informe en particular, ya que lleva aproximadamente un segundo recompilar, y esto no es demasiado notorio en un informe que demora de 1 a 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.
Tuvimos el mismo problema y esto es lo que descubrimos.
nuestro tamaño de registro de base de datos se mantuvo en el valor predeterminado (814 MB) y el crecimiento automático fue del 10%. En el servidor, la memoria máxima del servidor también se mantuvo en la configuración predeterminada (2147483647 MB).
Cuando nuestro log se llenó y necesitaba crecer, utilizó toda la memoria del servidor y no queda nada para ejecutar el código, por lo que se agotó el tiempo de espera. Lo que terminamos haciendo fue establecer el tamaño inicial del archivo de registro de la base de datos a 1 MB y la memoria máxima del servidor a 2048 MB. Esto solucionó nuestro problema al instante. Por supuesto, puede cambiar estas dos propiedades para que se ajusten a sus necesidades, pero esta es una idea para alguien que está teniendo problemas de tiempo cuando ejecuta un procedimiento almacenado a través de un código pero funciona muy rápido en SSMS y las soluciones anteriores no ayudan.