Encontramos el arreglo a este disgusto, o por lo menos eso creemos. Si continuas con interrogantes compártelo en un comentario, que para nosotros será un placer responderte
Solución:
Puedes hacerlo de esta manera:
-- write everything from your buffers to the disc!
CHECKPOINT;
GO
-- Clean all buffers and caches
DBCC DROPCLEANBUFFERS;
DBCC FREEPROCCACHE;
DBCC FREESYSTEMCACHE('ALL');
DBCC FREESESSIONCACHE;
GO
-- Now shrink the file to your desired size
DBCC SHRINKFILE (TEMPDEV, 40960);
-- Make sure that there is no running transaction which uses the tempdb while shrinking!
-- This is most trickiest part of it all.
GO
El último paso es el más complicado. Durante el proceso de reducción, ninguna otra acción debe usar tempdb, ya que esto podría causar un aborto de su SHRINKFILE operación. Debido al hecho de que tempdb es bastante fácil de reducir, no debería llevar mucho tiempo reducirlo.
Tenga en cuenta que esto es algo así como un “reinicio suave”. Todo se eliminará de los búferes y se escribirá en el disco. Esto significa un impacto en su subsistema de E/S (escritura) ya que tiene que manejar todas las operaciones de escritura. Después de eso, puede reducir el archivo (lo que tiene un impacto en el rendimiento de lectura y escritura) y, al final, todos los procesos que consultan cualquier tabla necesitarán recuperar los datos del subsistema de E/S en los búferes. Esto puede doler más que un reinicio.
Si está ejecutando un sistema de desarrollo, simplemente debe reiniciar la máquina en lugar de hacerlo de esta manera. Pero en algunos sistemas de producción sin un socio de conmutación por error, esto puede ser útil.
Si te apasiona este mundo, puedes dejar una reseña acerca de qué te ha impresionado de este ensayo.