Best practice per il file di registro tempdb

Ho letto molti blog qua e là su come configurare i file di dati tempdb ma non ho trovato alcuna informazione sul file di registro tempdb .

Ecco la strategia che sto attualmente usando con il mio tempdb:

Ho usato i consigli di Paul Randal su come dividere i miei file di dati tempdb
Ho impostato la dimensione dei miei file di dati tempdb al massimo e disabilitato la crescita automatica. Ad esempio, ho 100 GB di spazio libero su disco e ho impostato la dimensione dei miei 8 file di dati tempdb su 10 GB ciascuno. Questo impedisce la frammentazione sul disco come raccomandato da Brent Ozar e ho anche 20 GB gratuiti per il mio file di registro.

Ma come ho detto, nessuno sta parlando del file di registro tempdb . Cosa dovrei farci? Nella mia configurazione, questo file si trova nello stesso posto dei file di dati tempdb. Qual è la dimensione e il valore di crescita automatica che dovrei usare con il file di registro tempdb?

sql-server sql-server-2012 tempdb

— Alexandre Jobin
fonte

Non c'è una risposta magica per questo, tranne per il fatto che non disabiliterei la crescita automatica per i dati o il registro tempdb a meno che tu non voglia assolutamente che il sistema si fermi bruscamente se fosse necessaria la crescita automatica. Non disabiliterei mai l'autogrow su nessun file, perché non importa quanto bene pianifichi, ci sono sempre situazioni anomale.

— Aaron Bertrand

@AaronBertrand: abilitare la crescita automatica su un tempdb di dimensioni standard non sarà di aiuto. Sono già al massimo possono essere sul disco. Non c'è più spazio su disco che possono comunque utilizzare. Questo è il motivo per cui ho disabilitato la crescita automatica.

— Alexandre Jobin,

Quindi non importa se è disabilitato o no, vero? Se è necessaria una crescita automatica, fallirà in entrambi i modi. Se lo lasci abilitato, questa è una cosa in meno che devi cambiare quando ti rendi conto che forse devi spostarlo su un disco più grande.

— Aaron Bertrand

PS 8 x 20> 100

— Aaron Bertrand

Dividere i tuoi file non è necessariamente "una buona configurazione". Dipende dalla tua configurazione hardware; che non hai fornito.

— Paul,

Risposte:

Dipende davvero dalla quantità di dati che fluirà attraverso il registro delle transazioni. Guarda quanto è grande il registro oggi. È necessario configurare il registro in modo che abbia almeno quella dimensione all'avvio di SQL. Per la maggior parte dei miei clienti finiscono con un log delle transazioni da 3-4 Gig per il tempdb, che contiene solo alcuni VLF e tutto funziona bene e senza intoppi.

— mrdenny
fonte

Mi è sempre stato detto di archiviare i file di registro su un array fisico / disco separato se il tuo hardware è in grado di scrivere simultaneamente sui dati e registrare contemporaneamente per migliorare le prestazioni. Immagino che la limitazione generata dal tuo limite tempdb 20G potrebbe definire una risposta per dimensione. Per la crescita automatica, ciò potrebbe dipendere dalle transazioni in esecuzione, dallo spazio libero disponibile e da altre risorse sul disco. Solitamente scelgo 1/6 della dimensione iniziale in modo arbitrario.

— Robert Gannon
fonte

Aaron ha ragione a configurare TempDB dipende da molte variabili, ad esempio se si prevede di utilizzare l'isolamento dello snapshot, ecc. Ecco un vecchio white paper di SQL 2005 di MS / TN che potrebbe essere d'aiuto, poiché è ancora valido. In particolare, dai un'occhiata allo "Spazio richiesto per la registrazione tempdb" in modo da poter vedere quali tipi di transazioni sono registrate nel registro tempdb in modo da poter impostare le cose di conseguenza. Sarà probabilmente il genere di cose che dovrai monitorare e modificare nel tempo.

Per quanto riguarda l'autogrowth per tempdb, in passato a malincuore l'ho disabilitato su un server di report e il comportamento che ho riscontrato è stato quello di causare l'interruzione e il rollback della transazione a lungo termine che ha liberato immediatamente lo spazio di log ma che potrebbe dipendere dal il tipo di transazione che nel mio caso è stata di enormi tipi e operazioni di join (query di report scritte male). Concordo con Aaron e consiglierei di evitarlo, se possibile, specialmente in situazioni di volumi di transazioni elevati.

— Miketk
fonte