Tengo demasiados archivos de datos secundarios (.ndf) creados para tempdb. Para eliminar el exceso de archivos, necesito vaciar el archivo (el contenido se moverá a otros archivos):
DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);y luego elimine el archivo:
ALTER DATABASE tempdb REMOVE FILE tempdbfile8;Pero el EMPTYFILEcomando devuelve el error:
DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.
No se preocupe, solo necesito localizar el objeto que está usando esta página para hacer algo al respecto:
DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920
El comando devuelve mucha información, object_id entre ellos. Pero:
Metadata: ObjectId = 0 No tengo idea de qué hacer al respecto. ¿Qué gato impide que se mueva esta página? ¿Cómo localizar ese objeto, proceso, sesión o lo que sea? Cualquier ayuda será apreciada, pero tenga en cuenta que dejar todo como está o eliminar otro archivo no es una solución válida para este problema;).
EDITAR:
Estoy eliminando los archivos, porque solíamos seguir la "mejor práctica" de crear un archivo por núcleo de procesador (mismo tamaño inicial, misma tasa de crecimiento). Pero hasta donde yo sé, hasta que encuentre problemas de contención, no tiene sentido crear archivos tempdb adicionales en el mismo dispositivo. En nuestro caso tiene sentido, porque tenemos MPIO activado y el dispositivo de almacenamiento puede manejar 4 rutas. Pero hubo un error, y terminamos con un total de 5 archivos con CPU de 6 núcleos. Es más que rutas MPIO, menos que núcleos de CPU, y no es un número par. Puede que no cause ningún problema, pero simplemente no parece correcto :).
Finalmente pude vaciar y eliminar el archivo sin reiniciar el servidor estableciendo una de las bases de datos (que sospechaba que causaba el problema) en modo de usuario único (reversión inmediata). Funcionó, pero tuve suerte. Lo que realmente quiero es poder rastrear siempre la página :).
fuente
dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])sobre su solución: funcionaría, pero realmente me gustaría hacer esto sin derribar la instancia.Respuestas:
Reiniciar el servidor debería ser suficiente: esas tablas de trabajo deberían eliminarse. Pero probablemente lo inicie en modo de usuario único (-m) para evitar que otros procesos creen tablas de trabajo antes de eliminar con éxito esos archivos. Luego redefina los archivos necesarios para
tempdb; quizás eliminar archivos innecesarios, cambiar tamaños, etc. También debe asegurarse de tener un número par de archivos, que todos estén configurados con el mismo tamaño y que todos tengan la misma configuración de crecimiento automático (en MB, no%). Y podría ser un buen momento para considerar TF 1117 y TF 1118 también ( punto de partida ).Sería muy cauteloso con la sugerencia de simplemente eliminar los archivos del sistema de archivos antes de iniciar SQL Server nuevamente; es posible que no se inicie en absoluto.
(Sin embargo, también me gustaría saber cuál es el problema real. Tener demasiados archivos no te hace daño realmente).
fuente
https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-411283400-could-not-be-moved-because-it-is- a-work-table-page? forum = sqldatabaseengine
Como propuso Mike en el foro msdn, las tablas de trabajo están asociadas principalmente con la caché del plan. Al eliminarlos, también se eliminaría la mesa de trabajo y luego se puede reducir Tempdb. Esto funcionó para mí. Y esto también le ahorra un reinicio del servidor. Habrá algunos gastos generales ya que el servidor SQL tendrá que volver a crear planes de ejecución.
fuente