TempDB non si ridurrà. Nessuna transazione aperta

Ho un TempDB su SQL 2008 che è diventato molto grande (> 40 GB) e voglio ridurlo. Ho usato dbcc shrinkdatabase, dbcc shrinkfile e il comando shrink tramite Management Studio.

Ottengo il seguente errore:

Pagina 1: 4573184 non può essere spostato perché è una pagina della tabella di lavoro.

Sono stato in grado di recuperare un po 'di spazio per farmi uscire dal pericolo eseguendo DBCC FREEPROCCACHE e ri-eseguendo una delle routine di riduzione, ma ovviamente questo non è l'ideale e probabilmente mi comprerà solo un po' di tempo.

Ho eseguito DBCC OpenTran e non c'è nulla che esca lì.

Ovunque abbia letto su Internet si riduce al riciclo di SQL Server ... sicuramente ci deve essere un modo migliore ... qualcuno?

Grazie,

Tom

Nota: anche questo post potrebbe essere utile:

Problemi con il file mdf TempDB in costante aumento

A meno che tu non riesca a capire quale processo sta usando quella tabella di lavoro (e puoi tranquillamente ucciderla), dovrei essere d'accordo con ciò che le tue ricerche hanno già prodotto: ciclo il server e dovresti essere in grado di ridurre tempdb.

Una domanda diversa si è occupata di capire questo per le tabelle #temp; Non so se può essere adattato per i tavoli di lavoro:

Trova quale sessione contiene quale tabella temporanea

Ne ho anche scritto un blog (di nuovo, per le tabelle #temp):

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

Dubito che la tabella di lavoro sia correlata all'isolamento dello snapshot / archivio versioni, ma nel caso in cui:

Trova le transazioni che stanno riempiendo l'archivio versione

Inoltre, non fare affidamento DBCC OPENTRAN;: ho osservato molti scenari in cui so di avere una transazione attiva ma non viene visualizzata lì. E nota che il contesto del database è importante; il database in cui è attiva la transazione non è necessariamente tempdb. cosa vedi qui? Nulla?

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

Dopo aver ristretto tempdb

Certo, questa non è una soluzione permanente. Ridurrai tempdb e poi crescerà di nuovo. Questo può diventare molto noioso e noioso per giocare a questo gioco ogni volta che succede. E se tornerà a crescere, cosa intendi fare con quello spazio libero nel frattempo? Affittalo e sfratti le persone quando ne ha bisogno di nuovo tempdb? È necessario:

1. In primo luogo, correggi il processo che sta facendo crescere tempdb in modo anomalo.
2. Assegna abbastanza spazio per tempdb in modo che non abbia bisogno di crescere e smetti di ridurlo (specialmente se solo temporaneamente; questo è solo un lavoro sprecato!).

Un paio di altri suggerimenti:

• Non utilizzare SHRINKDATABASE(che dovrebbe essere chiamato frammento automatico) o l'interfaccia utente. Scrivi SHRINKFILEcomandi specifici e mirati per influire sui singoli file.
• Considerare l'utilizzo di più file per tempdb (che è possibile distribuire in archivi diversi se / quando possibile) e considerare i flag di traccia 1117 (purché questo comportamento non influisca anche sui database degli utenti) e 1118.
• Alcuni suggerimenti su come ridurre al minimo l'utilizzo di tempdb qui:
  • Come identificare quale query sta riempiendo il registro delle transazioni tempdb?

Ovunque abbia letto su Internet si riduce al riciclo di SQL Server ... sicuramente ci deve essere un modo migliore ... qualcuno?

No, questa è una soluzione temporanea. Immagino che tu abbia pubblicato la stessa domanda prima, potresti dirmi qual è la dimensione totale del database che hai nella tua istanza di SQL Server. Le dimensioni di tempdb dipendono da quanto le tue query lo utilizzano. Non può crescere da solo se non lo usi. I collegamenti condivisi da Aron potrebbero essere d'aiuto, ma è necessario ottimizzare le query se utilizzano fortemente temdbb o potrebbero essere i requisiti predefiniti del proprio ambiente. Ho visto pochi env. dove 200 G di tempdb erano accettabili perché le query richiedevano una tale quantità di spazio tempdb.