Il modo migliore per mantenere le dimensioni dei file di registro SQL

Sono in qualche modo un nuovo DBA e gestisco un'istanza di SQL Server 2012 con una discreta quantità di attività. Sto correndo in modalità di recupero completo perché abbiamo bisogno di un recupero temporizzato.

In questo momento, eseguo un backup completo dei database e dei registri ogni giorno alle 5:00. Alcuni file di registro sono aumentati fino a 300 GB e anche dopo aver eseguito un backup non si riducono di dimensioni. Posso farli ridurre di dimensioni eseguendo qualcosa di simile a:

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

Quando controllo gli LSN dei file di backup vedo qualcosa del tipo:

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

Non credo di spezzare la mia catena di log riducendo i file di log. Leggendo questo, credo di danneggiare la mia performance perché quei file di log ridotti devono ri-crescere da soli.

Domande:

1. Perché il file di registro non si riduce dopo i miei backup? È perché ci sono transazioni senza commit?
2. All'inizio stavo pensando che avrei dovuto ridurre i file di registro dopo ogni backup delle 5:00. Dopo aver letto su quanto sia negativo per le prestazioni, ora credo di dover eseguire backup regolari del registro ogni paio d'ore durante il giorno. È corretto?
3. Il mio normale backup completo del database / dei registri avviene ogni giorno alle 5:00 del mattino e talvolta impiega 3 ore. Se pianifico che i backup del registro vengano eseguiti ogni ora, cosa accadrà quando il backup del registro si scontra con il backup delle 5:00?

1. Perché il file di registro non si riduce dopo i miei backup? È perché ci sono transazioni senza commit?

Il file di registro NTFS effettivo non "si restringe" da un backup del registro delle transazioni, ma i VLF (file di registro virtuali) all'interno del registro delle transazioni sono contrassegnati per il riutilizzo (poiché ora sono sottoposti a backup e persistono sui supporti) consentendo l'avvolgimento di si verifica l'utilizzo del registro delle transazioni. Se non si esegue il backup del registro delle transazioni, o non abbastanza frequentemente, non ci saranno VLF disponibili e ciò causerà la crescita del registro delle transazioni (a condizione che sia impostata la crescita automatica) per adattarsi alle voci aggiuntive del registro delle transazioni.

2. All'inizio stavo pensando che avrei dovuto ridurre i file di registro dopo ogni backup delle 5:00. Dopo aver letto su quanto sia negativo per le prestazioni, ora credo di dover eseguire backup regolari del registro ogni paio d'ore durante il giorno. È corretto?

La riduzione dei file di routine e pianificata non è una buona idea. Solo quando devi recuperare lo spazio tanto necessario dovresti prendere in considerazione a DBCC SHINKFILE. Inoltre, quando si aumenta continuamente il registro delle transazioni, si potrebbero ostacolare altre cose come il recupero del database. Con troppi VLF nel registro delle transazioni (un problema comune quando il registro delle transazioni viene aumentato solo da un piccolo incremento di memoria), il tempo necessario per ripristinare il database potrebbe essere più lungo di quanto desiderato.

3.Il mio normale backup completo del database / dei registri avviene ogni giorno alle 5:00 del mattino e talvolta impiega 3 ore. Se pianifico che i backup del registro vengano eseguiti ogni ora, cosa accadrà quando il backup del registro si scontra con il backup delle 5:00?

Non succederà nulla, è un'operazione completamente legale. Vedi questo sotto grafico da MSDN . Laddove è presente un punto nero, queste due operazioni non possono avvenire contemporaneamente. Come puoi vedere, sono consentiti contemporaneamente un backup del database e un registro delle transazioni.

Il takeaway qui è che dovresti eseguire il backup del registro delle transazioni più frequentemente. La crescita dei file NTFS non è l'unico problema che potresti incontrare non eseguendo il backup del registro delle transazioni più frequentemente. Se si dovesse verificare un errore di archiviazione e il registro delle transazioni andasse perso, è possibile ripristinare solo fino al momento dell'ultimo backup del registro delle transazioni. Se il registro delle transazioni viene perso, non sarà possibile eseguire il backup della coda del registro e ripristinarlo al momento opportuno dell'errore. Nel tuo caso, potresti potenzialmente perdere 24 ore di dati. Ma se esegui il backup dei registri delle transazioni ogni, diciamo, 30 minuti, la perdita massima di dati sarebbe di 30 minuti. In tal caso, se il registro delle transazioni è sparito e si dispone del backup completo e della catena di registri intatti, è possibile ripristinare l'ultimo backup del registro.

Documentazione TechNet sul troncamento del registro delle transazioni

Il problema principale con cui hai a che fare è il backup dei tuoi registri una volta al giorno. Il comportamento del motore è che i record di registro (spazio utilizzato) all'interno di un file di registro verranno rimossi solo dopo un backup del registro eseguito correttamente. Questo spazio viene recuperato quando si verifica un checkpoint , ma se il database è in modalità di ripristino con registrazione completa / in blocco , i record di registro verranno rimossi solo se è stato eseguito correttamente il backup.

I backup dei log devono essere utilizzati insieme ai backup completi e devono essere eseguiti a intervalli regolari tra i backup completi. Questo intervallo può essere qualsiasi periodo, anche se in genere ho eseguito backup dei registri ogni 15 minuti. L'intervallo dipende dal Recovery Point Objective (RPO) e dalla quantità di dati che è possibile perdere in caso di recupero.

Se si eseguono backup regolari del registro, non è necessario eseguire riduzioni regolari dei file perché si gestirà lo spazio del file di registro prima che sia costretto a crescere.

Ho avuto lo stesso problema come te prima. Il mio file di registro aumenta sempre invece utilizzo il backup completo del database ogni notte. Quindi ecco la mia soluzione:

1. eseguire il backup del file di registro corrente.

2. Imposta il tuo database su Simple Recovery

   • Perché in Full Recovery -> Il file di registro non elimina la transazione impegnata, è solo riorganizzare i dati -> Il file Shink non influisce molto -> e viceversa per Simple Recovery.

3. Trasforma il tuo file di registro a 1 MB o meno (dipende da te)

4. Imposta il tuo database su Ripristino completo.

Spero sia di aiuto

Phong Tran