Durante tutta la mia carriera come professionista dei dati, sia all'interno di Microsoft che come consulente, ho scoperto che una delle parti più fraintese di un database di SQL Server è il registro delle transazioni. La mancanza di conoscenza di come funziona e di come deve essere gestito il registro delle transazioni, o solo semplici idee sbagliate, possono portare a tutti i tipi di problemi di produzione, tra cui:
- Il registro delle transazioni cresce senza controllo e potenzialmente esaurisce lo spazio
- Problemi di prestazioni dovuti alla riduzione ripetuta del registro delle transazioni
- Problemi di prestazioni dovuti a un problema noto come frammentazione VLF , di cui ho parlato in questo post
- L'impossibilità di ripristinare il momento desiderato utilizzando i backup del registro delle transazioni
- L'impossibilità di eseguire un backup del registro finale durante il ripristino di emergenza (per una spiegazione dei backup del registro finale, vedere qui)
- Vari problemi relativi ai failover e al ripristino delle prestazioni
Con questo post, sto iniziando una serie occasionale sul registro delle transazioni e su come funziona e dovrebbe essere gestito, e nel corso del suo corso tratterò tutti i problemi sopra. In questo post spiegherò cos'è la registrazione e perché è richiesta.
Terminologia di base sulla registrazione
Quando parlo di qualsiasi meccanismo in SQL Server, trovo che c'è un problema di gallina e uova in cui devo usare una parola o una frase prima di averla spiegata. Per evitare questo problema in questa serie, inizierò spiegando una terminologia che deve essere utilizzata quando si discute della registrazione e approfondirò molti di questi termini man mano che la serie avanza.
Transazione, impegno e rollback
Una transazione comprende una modifica o un insieme di modifiche a un database. Ha un inizio definito e una fine definita. L'inizio è quando viene utilizzata un'istruzione BEGIN TRANSACTION o SQL Server avvia automaticamente una transazione. La fine può essere una di quattro cose:
- La transazione viene eseguita quando viene eseguita un'istruzione COMMIT TRANSACTION
- La transazione viene eseguita quando SQL Server esegue automaticamente il commit della transazione nel caso di una transazione con commit automatico
- La transazione termina il rollback dopo l'esecuzione di un'istruzione ROLLBACK TRANSACTION
- Il rollback della transazione termina dopo che si è verificato un problema e SQL Server ha eseguito il rollback automatico della transazione
Quando viene eseguito il commit di una transazione, le modifiche apportate dalla transazione vengono finalizzate nel database e sono durevoli nel registro delle transazioni di SQL Server su disco. Nota che ho detto "nel registro delle transazioni". Le modifiche effettive alle pagine dei file di dati in memoria *non* vengono scritte su disco quando la transazione viene confermata. Non è necessario che siano resi durevoli nei file di dati perché le modifiche sono già durevoli nel registro delle transazioni. Alla fine, le pagine del file di dati verranno scritte su disco da un'operazione di checkpoint.
Al contrario, quando una transazione esegue il rollback, le modifiche ai dati effettuate dalla transazione non sono più presenti nel database. Ci saranno ancora alcune modifiche fisiche nel database, poiché il rollback di una transazione significa eseguire più modifiche, ma puoi pensare a una transazione di rollback come se non avesse influito sui dati nel database.
I checkpoint e le operazioni di rollback sono argomenti degni dei loro stessi post, quindi li spiegherò più avanti nella serie.
Discuterò questi tre termini in modo molto più approfondito nel tutorial Introduzione alle transazioni di SQL Server sul blog SentryOne.
Registrazione, record di registro e registro delle transazioni di SQL Server
La registrazione significa semplicemente creare una descrizione durevole di una modifica a un database, quasi sempre nel contesto di una transazione. Quando viene apportata una modifica, la modifica viene descritta in un record di registro. Un record di registro di solito contiene informazioni sufficienti per consentire la riproduzione della modifica nel database o il rollback nel database, se necessario.
Questo record di registro sarà inizialmente in memoria e può essere scritto su disco prima del commit della transazione, ma deve essere assolutamente scritto su disco prima la transazione può terminare il commit, altrimenti la transazione non sarebbe duratura. Un'eccezione a questa regola è quando la durata ritardata è abilitata, di cui Aaron Bertrand discute in questo post.
I record di registro sono archiviati nel registro delle transazioni (uno o più file di registro su disco), che ha un'architettura interna alquanto complessa, e ne parlerò e molto altro sui record di registro nel prossimo post della serie.
Ripristino da crash
Un arresto anomalo è il punto in cui SQL Server si arresta in modo imprevisto e non è stato possibile arrestare correttamente i vari database modificati (assicurandosi che tutte le pagine dei file di dati modificate vengano scritte su disco e che il database sia contrassegnato come chiuso in modo corretto).
All'avvio di SQL Server, controlla tutti i database per verificare se non sono stati contrassegnati come chiusi correttamente. Se ne trova uno, il database deve eseguire il ripristino di emergenza. Ciò garantisce quanto segue:
- Per qualsiasi transazione eseguita prima dell'arresto anomalo, assicurati che tutte le modifiche nella transazione si riflettano nel database (ad esempio, riproduci la transazione)
- Per qualsiasi transazione che non è stata confermata prima dell'arresto anomalo, assicurati che nessuna delle modifiche apportate alla transazione si rifletta nel database (ad esempio, annulla la transazione)
In altre parole, il ripristino da crash rende un database transazionalmente coerente dal momento in cui si è verificato l'incidente. Viene utilizzato il ripristino da crash:
- Quando SQL Server si avvia e trova un database che deve essere ripristinato
- Durante un failover su una copia secondaria di un database
- Al termine di una sequenza di ripristino che coinvolge i backup (vedi qui)
Il ripristino da crash è un processo complesso e richiede altri post nella serie prima che io possa spiegarlo in modo approfondito.
Perché è richiesta la registrazione?
Il motivo più semplice per la registrazione consiste nel consentire al database di SQL ServerSQL Server di rendere le transazioni durature, in modo che possano essere ripristinate durante il ripristino da arresto anomalo o, se necessario, ripristinate durante le normali operazioni del database. Se non ci fosse la registrazione, un database sarebbe transazionale incoerente e forse strutturalmente danneggiato dopo un arresto anomalo.
Senza la registrazione, tuttavia, non sarebbe possibile una serie di altre funzionalità in SQL Server, tra cui:
- Backup dei dati che possono essere ripristinati in modo coerente
- Backup del log delle transazioni di SQL Server che possono essere utilizzati durante un'operazione di ripristino e per implementare il log shipping
- Replica, che si basa sulla capacità di raccogliere le transazioni dal registro delle transazioni
- Change Data Capture, che utilizza l'agente di lettura log di replica transazionale per raccogliere le modifiche dal log delle transazioni
- Mirroring del database e gruppi di disponibilità, che si basano sull'invio di record di registro a copie secondarie del database per la riproduzione
SQL Server (e tutti i server di database simili) utilizza ciò che viene chiamato registrazione write-ahead . Ciò significa che le descrizioni delle modifiche devono essere scritte su disco prima delle modifiche stesse per garantire la possibilità di ripristinare correttamente un database in modo anomalo. Se una modifica è stata scritta in un file di dati prima dei record di registro che la descrivono e SQL Server si è arrestato in modo anomalo, non sarebbe possibile sapere cosa eseguire il rollback e il database sarebbe incoerente. Questo ordinamento è invariante, indipendentemente dal livello di isolamento, dal tipo di transazione o dall'utilizzo della funzione di durabilità ritardata. Registra prima i record, poi le pagine di dati.
Solo la punta dell'iceberg
Come puoi vedere da questo post introduttivo, una quantità enorme va nel registro delle transazioni e accede a un database di SQL Server, e tutto ciò che ho fatto finora è definire una terminologia di alto livello e spiegare perché è necessaria la registrazione. Spero che ti unirai a me mentre mi allontano e approfondisco man mano che la serie avanza!
