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
Interessante!!! Quindi la probabilità che, a fronte di un errore hardware, si possano avere archivi inconsistenti risulta minima!
RispondiEliminaUn buon metodo per garantire continuità di servizio e consistenza degli archivi!