Nei miei ultimi due post ho discusso i modi per ridurre la quantità di log delle transazioni che viene generato e come garantire che il log delle transazioni possa sempre essere cancellato correttamente. In questo post voglio continuare con il tema delle prestazioni del registro delle transazioni e discutere alcuni problemi di configurazione del registro delle transazioni che possono causare problemi.
Troppi VLF
Il registro delle transazioni è suddiviso in blocchi chiamati file di registro virtuali (VLF) in modo che il sistema di gestione dei registri possa facilmente tenere traccia di quali parti del registro delle transazioni sono disponibili per il riutilizzo. C'è una formula per quanti VLF ottieni quando crei il registro delle transazioni, lo fai crescere manualmente o cresce automaticamente:
| Fino a 1 MB | 2 VLF, ciascuno circa 1/2 della dimensione totale |
|---|---|
| 1 MB a 64 MB | 4 VLF, ciascuno circa 1/4 della dimensione totale |
| 64 MB a 1 GB | 8 VLF, ciascuno circa 1/8 della dimensione totale |
| Più di 1GB | 16 VLF, ciascuno circa 1/16 della dimensione totale |
Ad esempio, se crei un registro delle transazioni da 8 GB, otterrai 16 VLF in cui ciascuno è di circa 512 MB. Se poi aumenti il registro di altri 4 GB, otterrai 16 VLF aggiuntivi, ciascuno dei quali sarà di circa 256 MB, per un totale di 32 VLF.
Nota:questo algoritmo è leggermente cambiato per SQL Server 2014 per alleviare i problemi di frammentazione VLF:vedere questo post del blog per i dettagli
Una procedura consigliata generale consiste nell'impostare la crescita automatica del registro su un valore diverso dal 10% predefinito, in modo da poter controllare la pausa richiesta quando si azzera il nuovo spazio del registro delle transazioni. Supponiamo di creare un registro delle transazioni da 256 MB e impostare la crescita automatica su 32 MB, quindi il registro cresce fino a una dimensione in stato stazionario di 16 GB. Data la formula sopra, ciò comporterà che il registro delle transazioni contenga più di 2.000 VLF.
Questo numero di VLF probabilmente comporterà alcuni problemi di prestazioni per le operazioni che elaborano il registro delle transazioni (ad es. ripristino di arresto anomalo, cancellazione del registro, backup del registro, replica transazionale, ripristini del database). Questa situazione è chiamata avere la frammentazione VLF. Generalmente un numero qualsiasi di VLF superiore a mille o giù di lì sarà problematico e deve essere affrontato (il massimo di cui abbia mai sentito parlare è di 1,54 milioni di VLF in un registro delle transazioni di dimensioni superiori a 1 TB!).
Il modo per sapere quanti VLF hai è usare il DBCC LOGINFO non documentato (e completamente sicuro) comando. Il numero di righe di output è il numero di VLF nel registro delle transazioni. Se pensi di averne troppi, il modo per ridurli è:
- Consenti la cancellazione del registro
- Riduci manualmente il registro
- Ripetere i passaggi 1 e 2 fino a quando il registro non raggiunge una piccola dimensione (che potrebbe essere difficile in un sistema di produzione occupato)
- Fai crescere manualmente il registro fino alla dimensione che dovrebbe essere, con passaggi fino a 8 GB in modo che ogni VLF non superi circa 0,5 GB
Puoi leggere ulteriori informazioni sui problemi di frammentazione VLF e sul processo per risolverli all'indirizzo:
- Articolo Microsoft KB che consiglia di ridurre i numeri VLF
- La crescita dei file di registro può influire su DML?
- 8 passaggi per migliorare il throughput del registro delle transazioni
Tempdb
Tempdb deve avere il registro delle transazioni configurato come qualsiasi altro database e potrebbe crescere come qualsiasi altro database. Ma ha anche alcuni comportamenti insidiosi che possono causare problemi.
Quando un'istanza di SQL Server viene riavviata per qualsiasi motivo, i dati e i file di registro di tempdb torneranno alla dimensione su cui erano stati impostati più di recente. Questo è diverso da tutti gli altri database, che rimangono alla dimensione corrente dopo il riavvio di un'istanza.
Questo comportamento significa che se il registro delle transazioni tempdb è cresciuto per adattarsi al normale carico di lavoro, è necessario eseguire un ALTER DATABASE per impostare la dimensione del file di registro, altrimenti la sua dimensione diminuirà dopo il riavvio di un'istanza e dovrà crescere di nuovo. Ogni volta che un file di registro cresce o cresce automaticamente, il nuovo spazio deve essere inizializzato a zero e l'attività di registrazione si interrompe mentre viene eseguita. Pertanto, se non gestisci correttamente le dimensioni del file di registro tempdb, pagherai una riduzione delle prestazioni in quanto aumenta dopo il riavvio di ogni istanza.
Restringimento regolare del file di registro
Abbastanza spesso sento persone dire come di solito rimpiccioliscono il registro delle transazioni di un database dopo che è cresciuto da un'operazione regolare (ad esempio un'importazione settimanale di dati). Non è una buona cosa da fare.
Proprio come ho spiegato sopra, ogni volta che il registro delle transazioni cresce o cresce automaticamente, c'è una pausa mentre la nuova parte del file di registro viene inizializzata a zero. Se riduci regolarmente il registro delle transazioni perché cresce fino alla dimensione X, significa che si verificano regolarmente problemi di prestazioni poiché il registro delle transazioni torna automaticamente alla dimensione X.
Se il tuo registro delle transazioni continua a crescere fino alla dimensione X, lascialo stare! Impostalo in modo proattivo sulla dimensione X, gestendo i tuoi VLF come ho spiegato sopra e accetta la dimensione X come dimensione richiesta per il tuo normale carico di lavoro. Un registro delle transazioni più grande non è un problema.
File di registro multipli
Non vi è alcun miglioramento delle prestazioni dalla creazione di più file di registro per un database. Potrebbe essere necessario aggiungere un secondo file di registro, tuttavia, se il file di registro esistente esaurisce lo spazio e non si desidera forzare la cancellazione del registro delle transazioni passando al modello di ripristino semplice ed eseguendo un checkpoint (in quanto ciò interrompe il backup del registro catena).
Spesso mi viene chiesto se c'è qualche motivo urgente per rimuovere il secondo file di registro o se va bene lasciarlo in posizione. La risposta è che dovresti rimuoverlo il prima possibile.
Sebbene il secondo file di registro non causi problemi di prestazioni per il carico di lavoro, influisce sul ripristino di emergenza. Se il tuo database viene distrutto per qualche motivo, dovrai ripristinarlo da zero. La prima fase di qualsiasi sequenza di ripristino consiste nel creare i dati e i file di registro se non esistono.
Puoi rendere la creazione del file di dati quasi istantanea abilitando l'inizializzazione del file istantanea che salta l'inizializzazione zero ma non si applica ai file di registro. Ciò significa che il ripristino deve creare tutti i file di registro esistenti al momento dell'esecuzione del backup completo (o creati durante il periodo di tempo coperto da un backup del registro delle transazioni) e inizializzarli a zero. Se viene creato un secondo file di registro e si dimentica di eliminarlo nuovamente, l'inizializzazione zero durante un'operazione di ripristino di emergenza si aggiungerà al tempo di inattività totale. Questo non è un problema di prestazioni del carico di lavoro, ma influisce sulla disponibilità del server nel suo insieme.
Ripristino da un'istantanea del database
L'ultimo problema nel mio elenco è in realtà un bug in SQL Server. Se utilizzi uno snapshot del database come metodo per ripristinare rapidamente un punto nel tempo noto senza dover ripristinare i backup (noto come ripristino dello snapshot), puoi risparmiare molto tempo. Tuttavia, c'è un grande svantaggio.
Quando il database viene ripristinato dallo snapshot del database, il registro delle transazioni viene ricreato con due VLF da 0,25 MB. Ciò significa che dovrai riportare il registro delle transazioni alle dimensioni e al numero ottimali di VLF (o aumenterà automaticamente), con tutte le pause di inizializzazione e carico di lavoro pari a zero di cui ho discusso in precedenza. Chiaramente non il comportamento desiderato.
Riepilogo
Come puoi vedere da questo post e dai miei due post precedenti, ci sono molte cose che possono portare a scarse prestazioni del registro delle transazioni, che quindi hanno un effetto a catena sulle prestazioni del tuo carico di lavoro complessivo.
Se puoi occuparti di tutte queste cose, avrai registri delle transazioni sani. Ma non finisce qui perché devi assicurarti di monitorare i registri delle transazioni in modo da essere avvisato di cose come la crescita automatica e le latenze I/O di lettura e scrittura eccessive. Tratterò come farlo in un post futuro.
