Il mio templog.ldf è enorme (45 gb), e se dovessi fare qualcosa?

Ho un'installazione di SQL 2005 e il mio file templog.ldf continua a crescere per consumare tutto lo spazio libero sull'unità in cui si trova. A volte si ferma con qualche mb libero ma a volte va oltre, essendo questo il c drive penso che questo comportamento possa essere implicato in altri problemi che ho visto.

La mia domanda è: cosa devo fare, posso spostare il registro su un'altra unità, ma ho ragione di presumere che non farà solo la stessa cosa lì. Suppongo che questo comportamento sia probabilmente il risultato di qualcosa che posso cambiare e che 45 GB è una dimensione insolita per il registro tempdb da raggiungere. Nel nostro codice utilizziamo molte tabelle temporanee e funzioni con valori di tabella, quindi esiste un ampio margine di utilizzo di tempdb, posso capire la crescita del database tempdb ma non capisco il motivo della crescita di templog.

Finora, ho eseguito DBCC OPENTRAN ('tempdb') per vedere se alcune vecchie transazioni sono in giro, non lo sono. Ho letto su come ridurre il tempdb e l'ho fatto un paio di volte, ma mi chiedo davvero cosa succede se posso fare qualcosa per impedire che ciò accada in primo luogo o maggiori dettagli sul perché potrebbe crescere così tanto in il primo posto.

== EDITS ==

1) tempdb utilizza un semplice modello di recupero

2) La crescita di templog si verifica nell'arco di un paio d'ore al mattino quando abbiamo in esecuzione alcune query pianificate, sostanzialmente un carico di report che si esaurisce nelle ore di ufficio per il giorno a venire. La dimensione del file aumenta costantemente durante questo periodo. Controlliamo quanti report simultanei sono in esecuzione contemporaneamente, aumentando il numero di report simultanei aumenta la velocità con cui il log cresce.

Controlla le tue query sui rapporti. Ne hai qualcuno con DISTINCT? Qualcuno di loro ha un join cartesiano?

Qualche query di reporting accede ai server collegati come membri di un join? In tal caso, ciò può far aumentare il registro e il database tempdb.

Quando i rapporti sono in esecuzione al mattino qualcuno di loro si blocca?

Abbiamo avuto un problema simile, dopo aver sollevato la chiamata PSS con Microsoft e un'indagine approfondita del problema, abbiamo suddiviso in zone la seguente possibile causa e risoluzione.

Causa:

La probabile causa dei sintomi è dovuta ai dischi / lun su cui sono posizionati i database degli utenti con gravi problemi di risposta I / O; ciò causa il completamento del checkpoint automatico nei database degli utenti.

Ora, il checkpoint su tempdb si verifica solo quando il registro tempdb diventa pieno al 70% e ha anche una priorità inferiore rispetto ai checkpoint del database utente. Pertanto, in modo efficace quando viene emesso un checkpoint automatico sul / i database / i utente e sta tentando di completarlo, a causa dell'uso intenso di tempdb, il file di registro tempdb si riempie rapidamente; al 70% di utilizzo del registro si verifica il checkpoint tempdb ma è in coda dietro il checkpoint del database utente.

Nel tempo impiegato dal checkpoint del database utente per completare il file di registro tempdb continua a riempirsi e se è impostata la funzione di crescita automatica, il file di registro aumenta quando richiede più spazio. Questo è il motivo per cui il file di registro continua a crescere.

In sintesi, la causa principale più probabile per i sintomi descritti è dovuta alla scarsa risposta I / O dei dischi / lun per l'utente e / o ai file di database / log tempdb.

Soluzione:

Abbiamo risolto il problema mentre risolvevamo il sottosistema I / O impostando un avviso che si attivava quando il file di registro tempdb si riempiva del 75% e in risposta eseguiva un lavoro che imponeva un "CHECKPOINT" manuale (che ha la precedenza sul sistema automatico punti di controllo), cancellando il registro tempdb impedendogli di auto-crescere indefinitamente. È comunque una buona idea lasciare che il file di registro cresca automaticamente per qualsiasi altra evenienza. Inoltre, ti consiglio vivamente di considerare di ridurre la dimensione del file di registro tempdb a qualcosa di significativo secondo il tuo ambiente dopo aver inserito la correzione.

