FYI:debe tener en cuenta algo más cuando trabaja con SQL 2005 y procesos almacenados con parámetros.
SQL Server compilará el plan de ejecución del proceso almacenado con el primer parámetro que se use. Así que si ejecutas esto:
usp_QueryMyDataByState 'Rhode Island'
El plan de ejecución funcionará mejor con los datos de un estado pequeño. Pero si alguien se da vuelta y corre:
usp_QueryMyDataByState 'Texas'
El plan de ejecución diseñado para datos del tamaño de Rhode-Island puede no ser tan eficiente con datos del tamaño de Texas. Esto puede producir resultados sorprendentes cuando se reinicia el servidor, porque el plan de ejecución recién generado estará dirigido a cualquier parámetro que se use primero, no necesariamente al mejor. El plan no se volverá a compilar hasta que haya una gran razón para hacerlo, como si se reconstruyen las estadísticas.
Aquí es donde entran en juego los planes de consulta, y SQL Server 2008 ofrece muchas características nuevas que ayudan a los administradores de bases de datos a establecer un plan de consulta en particular a largo plazo, sin importar qué parámetros se llamen primero.
Mi preocupación es que cuando reconstruyó su proceso almacenado, forzó la recompilación del plan de ejecución. Lo llamó con su parámetro favorito y, por supuesto, fue rápido, pero es posible que el problema no haya sido el proceso almacenado. Podría haber sido que el proceso almacenado se volvió a compilar en algún momento con un conjunto inusual de parámetros y, por lo tanto, un plan de consulta ineficiente. Es posible que no haya solucionado nada y que enfrente el mismo problema la próxima vez que se reinicie el servidor o se vuelva a compilar el plan de consulta.
