.net - utilizada - Procedimiento almacenado que causa tiempo de espera solo cuando se ejecuta desde la aplicación
qué desventajas aporta el uso de procedimientos almacenados en una base de datos (5)
Nos encontramos con un problema con una sp.
Tenemos una sp bastante simple que contiene una tabla declarada y un par de combinaciones externas que al final devuelve entre 20 y 100 filas.
Debido a que la consulta de esta sp nos ha estado brindando un rendimiento deficiente tanto en producción como en ambiente de pruebas, recientemente la hemos reescrito para que sea más eficiente y haya probado a fondo con un gran rendimiento en nuestro entorno de prueba.
Lo lanzamos a producción solo para descubrir que todavía es muy lento y está causando que nuestra aplicación .NET 2.0 agote el tiempo de espera cuando se la llama.
No entendimos nada y entramos a Management Studio en la base de datos de producción y ejecutamos el sp allí, se ejecuta menos de 1 segundo.
Es decir, cuando se ejecuta desde nuestra aplicación, es extremadamente lento y causa tiempos de espera, cuando se ejecuta desde Management Studio es muy rápido y nunca demora más de un segundo.
¿Alguien con un buen conocimiento de SQL Server 2005 nos puede dar una pista al respecto?
¿Puedes estar seguro de que no hay una situación de estancamiento? La ejecución del estudio de gestión estaría aislada, ya que a partir de la aplicación, esto podría ser parte de una transacción mayor.
Asegúrese de que su base de datos de producción tenga estadísticas actualizadas y los índices estén en buenas condiciones (si es posible, considere reconstruir los índices involucrados).
Muchas gracias por las respuestas chicos, parece que al ejecutar sp_recompile se solucionó el problema, al menos todo ha estado funcionando sin problemas desde que lo ejecuté ayer por la tarde, seguiré mirándolo y veré si se mantiene rápido.
Sin embargo, ¿no entiendo que la recompilación no se hizo cuando cambié el contenido dentro de la sp?
Creo que su problema podría ser "Parameter sniffing". Es un proceso en el que el entorno de ejecución de SQL Server "olfatea" los valores de los parámetros sp durante la compilación o recompila para generar planes de ejecución más rápidos. Pero a veces se obtiene una combinación de parámetros que junto con los datos actuales que devolverá la sp, hace una sp realmente lenta.
Hay un par de buenas explicaciones por ahí. Busque en . Este es uno es bueno: http://omnibuzz-sql.blogspot.com/2006/11/parameter-sniffing-stored-procedures.html
Una posible solución es crear variables locales en sp y establecer los valores de parámetros entrantes para ellas. Luego use solo las variables locales en la sp.
CREATE PROCEDURE [dbo].spTest
@FromDate as DATETIME
AS
BEGIN
DECLARE @FromDate_local as DATETIME
SET @FromDate_local = ''2009-01-01''
SET @FromDate_local = @FromDate
...
SELECT * FROM TestTbl WHERE FromDate >= @FromDate_local
END
Recompilar es un instrumento contundente. Lo más probable es que detecte los parámetros
Consulte esta pregunta: Fallo del procedimiento almacenado en un usuario específico