TempDB no se encogerá. No hay transacciones abiertas

9

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

sql-server-2008 tempdb shrink usuario45117
fuente

Respuestas:

7

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í:
Aaron Bertrand
fuente
1
SELECCIONAR * DESDE sys.dm_tran_active_transactions DONDE nombre = N'worktable '; devuelve 6 filas todas desde la misma fecha (7/10/14). ¿La transacción_id representa el SPID?
user45117
No, transacción_id no es SPID. Si las transacciones están realmente activas (y no son transacciones del sistema ), debería poder hacer coincidir un session_id en sys.dm_tran_session_transactions. En cualquier caso, ¿está seguro de que este es el mensaje que recibe de DBCC SHRINKFILE? ¿Qué pasa con ALTER DATABASE ... MODIFY FILE? Además, no estoy seguro de entender por qué borrar el caché del procedimiento lo sacó de problemas; procedimiento caché está en la memoria, no en tempdb ...
Aaron Bertrand
El mensaje vino de DBCC SHRINKDATABASE. No he probado ALTER DATABASE ... MODIFY FILE ... que será el próximo. Borrar el caché del procedimiento permitió que el tempdb se redujera en aproximadamente un 10% y me devolvió 4 gb de espacio en disco. No pude vincular esas transacciones_id de sys.dm_tran_active_transactions a nada en sys.dm_tran_session_transactions
user45117
1
Creo que borrar el caché del procedimiento estaba menos relacionado con "permitir" que tempdb se redujera de lo que piensas. Las coincidencias ocurren todo el tiempo.
Aaron Bertrand
0

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.

Shanky
fuente