¿Cómo se borran todos los planes de consulta antiguos desde Microsoft SQL Server?

12

Tenemos una aplicación estándar que utiliza una base de datos Microsoft SQL. Dentro de esta aplicación, seleccionamos varios criterios de selección para cada informe. Esta aplicación luego ejecuta estos informes.

Creo que tenemos un problema con el plan de consulta. El primer informe que ejecutamos cada día, se ejecuta muy rápido 7 minutos. Cualquier informe que ejecutemos después del primer informe lleva más de una hora.

Cada noche ejecutamos una tarea programada que detiene e inicia el Agente SQL Server y SQL Server. Hay aproximadamente otras 25 bases de datos dentro de esta instancia de SQL Server. Ninguna otra base de datos tiene problemas de rendimiento, solo el producto estándar que mencioné anteriormente.

¿Hay alguna manera de borrar todos los planes de consulta que SQL Server tiene actualmente en la memoria?

¿Cómo puedo hacer esto sin afectar a unos 30 usuarios que dependen de otras bases de datos en el mismo servidor?

sql-server performance query

— Michael Riley - también conocido como Gunny
fuente

esto puede ayudar a dba.stackexchange.com/questions/623/full-plan-cache-behavior/…

— CoderHawk

7

Mis disculpas por mi respuesta anterior.

1) Agregue la opción WITH RECOMPILE a la instrucción CREATE PROCEDURE si sabe que su consulta variará cada vez que se ejecute desde el procedimiento almacenado. La opción WITH RECOMPILE evita la reutilización del plan de ejecución del procedimiento almacenado, por lo que SQL Server no almacena en caché un plan para este procedimiento y el procedimiento se vuelve a compilar en tiempo de ejecución. El uso de la opción WITH RECOMPILE puede aumentar el rendimiento si su consulta variará cada vez que se ejecuta desde el procedimiento almacenado porque en este caso no se utilizará el plan de ejecución incorrecto.

2) Debe crear una guía de plan que use una sugerencia de consulta USE PLAN para cada tipo de consulta (cada tipo de solicitud de procedimiento almacenado) para forzar el plan de ejecución.

Aquí hay un artículo sobre el plan de ejecución que puede ayudar.

— Garik
fuente

Estoy de acuerdo con WITH RECOMPILE, he hecho esto con los sistemas que he construido. Sin embargo, no tengo acceso a la fuente sql ... se ejecuta desde una aplicación.

— Michael Riley - También conocido como Gunny

@Cape Cod Gunny en este caso, pruebe DBCC FLUSHPROCINDB: se utiliza para borrar la memoria caché de procedimientos almacenados para una base de datos específica en un servidor SQL, no todo el servidor SQL. Es posible que desee utilizar este comando antes de probar para asegurarse de que los planes de procedimientos almacenados anteriores no afecten negativamente los resultados de las pruebas. Ejemplo: DECLARE @intDBID INTEGER SET @intDBID = (SELECT dbid FROM master.dbo.sysdatabases WHERE name = 'database_name') DBCC FLUSHPROCINDB (@intDBID)

— garik

el problema ha sido resuelto. Resultó que una tabla temporal utilizada para almacenar criterios de búsqueda había estado acumulando datos perpetuamente. Se supone que el proceso truncará los datos de esta tabla antes de recopilarlos. Gracias por el bonito fragmento de sql.

— Michael Riley - AKA Gunny

13

Hiciste dos preguntas aquí. Primero, desea saber si puede eliminar todos los planes almacenados en la memoria para una instancia de SQL. Eso se hace con DBCC FREEPROCCACHE como Matt M. sugirió.

La segunda pregunta que hizo es "¿Cómo puedo hacer esto sin afectar a más o menos 30 usuarios que dependen de otras bases de datos en el mismo servidor?". La respuesta corta es "no puedes". Si elimina todos los planes, los otros usuarios que dependen de los planes que están en la memoria probablemente sufrirán un impacto en el rendimiento.

La solución para esto requiere alguna intervención manual. Puede usar DBCC FREEPROCCACHE para eliminar planes específicos siempre que tenga el plan_handle.

Por lo que está describiendo anteriormente, suena como un problema de plan, pero no estoy seguro de que eliminar planes sea la respuesta. Te diría en la dirección de la detección de parámetros antes de pensar en eliminar planes:

http://blogs.msdn.com/b/conor_cunningham_msft/archive/2010/08/11/conor-vs-misbehaving-parameterized-queries-optimize-for-hints.aspx

Debería poder optimizar las consultas en lugar de perder el tiempo con DBCC FREEPROCCACHE de forma programada. También le aconsejaría que dedique tiempo a analizar los eventos de espera para su instancia.

— SQLRockstar
fuente

DBCC FREEPROCCACHE no resolvió el problema. Monitoree la actividad y los eventos. Hay 0 E / S físicas. Parece estar colgando de esta aplicación: .Net Sql Client Data Provider. El tipo de espera es CXPACKET.

— Michael Riley - También conocido como Gunny

CXPACKET implica que su consulta va paralela. ¿Puede determinar cuántos hilos se están ejecutando para la consulta y examinar sus esperas? Es posible que desee utilizar la herramienta gratuita de Adam Machanic WhoIsActive sqlblog.com/files/folders/release/entry29675.aspx .

— SQLRockstar

7

DBCC FREEPROCCACHE

Con este comando, puede borrar todo el caché del procedimiento en un solo comando. Definitivamente lea la documentación antes de usar este comando. Lea la sección de Comentarios algunas veces.

Borrar el caché de procedimientos hará que los cachés de procedimientos almacenados se vuelvan a compilar en el próximo uso. Esto podría afectar el rendimiento. Use con cuidado!

Mate

— Matt M
fuente

Intenté usar DBCC FREEPROCCACHE y no resolvió el problema. Terminé matando el proceso después de 1 hora.

— Michael Riley - AKA Gunny