Carissimi lettori di nuovo ben trovati!
Nello scorso articolo (Qui) abbiamo imparato ad utilizzare gli Extended Event di SQL Server per tracciare in profondità eventi non disponibili tramite il Profiler.
Lo abbiamo fatto per utilizare oggi questo stesso metodo così da raccontarvi cosa succede durante il processo di recovery del database.
Cercheremo di raccontarlo nel modo più semplice possibile al costo di tralasciare qualche aspetto tecnico che magari riprenderemo in futuro.
Buona lettura!
Database recovery e le fasi di Analysis, Redo e Undo
Se avete avuto la necessità di eseguire un riavvio della istanza di SQL Server vi sarete accorti sicuramente di quanto tempo questo processo impieghi .
Ma quali operazioni SQL Server effettua durante questo fondamentale processo?
Per scoprirlo (e per effettuare assieme questa prova) occorrerà crearsi un Extended Event il quale estragga i seguenti tre eventi:
- database_recovery_progress_report
- database_recovery_times
- database_recovery_trace
Avete fatto?
Se si allora sarà sufficiente attivarlo per iniziare a registrare i nostri eventi.
Adesso eseguiamo tramite SMSS le seguenti operazioni:
- Inseriamo alcune righe in una tabella
- Apriamo una transazione
- Inseriamo altre righe nella stessa tabella.
- Infine anzichè chiudere la transazione riavviamo l'instanza di SQL Server!
Facciamo ora doppio click sul nome del package (qui package0.event_file)
Et voilà!
Dalla griglia che si aprirà possiamo osservare l'elenco di tutte le operazioni effettuate.
Una prima cosa che occorre dire è che il recovery è un processo a tre fasi comunemente dette Analysis, Redo e Undo.
In realtà prima della fase di Analysis vengono eseguiti altre attività.
Se osservate infatti le righe della griglia precedenti all'event sequence 11 vedrete che vengono letti i virtual log files.
Ma cosa sono i virtual log files?
I virtual log files sono suddivisioni logiche del file di log del database (che altro non è che il file con estensione ldf associato al nostro database)
Inutile dire che questo file di log è di importanza fondamentale per SQL Server.
Infatti dovete tenere a mente un concetto importante:
SQL Server adotta un logica detta WAL o Write Ahead logging: la modifica da apportare ai dati prima viene scritta sul log delle transazioni. La scrittura su disco avviene invece successivamente.
Dalla sequenza 12 alla sequenza 29 avviene la prima fase detta di fase di Analysis.
Durante questa fase dalla lettura dei virtual log files vengono generate due tabelle dette DTP e ATT.
La tabelle delle Dirty page (DTP) conterrà tutte le pagine (ed i relativi LSNs) che potrebbero essere "Dirty" ovvero presenti essere nel virtual log file ma non ancora scritte sul disco.
Sarà la successiva fase di Redo a scriverle sul disco.
La tabella delle transazioni attive (ATT) invece conterrà le transazioni che non sono ancora state committate al momento del crash.
Sarà la fase di Undo a processare la tabella delle transazioni attive.
Dalla sequenza 30 alla sequenza 50 possiamo notare la Fase di Redo
Durante questa fase viene effettuato il rolling forward.
In pratica viene letta la tabella delle Dirty Pages e tutte la modifiche scritte sul log delle transazioni ma non ancora scritte sul disco vengono materializzate.
Al termine di questa fase ci troviamo nello stesso stato in cui ci trovavamo prima del crash.
Infine dalla sequenza 51 fino alla 91 possiamo osservare la Fase di Undo
Durante Questa fase viene letta la tabella ATT che contiene le transazioni attive al momento del crash.
Di ogni transazione attiva viene fatto il rollback.
Dopo questa fase il database tornerà nuovamente accessibile.
Per oggi è tutto! Alla prossima!
Luca Biondi @ SQLServerPerformance blog! 
Next post: SQL Server, il database recovery e le fasi di Analysis, Redo e Undo
previous post: SQL Server e gli Extended Event