TempDB no se encogerá. No hay transacciones abiertas

Tengo un TempDB en SQL 2008 que se ha vuelto muy grande (> 40 gb) y quiero reducirlo. He usado dbcc shrinkdatabase, dbcc shrinkfile y el comando shrink a través de Management Studio.

Obtuve el siguiente error:

Página 1: 4573184 no se pudo mover porque es una página de tabla de trabajo.

He podido recuperar algo de espacio para salir de peligro ejecutando DBCC FREEPROCCACHE y volviendo a ejecutar una de las rutinas de reducción, pero obviamente esto no es ideal y probablemente solo me dará un poco de tiempo.

He ejecutado DBCC OpenTran y no hay nada que cuelgue por ahí.

Todo lo que he leído en Internet se reduce al reciclaje de SQL Server ... seguramente tiene que haber una mejor manera ... ¿alguien?

Gracias,

Tom

Nota: esta publicación también puede ser útil:

Problemas con el archivo mdf TempDB cada vez mayor

A menos que pueda averiguar qué proceso está usando esa tabla de trabajo (y puede eliminarla de forma segura), tendría que estar de acuerdo con lo que sus búsquedas ya han arrojado: realice un ciclo en el servidor y debería poder reducir tempdb.

Una pregunta diferente se ha ocupado de resolver esto para las tablas #temp; No sé si se puede adaptar para mesas de trabajo:

Encuentra qué sesión está sosteniendo qué tabla temporal

También he blogueado al respecto (de nuevo, para #temp tables):

http://sqlperformance.com/2014/05/t-sql-queries/dude-who-owns-that-temp-table

Dudo que la tabla de trabajo esté relacionada con el aislamiento de instantáneas / almacén de versiones, pero por las dudas:

Encuentra transacciones que llenan la tienda de versiones

Además, no confíe en DBCC OPENTRAN;: he observado muchos escenarios en los que sé que tengo una transacción activa pero que no aparece allí. Y tenga en cuenta que el contexto de la base de datos es importante; la base de datos donde está activa la transacción no es necesariamente tempdb. que ves aquí? ¿Cualquier cosa?

SELECT * FROM sys.dm_tran_active_transactions
  WHERE name = N'worktable';

Una vez que haya reducido tempdb

Por supuesto, esta no es una solución permanente. Vas a reducir tempdb, y luego volverá a crecer. Puede ser muy aburrido y tedioso jugar este juego cada vez que sucede. Y si va a crecer de nuevo, ¿qué vas a hacer con ese espacio libre mientras tanto? ¿Arrendarlo y luego desalojar a las personas cuando tempdb lo necesite nuevamente? Usted necesita:

1. Arregle el proceso que hace que tempdb crezca anormalmente grande en primer lugar.
2. Asigne suficiente espacio para tempdb para que no necesite crecer, y deje de reducirlo (especialmente si es solo temporalmente; ¡esto es solo un trabajo desperdiciado!).

Un par de otras sugerencias:

• No use SHRINKDATABASE(que debería llamarse auto-fragmento) o la IU. Escriba SHRINKFILEcomandos específicos y específicos para afectar archivos individuales.
• Considere el uso de varios archivos para tempdb (que podría distribuir a un almacenamiento diferente si es posible), y considere las marcas de seguimiento 1117 (siempre que este comportamiento no afecte también a las bases de datos de sus usuarios) y 1118.
• Algunos consejos para minimizar la utilización de tempdb aquí:
  • ¿Cómo identificar qué consulta está llenando el registro de transacciones tempdb?

Todo lo que he leído en Internet se reduce al reciclaje de SQL Server ... seguramente tiene que haber una mejor manera ... ¿alguien?

No, esta es una solución temporal. Supongo que publicó la misma pregunta antes, ¿podría decir cuál es el tamaño total de la base de datos que tiene en su instancia de SQL Server? El tamaño de tempdb depende de cuánto lo estén usando sus consultas. No puede crecer por sí solo a menos que lo use. Los enlaces compartidos por Aron ayudarían, pero debe ajustar las consultas si usan mucho temdbb o pueden ser el requisito predeterminado de su entorno. He visto pocas env. donde 200 G de tempdb era aceptable porque las consultas requerían una gran cantidad de espacio tempdb.