.net - procedimientos - Gran diferencia en el tiempo de ejecución del proceso almacenado entre Managment Studio y TableAdapter

permisos para ejecutar procedimientos almacenados oracle

Question

¿Cómo podría una proposición almacenada ejecutar en 10 segundos a través de Management Studio, pero tomar 15 minutos a través de un TableAdapter para las mismas entradas? Es repetible, lo que significa que lo he ejecutado al menos tres veces en cada entorno, y Management Studio es aproximadamente 100 veces más rápido.

Estoy usando .net 2.0 y SQL Server 2000

En SQL Server Management, lo estoy ejecutando así:

EXEC    [dbo].[uspMovesReportByRouteStep]
    @RouteStep = 12000,
    @RangeBegin = N''12/28/08'',
    @RangeEnd = N''1/18/9''

En TableAdapter, estoy usando CommandType y dbo.uspMovesReportByRouteStep para CommandText . Estoy llamando al adaptador de tabla desde una página ASP.NET, aunque se agota en 30 segundos si intento también "Vista previa de datos" localmente.

No es práctico proporcionar el procedimiento almacenado porque tiene más de 100 líneas de largo con dependencias en varias otras UDF y vistas en la misma y en otras bases de datos.

Todos los demás procedimientos almacenados parecen ejecutarse casi al mismo tiempo con cualquiera de los métodos. ¿Cómo es esto posible?

Answer 1

Es muy probable que esto se deba a la "detección de parámetros" y a un plan de consulta en caché que no es apropiado para los valores particulares de los parámetros con los que lo está llamando. ¿Cómo sucede eso? Bueno, la primera vez que llame a un SP con un conjunto de valores, se generará un plan de consulta, se parametrizará y se almacenará en caché. Si se llama nuevamente al SP con otro conjunto de valores de parámetros que hubiera resultado en un plan de consulta diferente, pero usa el plan de consulta en caché, entonces el rendimiento puede verse afectado.

A menudo es porque las estadísticas están desactualizadas. Puede determinar si ese es el caso comparando el plan de ejecución estimado con el plan de ejecución real; si es diferente, las estadísticas probablemente no estén actualizadas.

Primero trataría de reconstruir los índices de la base de datos, o al menos las estadísticas actualizadas (pregunte a su DBA). Una forma de reconstruir los índices (debería funcionar en todas las versiones en SQL Server):

exec sp_msforeachtable "dbcc dbreindex (''?'')"

Si todavía es un problema, intente agregar temporalmente la declaración WITH RECOMPILE a la definición del procedimiento almacenado. Si el problema desaparece, eche un vistazo al uso de OPTIMIZE FOR , descrito en esta publicación de blog.