SQL Server, il database recovery e le fasi di Analysis, Redo e Undo

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

Comments

Post a Comment

I Post più popolari

SQL Server, execution plan and the lazy spool (clearly explained)

Image
Hi Guys, Welcome back! In one of the last posts we talked about Table Spool . We had explained what Spool are for by telling the somewhat curious story of the halloween problem . Here we specifically talked about a type of spool called Eager Spool   You can look to the execution plan below where the eager Spool is used to avoid the halloween problem in classic query of the "salary increase".. i suggest Well, if the story of the eager spool intrigued you, today instead we will speak about another type of Spool, the Lazy Spool . The Lazy spool Let's take a small step back. So, what is a Spool operation?  As we have already understood a spool operation is simply a temporary storage of data . Data are read from a source table and stored inside a worktable in the Tempdb database . While an Eager Spool is used to prevent the Halloween problem, the Lazy Spool is instead used to store data that will later be needed again when running a query . So, when a Lazy spool is used?    I
Read more

SQL Server, datetime vs. datetime2

Image
Hi guys, This time, in this post we will speak about datetime and datetime2 datatypes. We will talk about the pros and cons. We will talk about all the differences between the two types of data. Write me in the comments which type of data do you prefer between the two. Enjoy the reading!     Datetime Vs. Datetime2 First of all, it must be said that the datatype datetime is certainly the best known native format for storing a date in SQL Server. However, Microsoft has also been introducing a new type of data for many years now, also used to manage dates. It is in fact from SQL server 2008 that it is present in datetime2 data type. This "new" type of data was born primarily to have higher accuracy . Let's in fact talk about ... precision ! Datetime Certainly the datetime data type is not very precise and certainly there are many cases in which its precision is simply not sufficient. Let's see it with an example. Open the SQL Management studio (SSMS) and write the fo
Read more

La clausola NOLOCK. Approfondiamo e facciamo chiarezza!

Image
Ehi ragazzi! La domanda è di quelle importanti! Siete pronti per scoprire tutto ma proprio tutto sulla clausola NOLOCK?   Se la riposta è si, allora seguitemi! Oggi ne spiegheremo il funzionamento in maniera approfondita. Faremo una introduzione al concetto di tipi di LOCK Ed infine vedremo come mai una SELECT ne può bloccare un'altra. Non vi nascondo che il motivo di questo articolo è fare chiarezza. Su questo argomento si sentono spesso affermazioni “curiose” ma tra le tante questa è la prima: “ uso la SELECT con l’opzione WITH(LOCK) così non blocco le altre tabelle ”.   Ma, è proprio vero quanto affermato? Beh oggi facciamo il punto!   Buona lettura!     La clausola NOLOCK Diciamo subito per iniziare che cos’è la NOLOCK. NOLOCK è il nome di una clausola che è possibile specificare all’interno di uno statement di tipo SELECT utilizzando la seguente sintassi: SELECT * FROM TABELLA WITH (NOLOCK) Si noti che non possiamo utilizzare questa cl
Read more