Spero che sia di aiuto.

A cosa è impostato il modello di recupero sul database temporaneo? Se non è impostato su Semplice, impostalo su Semplice. Questo dovrebbe impedirgli di crescere. Se è già impostato su Semplice, direi che c'è un problema di base che deve essere risolto e qualsiasi tentativo di ridurre il file sta semplicemente trattando i sintomi del problema e non la causa principale.

Ho passato le ultime ore a leggere e prendere appunti su questo

http://technet.microsoft.com/en-gb/library/cc966545.aspx

Ci sono molti dettagli e suggerimenti per risolvere i problemi. Sembra che a meno che il tuo tempdb non si stia espandendo e non smetta mai di crescere, probabilmente sta semplicemente occupando la quantità di spazio di cui ha bisogno e avrebbe dovuto essere configurato inizialmente con quelle dimensioni. C'è una sezione per stimare lo spazio richiesto per il tuo tempdb e per rintracciare ciò che potrebbe occupare spazio in tempdb. Di conseguenza, la prima cosa che farò è spostare tempdb su un'unità più grande e vedere cosa succede da lì.

Esiste una sezione intitolata "Spazio richiesto per la registrazione di tempdb" che indica quali funzionalità utilizzano il registro, mentre un'altra sezione precedente descrive in dettaglio il superset di funzionalità che utilizzano tempdb.

La sezione intitolata "Monitoraggio I / O" ha alcune idee sui contatori delle prestazioni da tenere d'occhio, una rapida occhiata al mio server li inserisce in un territorio probabilmente-colto-collo di bottiglia. Li monitorerò per un po 'e vedrò come vanno le cose. Anche il file di registro tempdb era in realtà con un utilizzo inferiore al 50%, il che si adatta all'idea che si è espansa sotto carico questa mattina e da allora ha mantenuto quello spazio.

Sto andando avanti sulla base del fatto che la dimensione in cui è cresciuta è la dimensione che deve essere, monitorare questa dimensione in futuro e assicurarmi che ci sia spazio per la crescita su qualsiasi unità sia accesa. Come suggerito da alcuni qui, esaminerò ciò che sta eseguendo mentre il registro temporaneo si espande e vedremo se qualcosa può essere modificato lì. Terrò anche d'occhio quei contatori delle prestazioni per vedere se qualcosa ha bisogno di essere affrontato.

C'era un'altra sezione interessante aggiuntiva intitolata "Aggiornamento a SQL Server 2005" che indica che tempdb è utilizzato per più cose nel 2005 rispetto al 2000 (sia nuove funzionalità che funzionalità esistenti che in precedenza non utilizzavano tempdb). Ho appena aggiornato al 2005, quindi questo potrebbe essere parte del motivo per cui questo è diventato improvvisamente un problema. Non ricordo di aver visto questo altrove con riferimento all'aggiornamento al 2005, il che è un po 'una seccatura.

Ciò è probabilmente causato da una query incrociata fuori controllo. La soluzione migliore è utilizzare Profiler per trovarlo e quindi risolverlo.

L'altro modo per trovarlo è limitare la dimensione del file di registro TempDB e quindi attendere per vedere quale query ha esito negativo. Tuttavia, scommetto che sta già fallendo e nessuno te lo sta dicendo.

Se si riavvia il motore SQL, il file verrà impostato sulla dimensione iniziale. Dovresti mettere una dimensione massima su tutti i tuoi file di crescita automatica.

Qualche query SQL o proc memorizzato sta facendo cose cattive - l'unica cosa che puoi fare è profilare il tempdb per catturare l'evento "Database: Auto crescita del file di registro" e, quando ciò accade, usa il profiler e le query su tabelle come sysprocesses per trovare fuori qual è il cattivo processo.

Sfortunatamente, dipende dal vecchio lavoro investigativo per rintracciare il processo canaglia.

Hai provato a ridimensionare i file di registro tempdb con DBCC SHRINKFILE ()? In tal caso, quanto tempo ci vuole per passare da [valore molto piccolo] a 45 GB o più?