Al comparar el tiempo de ejecución de dos consultas diferentes, es importante borrar el caché para asegurarse de que la ejecución de la primera consulta no altera el rendimiento de la segunda.
En una Búsqueda de Google, pude encontrar estos comandos:
DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHEDe hecho, mis consultas están tardando más en completarse después de varias ejecuciones que antes. Sin embargo, no estoy seguro de que esta sea la técnica recomendada.
¿Cuál es la mejor práctica?
sql-server
performance-testing
andrerpena
fuente
fuente
DBCC FLUSHPROCINDB: Se proporcionó un número incorrecto de parámetros a la instrucción DBCC.DECLARE @myDb AS INT = DB_ID(); DBCC FLUSHPROCINDB(@myDb); GOdesde aquí: stackoverflow.com/questions/7962789/…Respuesta tardía pero puede ser útil para otros lectores
DBCC DROPCLEANBUFFERS es un comando de uso frecuente para probar consultas y medir la velocidad de ejecución de consultas. Este comando (cuando se ejecuta) deja solo las páginas sucias, que en realidad son una pequeña porción de datos. Elimina todas las páginas limpias para un servidor completo.
Tenga en cuenta que este comando no debe ejecutarse en un entorno de producción. La ejecución de este comando dará como resultado una memoria caché de búfer en su mayoría vacía. Al ejecutar cualquier consulta después de ejecutar el comando DBCC DROPCLEANBUFFERS, se usarán lecturas físicas para devolver los datos a la memoria caché, lo que probablemente será mucho más lento que la memoria.
Nuevamente, trate este comando de manera similar a DBCC FREEPROCCACHE: no debe ejecutarse en ningún servidor de producción a menos que sepa absolutamente lo que está haciendo.
Esta puede ser una herramienta de desarrollo útil porque puede ejecutar una consulta en un entorno de prueba de rendimiento una y otra vez sin ningún cambio en la velocidad / eficiencia debido al almacenamiento en caché de los datos en la memoria.
Obtenga más información en: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/
fuente
Siempre me dijeron que usara:
De MSDN :
fuente
DBCC FREEPROCCACHEpara borrar los planes de ejecución en caché ...Las otras respuestas son correctas sobre las razones para no ejecutar
DBCC FREEPROCCACHE. Sin embargo, también hay un par de razones para hacerlo:Si desea comparar dos consultas o procedimientos diferentes que intentan hacer lo mismo de diferentes maneras, es probable que lleguen a las mismas páginas. Si ingenuamente ejecuta la consulta # 1 y luego la consulta # 2, la segunda puede ser mucho más rápida simplemente porque esas páginas fueron almacenadas en caché por la primera consulta. Si borra el caché antes de cada ejecución, comienzan de manera uniforme.
Si desea probar el rendimiento de la caché en caliente, asegúrese de ejecutar las consultas varias veces, alternando, y descarte las primeras ejecuciones. Promedio de los resultados.
Supongamos que tiene una consulta que demora un segundo en un caché activo pero un minuto en un caché frío. Una optimización que hace que la consulta en memoria sea un 20% más lenta pero la consulta vinculada a IO un 20% más rápida podría ser una gran victoria: durante las operaciones normales, nadie notará los 200 ms adicionales en circunstancias normales, pero si algo obliga a una consulta a ejecutar contra disco, tomar 48 segundos en lugar de 60 podría ahorrar una venta.
Esto es menos preocupante en los sistemas modernos con decenas de gigabytes de memoria y almacenamiento relativamente rápido de SAN y SSD, pero todavía es importante. Si algún analista ejecuta una consulta de escaneo de tabla masiva contra su base de datos OLTP que borra la mitad de su caché de búfer, las consultas de almacenamiento eficiente lo pondrán nuevamente en marcha más rápido.
fuente