TempDB non si ridurrà. Nessuna transazione aperta


9

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

Risposte:


7

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:

1
SELEZIONA * FROM sys.dm_tran_active_transactions WHERE name = N'worktable '; restituisce 6 righe tutte dalla stessa data (7/10/14). La transazione_id rappresenta lo SPID?
user45117

No, transaction_id non è SPID. Se le transazioni sono veramente attive (e non sono transazioni di sistema ), dovresti essere in grado di abbinare a session_id in sys.dm_tran_session_transactions. In ogni caso, sei sicuro che questo sia il messaggio che ricevi da DBCC SHRINKFILE? Che dire di ALTER DATABASE ... MODIFY FILE? Inoltre non sono sicuro di capire perché svuotare la cache delle procedure ti abbia messo in difficoltà; la cache delle procedure è in memoria, non in tempdb ...
Aaron Bertrand

Il messaggio proveniva da DBCC SHRINKDATABASE. Non ho provato ALTER DATABASE ... MODIFY FILE ... che sarà il prossimo. Svuotare la cache delle procedure ha permesso di ridurre il tempdb di circa il 10% e mi ha restituito 4 GB di spazio su disco. Non sono stato in grado di collegare tali transazioni_id da sys.dm_tran_active_transactions a qualcosa in sys.dm_tran_session_transactions
user45117

1
Penso che svuotare la cache delle procedure sia meno correlata al "consentire" di ridurre tempdb di quanto si pensi. Le coincidenze accadono continuamente.
Aaron Bertrand

0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.