Pagine

domenica 17 giugno 2012

SQL Server 2012: Automatic page repair e Always On

L'Always On consente di avere molti vantaggi tra cui l'automatic page repair. Con l'utilizzo e attività di scrittura nei DB si possono verificare errori che rendono inutilizzabili le data pages e di conseguenza i dati, ma grazie all'always on è possibile far si che SQL, automaticamente, ponga rimedio all'anomalia.
Purtroppo non tutte le data pages sono riparabili. Per esempio la File header page (page ID 0), la database boot page (page ID 9) e le Allocation pages GAM, SGAM e PFS non possono essere riparate automaticamente.
Vediamo come funziona. Nei post precedenti ho configurato Always On , backup distribuiti, Listener e Read only routing grazie ai quali ho ridondato un database chiamato MyTestDatabase contenente una tabella con questa struttura e popolata con 10000 record :
Create table MyTestTable
(
 id int identity primary key,
 valore varchar(50)
)

;with CtePopolaTab
as
(Select 1 R union All Select 1 R),
Cte4 as (Select A.* from CtePopolaTab A,CtePopolaTab B),
Cte16 as (Select A.* from Cte4 A,Cte4 B),
Cte256 as (Select A.* from Cte16 A,Cte16 B),
Cte65536 as (Select A.* from Cte256 A,Cte256 B),
[Result] as (Select ROW_NUMBER() over(Order by r) Riga from Cte65536 )
Insert Into MyTestTable (valore)
Select 'Valore Riga ' + CAST(Riga as varchar(10)) from Result
Where Riga <= 10000

--con il backup impongo il checkpoint 
backup database [MyTestDatabase] to disk = '\\win8dc\MySharedFolderForAvailabiltyGroup\testPageRestore.Bak'


A questo punto mi serve reperire il numero di pagina che contiene la riga con id = 4843 per poterla poi danneggiare. Con questa istruzione troviamo l'id della pagina contenente la nostra riga 4843:
SELECT t1.PageName , 
       COUNT( * )AS num
  FROM  dbo.MyTestTable t 
  CROSS APPLY
    ( 
    SELECT REPLACE( sys.fn_PhysLocFormatter( %%Physloc%% ) , ':' , '.' )
    AS PageName 
    )t1
  WHERE id = 4843
  GROUP BY t1.PageName;
GO













La pagina ha pid = 237.

Per poter alterare il file mdf però devo sganciarlo da SQL, quindi sospendo l'always On e fermo il servizio SQL.












Per danneggiare la page pid 237 devo aprire il file mdf del db con un'editor esadecimale e posizionarmi sull'indirizzo 1941504 (decimale) dato da numeropagina * 8192.





La modifico rendendo inconsistente il checksum





A questo punto riattivo l'istanza di SQL e faccio il resume data movement dell'always on.













Provo a fare una ricerca puntuale sulla riga id 4843 che risiede nella pagina inutilizzabile. SQL Segnala l'errore:





La pagina è persa ? Fortunatamente no. Rieseguendo la query l'always on recupera la pagina dalla replica secondaria e ripara quella del nodo primary:










Come si dice ? Un vero sistema High Availability !! ;-)
Ciao
Luca

1 commento:

  1. Interessante!!! Quindi la probabilità che, a fronte di un errore hardware, si possano avere archivi inconsistenti risulta minima!
    Un buon metodo per garantire continuità di servizio e consistenza degli archivi!

    RispondiElimina