Comandos de SQL Server para borrar cachés antes de ejecutar una comparación de rendimiento

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 FREEPROCCACHE

De 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?

Personalmente, para una consulta común, la segunda ejecución y las posteriores son más importantes.

¿Está probando el disco IO o el rendimiento de la consulta?

Suponiendo que su consulta se ejecuta con frecuencia y es crítica, entonces desea medir eso en condiciones de la vida real. Y no desea borrar las memorias caché del servidor de productos cada vez ...

Si tu quieres tu puedes:

• DBCC DROPCLEANBUFFERSborra las páginas limpias (no modificadas) del grupo de búferes.
  Preceda eso con un CHECKPOINTpara vaciar primero las páginas sucias al disco
• DBCC FLUSHPROCINDB borra los planes de ejecución para esa base de datos

Ver también (en DBA.SE)

• Resolver un alto tiempo de carga de la página usando SQL Profiler

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/

Siempre me dijeron que usara:

dbcc dropcleanbuffers;

De MSDN :

Use DBCC DROPCLEANBUFFERS para probar consultas con un caché de búfer frío sin apagar y reiniciar el servidor.

Para eliminar búferes limpios del grupo de búferes, primero use CHECKPOINT para generar un caché de búfer frío. Esto obliga a que todas las páginas sucias de la base de datos actual se escriban en el disco y limpia los búferes. Después de hacer esto, puede emitir el comando DBCC DROPCLEANBUFFERS para eliminar todos los búferes del grupo de búferes.

Las otras respuestas son correctas sobre las razones para no ejecutar DBCC FREEPROCCACHE. Sin embargo, también hay un par de razones para hacerlo:

1. Consistencia

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.

2. El peor de los casos

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.