Nel mio precedente post sulla semplificazione delle operazioni del registro delle transazioni, ho discusso due delle cause più comuni di generazione di record di registro aggiuntivi:peso morto da indici non cluster inutilizzati e operazioni di divisione della pagina (che causano la frammentazione dell'indice). Supponendo che tu abbia letto quel post, ho detto che ci sono problemi più sottili che possono essere dannosi per le prestazioni del registro delle transazioni e li tratterò qui.
Tante, tante piccole transazioni
Ogni tanto SQL Server svuota una parte del registro delle transazioni su disco. Si verifica uno svuotamento del registro ogni volta che:
- Viene generato un record di log del commit della transazione.
- Un record di registro di interruzione della transazione viene generato al termine del rollback di una transazione.
- 60 KB di record di registro sono stati generati dal precedente svuotamento del registro.
Il più piccolo flush del registro possibile è un singolo blocco di registro da 512 byte. Se tutte le transazioni in un carico di lavoro sono molto piccole (ad es. inserendo una singola riga di tabella piccola), si verificheranno molti svuotamenti di log di dimensioni minime. Gli svuotamenti dei log vengono eseguiti in modo asincrono, per consentire una discreta velocità effettiva del log delle transazioni, ma esiste un limite fisso di 32 I/O simultanei di svuotamento dei registri in qualsiasi momento (portato a 112 in SQL Server 2012).
Ci sono due possibili effetti che questo potrebbe avere:
- In un sottosistema di I/O a prestazioni lente, il volume delle minuscole scritture del registro delle transazioni potrebbe sovraccaricare il sottosistema di I/O causando scritture a latenza elevata e conseguente degrado del throughput del registro delle transazioni. Questa situazione può essere identificata da latenze di scrittura elevate per il file di registro delle transazioni nell'output di sys.dm_io_virtual_file_stats (vedi i link demo all'inizio del post precedente)
- Su un sottosistema di I/O ad alte prestazioni, le scritture possono essere completate in modo estremamente rapido, ma il limite di 32 I/O simultanei di flush del registro crea un collo di bottiglia quando si tenta di rendere i record di registro durevoli su disco. Questa situazione può essere identificata da basse latenze di scrittura e da un numero quasi costante di scritture del log delle transazioni in sospeso vicino a 32 nell'output aggregato di sys.dm_io_pending_io_requests (vedi gli stessi link demo).
In entrambi i casi, allungare le transazioni (che è molto controintuitivo!) può ridurre la frequenza degli svuotamenti del registro delle transazioni e aumentare le prestazioni. Inoltre, nel caso n. 1, può essere utile passare a un sottosistema I/O con prestazioni superiori, ma può portare al caso n. 2. Con il caso n. 2, se le transazioni non possono essere prolungate, l'unica alternativa è suddividere il carico di lavoro su più database per aggirare il limite fisso di 32 I/O simultanei di flush del log o eseguire l'aggiornamento a SQL Server 2012 o versioni successive.
Crescita automatica del registro delle transazioni
Ogni volta che viene aggiunto nuovo spazio al registro delle transazioni, deve essere inizializzato a zero (scrivendo zero per sovrascrivere l'utilizzo precedente di quella parte del disco), indipendentemente dal fatto che la funzione di inizializzazione del file istantaneo sia abilitata o meno. Questo vale per la creazione, la crescita manuale e la crescita automatica del registro delle transazioni. Mentre è in corso l'inizializzazione zero, i record di registro non possono essere scaricati nel registro, quindi la crescita automatica durante un carico di lavoro che modifica i dati può portare a un notevole calo della velocità effettiva, soprattutto se la dimensione della crescita automatica è impostata su grande ( diciamo gigabyte o lasciato al 10% predefinito%.
La crescita automatica dovrebbe quindi essere evitata, se possibile, consentendo la cancellazione del registro delle transazioni in modo che ci sia sempre spazio libero che può essere riutilizzato per nuovi record di registro. La cancellazione del registro delle transazioni (nota anche come troncamento del registro delle transazioni, da non confondere con la riduzione del registro delle transazioni) viene eseguita dai backup del registro delle transazioni quando si utilizzano le modalità di ripristino Completo o Registrato in blocco e dai punti di controllo quando si utilizza la modalità di ripristino semplice.
La cancellazione del registro può avvenire solo se nulla richiede la cancellazione dei record di registro nella sezione del registro delle transazioni. Un problema comune che impedisce la cancellazione del registro è avere transazioni di lunga durata. Fino a quando una transazione non esegue il commit o il rollback, tutti i record di registro dall'inizio della transazione in poi sono necessari nel caso in cui la transazione venga ripristinata, inclusi tutti i record di registro di altre transazioni che sono intervallati da quelli della transazione di lunga durata. Le transazioni di lunga durata potrebbero essere dovute, ad esempio, a una progettazione scadente, codice in attesa di input umano o uso improprio di transazioni nidificate. Tutti questi possono essere evitati una volta identificati come un problema.
Puoi leggere di più su questo qui e qui.
Funzioni ad alta disponibilità
Alcune funzionalità ad alta disponibilità possono anche ritardare la cancellazione del registro delle transazioni:
- Il mirroring del database e i gruppi di disponibilità quando vengono eseguiti in modo asincrono possono creare una coda di record di registro che non sono stati ancora inviati alla copia ridondante del database. Questi record di registro devono essere conservati fino al momento dell'invio, ritardando la cancellazione del registro delle transazioni.
- La replica transazionale (e anche Change Data Capture) si basa su un processo dell'agente di lettura log per eseguire periodicamente la scansione del registro delle transazioni alla ricerca di transazioni che modificano una tabella contenuta in una pubblicazione di replica. Se l'agente di lettura del registro rimane indietro per qualsiasi motivo, o viene fatto eseguire di proposito di rado, tutti i record di registro che non sono stati scansionati dal lavoro devono essere conservati, ritardando la cancellazione del registro delle transazioni.
Durante l'esecuzione in modalità sincrona, il mirroring del database ei gruppi di disponibilità possono causare altri problemi con il meccanismo di registrazione. Utilizzando il mirroring sincrono del database come esempio, qualsiasi transazione che esegue il commit sull'entità non può effettivamente tornare all'utente o all'applicazione finché tutti i record di registro generati non sono stati inviati correttamente al server mirror, aggiungendo un ritardo di commit sull'entità. Se la dimensione media della transazione è lunga e il ritardo è breve, ciò potrebbe non essere evidente, ma se la transazione media è molto breve e il ritardo è piuttosto lungo, ciò può avere un effetto notevole sul throughput del carico di lavoro. In tal caso, è necessario modificare gli obiettivi di prestazioni del carico di lavoro, modificare la tecnologia ad alta disponibilità in modalità asincrona oppure aumentare la larghezza di banda della rete e la velocità tra il database principale e quello ridondante.
Per inciso, lo stesso tipo di problema può verificarsi se il sottosistema di I/O stesso è sottoposto a mirroring sincrono, con un potenziale ritardo per tutte le scritture eseguite da SQL Server.
Riepilogo
Come puoi vedere, le prestazioni del registro delle transazioni non riguardano solo la generazione di ulteriori record del registro delle transazioni:esistono anche molti fattori ambientali che possono avere un effetto profondo.
La conclusione è che l'integrità e le prestazioni del registro delle transazioni sono di fondamentale importanza per mantenere le prestazioni complessive del carico di lavoro. In questi due post ho descritto in dettaglio le principali cause dei problemi di prestazioni del registro delle transazioni, quindi spero che sarai in grado di identificare e correggere quelli che hai.
Se vuoi saperne di più sulle operazioni del registro delle transazioni e sull'ottimizzazione delle prestazioni, ti consiglio di dare un'occhiata al mio corso di formazione online di 7,5 ore su registrazione, ripristino e registro delle transazioni, disponibile tramite Pluralsight.
