Nella seconda parte di questa serie, ho descritto la gerarchia strutturale del log delle transazioni. Poiché questo post riguarda principalmente i file di registro virtuali (VLF) che ho descritto, ti consiglio di leggere la seconda parte prima di continuare.
Quando tutto va bene, il registro delle transazioni verrà eseguito in loop all'infinito, riutilizzando i VLF esistenti. Questo comportamento è ciò che io chiamo la natura circolare del registro . A volte, tuttavia, succede qualcosa per impedirlo e il registro delle transazioni cresce e cresce, aggiungendo sempre più VLF. In questo post spiegherò come funziona tutto questo, oa volte no.
VLF e troncamento log
Tutti i VLF hanno una struttura di intestazione contenente metadati sul VLF. Uno dei campi più importanti nella struttura è lo stato del VLF e i valori che ci interessano sono zero, il che significa che il VLF è inattivo e due, il che significa che il VLF è attivo . È importante perché un VLF inattivo può essere riutilizzato, ma non uno attivo. Nota che un VLF è completamente attivo o completamente inattivo.
Un VLF rimarrà attivo mentre sono presenti i record di registro richiesti, quindi non può essere riutilizzato e sovrascritto (la prossima volta tratterò i record di registro stessi). Esempi di motivi per cui potrebbero essere richiesti i record di registro includono:
- C'è una transazione di lunga durata di cui fanno parte i record di log, quindi non possono essere rilasciati fino a quando la transazione non è stata confermata o non ha terminato il rollback
- Un backup del registro non ha ancora eseguito il backup di quei record di registro
- Quella parte del registro non è stata ancora elaborata dall'agente di lettura del registro per la replica transazionale o l'acquisizione dei dati di modifica
- Quella parte del log non è stata ancora inviata a un mirror asincrono del database o a una replica del gruppo di disponibilità
È importante notare che se non ci sono ragioni per cui un VLF rimane attivo, non passerà a essere nuovamente inattivo fino a quando un processo chiamato troncamento del registro si verifica – più su questo sotto.
Utilizzando un semplice ipotetico registro delle transazioni con solo cinque VLF e numeri di sequenza VLF che iniziano da 1 (ricorda dall'ultima volta che in realtà non lo fanno mai), quando viene creato il registro delle transazioni, VFL 1 viene immediatamente contrassegnato come attivo, come è sempre stato essere almeno un VLF attivo nel registro delle transazioni, il VLF in cui vengono attualmente scritti i blocchi di registro. Il nostro scenario di esempio è mostrato nella Figura 1 di seguito.
Figura 1:ipotetico registro delle transazioni nuovo di zecca con 5 VLF, numeri di sequenza 1 fino a 5.
Man mano che vengono creati più record di registro e più blocchi di registro vengono scritti nel registro delle transazioni, VLF 1 si riempie, quindi VLF 2 deve diventare attivo per scrivere più blocchi di registro, come mostrato nella Figura 2 di seguito.
Figura 2:l'attività si sposta nel registro delle transazioni.
SQL Server tiene traccia dell'inizio della transazione non vincolata (attiva) meno recente e questo LSN viene mantenuto sul disco ogni volta che si verifica un'operazione di checkpoint. Viene tracciato anche l'LSN del record di registro più recente scritto nel registro delle transazioni, ma viene tracciato solo in memoria poiché non è possibile mantenerlo su disco senza incorrere in varie condizioni di gara. Non importa in quanto viene utilizzato solo durante il ripristino da arresto anomalo e SQL Server può elaborare l'LSN della "fine" del registro delle transazioni durante il ripristino da arresto anomalo. I checkpoint e il ripristino da crash sono argomenti per i post futuri della serie.
Alla fine, VLF 2 si riempirà e VLF 3 diventerà attivo e così via. Il punto cruciale della natura circolare del log delle transazioni è che i VLF precedenti nel log delle transazioni diventano inattivi in modo che possano essere riutilizzati. Questo viene fatto da un processo chiamato troncamento log , comunemente chiamato anche cancellazione log . Sfortunatamente, entrambi questi termini sono terribili impropri perché nulla viene effettivamente troncato o cancellato.
Il troncamento del registro è semplicemente il processo di esame di tutti i VLF nel registro delle transazioni e di determinare quali VLF attivi possono ora essere contrassegnati di nuovo come inattivi, poiché nessuno dei loro contenuti è ancora richiesto da SQL Server. Quando viene eseguito il troncamento del registro, non vi è alcuna garanzia che i VLF attivi possano essere resi inattivi, dipende interamente da ciò che sta accadendo con il database.
Esistono due idee sbagliate comuni sul troncamento dei log:
- Il registro delle transazioni diventa più piccolo (l'idea sbagliata del "troncamento"). No, non è così:non ci sono modifiche alle dimensioni dal troncamento del registro. L'unica cosa in grado di ridurre il registro delle transazioni è un DBCC SHRINKFILE esplicito.
- I VLF inattivi vengono azzerati in qualche modo (l'idea sbagliata di "cancellazione"). No, nulla viene scritto nel VLF quando viene reso inattivo, tranne alcuni campi nell'intestazione VLF.
La figura 3 di seguito mostra il nostro registro delle transazioni in cui i VLF 3 e 4 sono attivi e il troncamento del registro è stato in grado di contrassegnare i VLF 1 e 2 inattivi.
Figura 3:il troncamento del registro contrassegna i VLF precedenti come inattivi.
Quando si verifica il troncamento del log dipende dal modello di ripristino in uso per il database:
- Modello semplice:il troncamento del registro si verifica quando viene completata un'operazione di checkpoint
- Modello completo o modello con registrazione in blocco:il troncamento del log si verifica al completamento di un backup del log (a condizione che non sia in esecuzione un backup completo o differenziale simultaneo, nel qual caso il troncamento del log viene posticipato fino al completamento del backup dei dati)
Non ci sono eccezioni a questo.
Natura circolare del registro
Per evitare che il registro delle transazioni debba crescere, il troncamento del registro deve essere in grado di contrassegnare i VLF come inattivi. Il primo VLF fisico nel log deve essere inattivo affinché il log delle transazioni abbia la sua natura circolare.
Si consideri la Figura 4 di seguito, che mostra che i VLF 4 e 5 sono in uso e il troncamento del registro ha contrassegnato i VLF da 1 a 3 come inattivi. Vengono generati più record di registro, più blocchi di registro vengono scritti in VLF 5 e alla fine si riempie.
Figura 4:L'attività riempie il VLF fisico più alto nel registro delle transazioni.
A questo punto, il log manager per il database esamina lo stato del primo VLF fisico nel log delle transazioni, che nel nostro esempio è VLF 1, con il numero di sequenza 1. VLF 1 è inattivo, quindi il log delle transazioni può scorrere e ricominciare a riempire dall'inizio. Il log manager imposta il primo VLF su attivo e aumenta il suo numero di sequenza in modo che sia uno superiore al numero di sequenza VLF più alto corrente. Quindi diventa VLF 6 e la registrazione continua con il blocco di registro scritto in quel VLF. Questa è la natura circolare del registro, come mostrato di seguito nella Figura 5.
Figura 5:La natura circolare del log delle transazioni e il riutilizzo di VLF.
Quando qualcosa va storto
Quando il primo VLF fisico nel registro delle transazioni non è inattivo, il registro delle transazioni non può avvolgersi, quindi aumenterà (purché sia configurato per farlo e lo spazio su disco sia sufficiente). Ciò accade spesso perché c'è qualcosa che impedisce al troncamento del registro di disattivare i VLF. Se trovi che il log delle transazioni per un database sta crescendo, puoi interrogare SQL Server per scoprire se c'è un problema di troncamento del log usando questo semplice codice qui sotto:
SELECT
[log_reuse_wait_desc]
FROM [master].[sys].[databases]
WHERE [name] = N'MyDatabase'; Se il troncamento del registro è stato in grado di disattivare uno o più VLF, il risultato sarà NIENTE. Altrimenti , ti verrà fornito un motivo per cui il troncamento del registro non ha potuto disattivare alcun VLF. C'è un lungo elenco di possibili ragioni descritte qui nella sezione Fattori che possono ritardare il troncamento del registro.
È importante capire la semantica di quale sia il risultato:è il motivo per cui il troncamento del registro non ha potuto fare nulla l'ultima volta che ha tentato di eseguire . Ad esempio, il risultato potrebbe essere ACTIVE_BACKUP_OR_RESTORE, ma sai che quel backup completo di lunga durata è terminato. Ciò significa solo che l'ultimo tentativo di troncamento del registro, il backup era ancora in esecuzione.
In base alla mia esperienza, il motivo più comune per impedire il troncamento dei log è LOG_BACKUP; cioè, vai a eseguire un backup del registro! Ma c'è anche un comportamento strano e interessante con LOG_BACKUP . Se vedi continuamente il risultato LOG_BACKUP ma sai che i backup del registro stanno avvenendo correttamente, è perché c'è pochissima attività nel database e il VLF corrente è lo stesso dell'ultima volta che è stato eseguito un backup del registro. Quindi, LOG_BACKUP significa "esegui un backup del registro" o "tutti i record del registro di cui è stato eseguito il backup provengono dal VLF corrente, quindi non è possibile disattivarlo". Quando si verifica quest'ultimo, può creare confusione.
Tornando indietro...
Mantenere la natura circolare del registro delle transazioni è molto importante per evitare costose espansioni del registro e la necessità di intraprendere azioni correttive. Di solito, ciò significa garantire che i backup dei registri avvengano regolarmente per facilitare il troncamento dei registri e il dimensionamento del registro delle transazioni per poter contenere operazioni di grandi dimensioni e di lunga durata come ricostruzioni di indici o operazioni ETL senza che si verifichi la crescita del registro.
Nella parte successiva della serie tratterò i record di registro, come funzionano e alcuni esempi interessanti.
