Las mejores prácticas para reducir Tempdb en un entorno de producción

¿Cuál es la mejor práctica para usar al reducir db temporal en SQL Server 2008?

¿Es arriesgado usar lo siguiente?

use tempdb
GO

DBCC FREEPROCCACHE -- clean cache
DBCC DROPCLEANBUFFERS -- clean buffers
DBCC FREESYSTEMCACHE ('ALL') -- clean system cache
DBCC FREESESSIONCACHE -- clean session cache
DBCC SHRINKDATABASE(tempdb, 10); -- shrink tempdb
dbcc shrinkfile ('tempdev') -- shrink db file
dbcc shrinkfile ('templog') -- shrink log file
GO

-- report the new file sizes
SELECT name, size
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO

sql-server shrink tempdb

— Mcol
fuente

La mejor práctica es determinar qué lo está haciendo crecer y abordarlo. Si lo encoges, solo tiene que volver a crecer y eso lleva tiempo e IO

— Nick.McDermaid

Sí, lo sé. Pero cuando tengo que hacerlo, porque es demasiado tarde para ser proactivo :) ¿Es esta la mejor solución?

Lo siento, no puedo ayudarte allí.

— Nick.McDermaid

Es una buena práctica monitorear proactivamente el uso normal de Tempdb y establecer el tamaño en consecuencia. Si este es uno de los casos en que Tempdb ha crecido a tal tamaño y es un entorno PROD, reiniciaría los Servicios de SQL Server durante el mantenimiento semanal. Luego, Tempdb volvería a su tamaño configurado.

Reducir el archivo está bien siempre que no se use Tempdb, de lo contrario, las transacciones existentes pueden verse afectadas desde el punto de vista del rendimiento debido a bloqueos y puntos muertos.

El procedimiento de limpieza de caché, caché de búfer, etc. tendrá un impacto negativo en el rendimiento de la base de datos hasta que no se vuelvan a crear. No haría esto en PROD.

¡Espero que ayude!

Gracias por su aporte. ¿Es suficiente verificar con sp_who los procesos en tempdb?

No creo que sea una forma confiable de averiguar si se está utilizando temp db. Creo que eso solo aparecería si alguien está creando una tabla temporal directamente en SSMS directamente. Pero si se está haciendo lo mismo como resultado de una operación de consulta debido a un derrame de memoria, etc., entonces no se mostrará en sp_who2. Esa pregunta sería de hecho un hilo separado. Cree eso, ya que es una discusión separada. Si la respuesta anterior lo ayudó, márquelo como respuesta. Eso ayudará a otros con situaciones similares.