Manutenzione del registro delle transazioni quando si passa a Ripristino semplice

Sfondo:

Di recente ho ereditato oltre 50 server SQL con oltre 450 database. I backup notturni sono all'incirca 8 TB e, inutile dirlo, stiamo usando più spazio su disco di quanto vorremmo. Tutti i database sono impostati su Ripristino COMPLETO e non è mai stato eseguito il backup dei registri delle transazioni. Ho esaminato tutti i server SQL e ho identificato quelli a bassa priorità che richiedono solo un backup notturno e un giorno in cui un giorno di perdita di dati è accettabile.

Domanda:

Sto passando da un sacco di database a bassa priorità alla SIMPLEmodalità di recupero da FULL. I registri delle transazioni esistenti verranno troncati (quando vengono creati i checkpoint)? Alcuni dei registri delle transazioni esistenti sono 50-100 GB; Qual è l'approccio migliore per determinare a cosa dovrei ridurli per andare avanti? Ovviamente non voglio mantenerli così grandi. Oppure, si ridurranno da soli nel tempo (non credo che lo faranno)?

Prima di passare FULLal SIMPLEmodello di recupero, chiediti quanti dati puoi permetterti di perdere. Per i database in cui in caso di disastro stai bene ripristinando l'ultimo backup del database, SIMPLEdovrebbe essere OK. In caso contrario, rimani con FULL.

Per ridurre il LDFfile alla dimensione più piccola possibile, seguire i passaggi indicati da Kimberly Tripp qui: 8 passaggi per migliorare il throughput del registro delle transazioni

1. Attendere il tempo in cui c'è scarsa attività sul database

2. Esegui in SSMS:

   DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)

3. Modifica la dimensione del file di registro delle transazioni:

   ALTER DATABASE db_name
   MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)

Sto passando molti database alla modalità di recupero SEMPLICE dalla modalità di recupero COMPLETA (non è necessario il T-Log e il recupero point-in-time). I registri delle transazioni esistenti verranno troncati (quando vengono creati i checkpoint)?

Nel modello di recupero semplice, il motore di database emetterà checkpoint automatici e la sua frequenza è determinata dall'intervallo di ripristino (impostazione di configurazione avanzata del server) o se il registro diventa pieno al 70%.

A meno che non si verifichino transazioni di lunga durata che ritarderanno il troncamento del registro, un checkpoint automatico troncerà la parte inutilizzata del T-log.

Alcuni dei registri delle transazioni esistenti sono 50-100 GB, qual è l'approccio migliore per determinare a cosa dovrei ridurli per andare avanti. Ovviamente non voglio mantenerli così grandi.

Se il modello di recupero del database è impostato su COMPLETO per quei database con 50-100 GB di T-log, è necessario iniziare a eseguire backup T-log frequenti. Ricordare nel modello di recupero completo, una volta stabilita una catena di backup del registro, anche i checkpoint automatici non causeranno il troncamento del registro.

Come ultima risorsa, è possibile troncare il file di registro e quindi eseguire immediatamente un backup completo e quindi iniziare a eseguire i backup di T-log in modo da poter eseguire il ripristino temporizzato in caso di disastro.

Oppure, si ridurranno da soli nel tempo (non credo che lo faranno)?

Come ha sottolineato @TomTom, è un'operazione manuale.

Documentarsi :

• Gestire le dimensioni del file di registro delle transazioni
• COME EFFETTUARE LO SHRINK DEL REGISTRO SERVER SQL - Eccellente scrittura.
• Come funzionano i checkpoint e cosa viene registrato - A cura di: Paul Randal

Molte delle domande non possono essere risolte da noi. Quanto dura un pezzo di spago?

Alcuni dei registri delle transazioni esistenti sono 50-100 GB, qual è l'approccio migliore per determinare a cosa dovrei ridurli per andare avanti.

Finché devono esserlo. Suggerisco di NON restringere. Trunacate registri, torna tra una settimana e vedi quanto spazio viene utilizzato, quindi decidi. Ma devi rispondere a questo.

I backup notturni sono all'incirca 8 TB e, inutile dirlo, stiamo utilizzando più spazio su disco di quanto vorremmo.

Quindi perché trasformarli in semplici? Voglio dire, sul serio.

Tutti i database sono impostati sul ripristino COMPLETO e non è mai stato eseguito il backup dei registri delle transazioni.

Una piccola logica ti dirà che se li tronchi UNA VOLTA, allora probabilmente utilizzerai MOLTO meno spazio per eseguirne il backup. Il risultato potrebbe essere che puoi mantenerli in piena modalità di recupero. Provalo prima. Se si radunano a basso volume, ecc., In futuro i backup dei log saranno MOLTO più piccoli.

Ho esaminato tutti i server SQL e ho identificato quelli con priorità BASSA che necessitano solo di un backup notturno e che un giorno di perdita di dati anche nel caso di un disastro non sarà un problema (database fax e cose del genere).

Sì. Questo fino a quando non si finisce in tribunale e si ottiene il culo consegnato per non avere documenti legali critici. Sai che i registri fax potrebbero far parte di ciò che ti viene richiesto di conservare per anni come informazioni rilevanti per l'azienda? È così nella mia giurisdizione (10 anni). Se sei una società per azioni U potrebbero esserci sorprese simili (SOX). Non farlo rende MOLTO male in tribunale se si desidera dimostrare di non aver ricevuto un fax. O ne ha inviato uno. A nessuno importa se questo è accaduto ogni mese e si dispone di registri più recenti: si falliscono i requisiti legali. Assicurati che questo sia approvato da qualcuno MOLTO alto, perché la tua attività non critica potrebbe essere la tua causa principale.

Oppure, si ridurranno da soli nel tempo (non credo che lo faranno)?

No. E non dovrebbero farlo. Il ridimensionamento del registro è un'operazione manuale ad eccezione dei database a basso volume.