Eliminar archivos de datos secundarios. DBCC SHRINKFILE: la página no se pudo mover porque es una página de tabla de trabajo

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 :).

— Adam Luniewski
fuente

El comando DBCC PAGE no es correcto, debería ser como la página dbcc (2,41920,1). 1,2,3 depende de lo que quieras en la salida.

— Shanky

Si lo anterior no funciona, es posible que tenga que hacerlo en hardware eliminando archivos y luego reiniciando el servidor sql para que solo use archivos que no se eliminaron. ¿Puede referirse a este enlace? Daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file

— Shanky

@Shanky El comando es correcto. 0..3 se puede pasar como cuarto parámetro: 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.

— Adam Luniewski

Ok ... Te estaba diciendo una forma más simple de página dbcc. Tenga en cuenta que es un comando no documentado. ¿Ha comprobado el enlace que

— publiqué

No creo que sea factible resolver este problema sin reiniciar la instancia. Obviamente ha intentado rastrear qué es esta mesa de trabajo (lo que ayudaría a determinar quién es el propietario), y eso ha fallado. Toma el golpe o vive con los archivos adicionales hasta que puedas reiniciar.

— Aaron Bertrand

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).

— Aaron Bertrand
fuente

@@ Aaron, por supuesto, debe tener cuidado al eliminarlo, debe estar vacío, pero eso está documentado aquí msdn.microsoft.com/en-gb/library/ms175574.aspx . Lo he probado y SQl Server tempdb se conecta.

— Shanky

@Shanky Intenté conducir 138 millas por hora una vez, y no me detuvieron. ¿Eso significa que debería seguir haciéndolo y que no hay posibilidad de que me detengan mañana? Es mucho más seguro intentar primero la forma correcta , antes de sugerir una forma más riesgosa. EN MI HUMILDE OPINIÓN. Especialmente porque no puede vaciar el archivo ahora, ¿crees que es posible que haya algo más además de la mesa de trabajo de la que se queja el mensaje de error? El error no produce una lista exhaustiva de todos los objetos, solo genera el primer objeto.

— Aaron Bertrand

Hay algo que realmente está usando tempdb, por lo que no le permite vaciar el archivo, es difícil de adivinar. Puede que él haya usado el operador sort es alguna consulta que todavía necesita tempdb. El DMV puede ayudarlo a encontrar sys.dm_db_task_space_usage sys.dm_db_session_space_usage sys.dm_db_file_space_usage

— Shanky

Reiniciar es una opción aquí, pero incluso si no vacía el archivo e intenta soltar el archivo tempdb, diría que el archivo tempdb no se puede soltar, pero al mismo tiempo se actualiza el catálogo del sistema y después de reiniciar el archivo desaparecerá. Supongo que este es el comportamiento predeterminado con tempdb, así que sugerí y sigo pensando que eliminar el archivo de datos funcionaría incluso si se utiliza. Lo mismo está allí en el enlace que publiqué en mi segundo comentario.

— Shanky

@Shanky esos DMV podrían devolver miles de filas para todo tipo de cosas que no tienen nada que ver con el archivo en cuestión, entonces, ¿cómo planeas reducirlo? Además, dado que con su método también debe reiniciar, ¿por qué no probar primero la forma más simple? Simplemente no estoy de acuerdo con usted en que "la forma difícil" debería ser la primera sugerencia, lo siento.

— Aaron Bertrand

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.

— sajeesh
fuente