Vuelva a ejecutar un plan de consulta real específico

He capturado un plan de consulta real para una consulta específica.

Después de esto, he cambiado algunas cosas (incluida la actualización de las estadísticas) y volví a ejecutar esa consulta específica. Ahora el plan de consulta real es diferente (lo cual tiene sentido).

La consulta ahora se ejecuta mucho más rápido. Tengo curiosidad por saber si el nuevo plan de ejecución tiene algo que ver con esto, porque otros cambios (cambios en la configuración de E / S, configuración de VM, reinicio de instancia de SQL, etc.) también pueden estar causando una mejora en el rendimiento. Para probar esto, me gustaría ejecutar la consulta una vez más e intentar forzar a SQL Server a usar el plan de ejecución anterior.

Pregunta : ¿hay alguna manera de volver a ejecutar una consulta con un plan de ejecución proporcionado por el usuario, o incluso ejecutar una consulta directamente desde dicho plan?

Esto es lo que he intentado resolver:

He buscado en los libros que tenemos disponibles en la oficina ( Professional SQL Server 2012 Internals and Solución de problemas , Consulta de Microsoft SQL Server 2012 );
Búsquedas en Google, por ejemplo, "ejecutar consulta basada en un plan de consulta específico"
DBA.SE busca, por ejemplo, "ejecutar plan de consulta" y "volver a ejecutar plan de ejecución"
Y finalmente, una que ha respondido mis preguntas muchas veces antes: marque cuidadosamente "Preguntas que ya pueden tener su respuesta" antes de presionar "Publique su pregunta" :-)

En resumen: ¿es esto posible? ¿Si es así, cómo?

sql-server sql-server-2012 execution-plan

— Jeroen
fuente

He utilizado lo siguiente para verificar consultas de ejecución larga y corta en mis sistemas de desarrollo y prueba. Borre los planes existentes, las memorias intermedias, las memorias caché y ejecute las consultas con el seguimiento activado. Uso de funciones de caída / liberación de dbcc para borrar la sesión, caché, búferes, etc. y desactivar o desactivar el seguimiento. Sin relación pero útil, es ver cuál es el trato con los datos en la tabla. Tenga en cuenta que vi que estaba usando S2K12, por lo que estas referencias deberían coincidir. El comportamiento puede diferir en versiones anteriores de SQL Server. Espero que esto ayude. DBCC FREESYSTEMCACHE, DROPCLEANBUFFERS, Trace On, show_statistics, etc.

— Ray Porrata

Si.

Necesitas la USE PLANpista.

En el que se suministra XMLdesde el primer plan.

SELECT *
FROM T
OPTION (USE PLAN N'<?xml version="1.0" encoding="utf-16"?> ....')

Si bien no garantiza que el plan sea exactamente el mismo (por ejemplo, los operadores escalares de cómputo pueden moverse, por ejemplo), es probable que esté bastante cerca.

— Martin Smith
fuente

Gracias, exactamente lo que estaba pidiendo. (Desafortunadamente, me deja con un nuevo problema: " No se pudo encontrar un plan de consulta porque el optimizador excedió el número de operaciones permitidas al buscar el plan especificado en la sugerencia USE PLAN ", pero supongo que ese es otro problema que tratar).

— Jeroen

@Jeroen - Hmmm. No estoy seguro si hay alguna solución para eso. Tal vez haya alguna marca de seguimiento que aumentaría ese límite, pero si existe, ¡no lo sé!

— Martin Smith

No hay problema, gracias por su ayuda en cualquier caso: ¡aprendí algo nuevo hoy! : D

— Jeroen

@Jeroen: ¿Tal vez el TF 8780 no documentado que deshabilita los tiempos de espera del optimizador ? No estoy seguro si eso tendría el efecto deseado.

— Martin Smith