Pratica SQL Server Blog

Il danneggiamento del database SQL Server Parte IV: pagina di verifica CHECKSUM

In post precedenti all'interno di questa serie, abbiamo già visto come non si può davvero prevenire la corruzione. Invece, in modo da essere in grado di affrontare meglio la corruzione, è necessario essere in grado di rilevare tempestivamente. A tal fine, ci sono in realtà un certo numero di modi diversi per consentire in anticipo (o early-ish) individuazione di corruzione quando succede. E, in questo post, vedremo l'utilizzo di CHECKSUM pagina di verifica come il primo di questi metodi.

CHECKSUM ABILITAZIONE PER LA PAGINA DI VERIFICA

Quando configurato correttamente, SQL Server può immediatamente individuare quando i dati che si sta tirando fuori dei dischi è stato salvato in modo improprio - o danneggiati. Per abilitare questa funzionalità, è sufficiente a garantire che i database desiderati sono configurati per utilizzare l'opzione CHECKSUM per la pagina di verifica - che è possibile impostare su SQL Server 2005 e superiori.

Per fare questo, è sufficiente interrogare il server come segue, e rivedere i nomi di tutti i database restituiti - in quanto non sono configurati per la verifica CHECKSUM:

UTILIZZO maestro
 GO

SELECT  NOME 
 , page_verify_option_desc
 FROM master . sys . database
 WHERE page_verify_option_desc ! =  'CHECKSUM' 
GO

Successivamente, per attivare (o toggle) questi database da utilizzare la verifica del checksum, eseguire l'istruzione seguente per database che volete a 'convertire' ad utilizzare la verifica del checksum:

ALTER  DATABASE  < dbnameHere >

SET PAGE_VERIFY CHECKSUM 
GO

Ovviamente, se hai un sacco di basi di dati che devono essere 'attivato', è possibile cablare un cursore semplice, o utilizzare script di un povero come la seguente:

- Passare alla produzione del testo: CTRL + T 
SET  NOCOUNT  ON 
DECLARE @ linefeed CHAR ( 2 ) 
SET @ linefeed =  CHAR ( 13 )  +  CHAR ( 10 )

SELECT  'ALTER DATABASE'  +  NOME  +  'SET PAGE_VERIFY CHECKSUM'  + @ linefeed +  'GO'  + @ linefeed + @ avanzamento riga
 FROM maestro . sys . database
 WHERE page_verify_option_desc ! =  'CHECKSUM'

Quale è quindi possibile eseguire - e quindi copiare / incollare l'output di tale query in un altro (o lo stesso) query finestra per eseguire i risultati - come questo vi darà una serie di istruzioni ALTER per database come necessario.

CHECKSUM - sotto le coperte Una volta PAGE_VERIFICATION è impostata su CHECKSUM, SQL Server transizione verso un nuovo mezzo di controllo, o la verifica che le pagine scritte su disco sono ora liberi la corruzione quando sono riletto di nuovo in memoria. Come documentazione in linea recita:

CHECKSUM
Calcola un checksum sul contenuto dell'intera pagina e archivia il valore nell'intestazione di pagina quando una pagina viene scritta su disco. Quando la pagina viene letta dal disco, il checksum viene ricalcolato e confrontato con il valore di checksum archiviato nell'intestazione della pagina. Se i valori non corrispondono, il messaggio di errore 824 (che indica un errore di checksum) è riportato sia nel log degli errori di SQL Server e il registro eventi di Windows. Un errore di checksum indica un I / O problema di percorso. Per determinare la causa principale richiede un esame di hardware, driver e firmware, BIOS, driver di filtro (ad esempio software antivirus), e di I / O. componenti del tracciato.

Naturalmente, quando si passa a un database di oltre all'utilizzo di CHECKSUM c'è NON qualche processo magico o operazione che passa attraverso e 'scrive' checksum nelle vostre pagine esistenti. Se ci fosse, alternando questa opzione, ovviamente, potrebbe causare alcuni problemi brutte. Ma, invece, dal momento che questo cambiamento è effettivamente un 'meta-dati', che indica a SQL Server per iniziare a utilizzare un nuovo comportamento (ad esempio, funzionalità CHECKSUM per scritture e letture di pagine CHECKSUM'd in precedenza), si può tranquillamente passare questa modifica al grazioso molto qualsiasi momento e senza timore di rallentare il vostro sistema.

Naturalmente, poiché questo, a sua volta, significa che si può avere gocce di dati esistenti / vecchio che è stato ovaiole in giro senza CHECKSUM configurato, che i dati (oi dati relativi a queste pagine) non finirà per ottenere valori di checksum fino a che i dati è finalmente tirato in SQL Server e poi ri-scritto. Di conseguenza, se si vuole "forzare" checksum nelle tue pagine, avrai bisogno di fare vere e proprie ricostruzioni di indice o altre modifiche che costringono tutti i dati per essere tirato dentro e poi riscritto. Fortunatamente, però, CHECKSUM è già attivata per impostazione predefinita in nuovo SQL Server 2005 e oltre database. Come tale, le preoccupazioni / preoccupazioni elencate in questo post di 'conversione' di un database di utilizzare la verifica del checksum si applicano solo ai database che sono stati volutamente impostato per utilizzare un'opzione PAGE_VERIFICATION diverso CHECKSUM (che è possibile, ma non ha senso) o per SQL Server2000 e al di sotto dei database che sono stati migrati a SQL Server 2005 e soprattutto - perché lo spostamento database meno recenti di nuovi host / server non comporta alcun cambiamento impliciti alle impostazioni PAGE_VERIFICATION.

I VANTAGGI DI UTILIZZARE CHECKSUM PER PAGE_VERIFICATION

Come afferma Books Online, con la verifica del checksum sul posto, SQL Server genererà il messaggio di errore 824 (errore di checksum) ogni volta che ora rileva problemi CHECKSUM. Certo, ciò non significa che ti cattura subito la corruzione come avviene (dal checksum vengono ricalcolati per questo errore quando i dati vengono riletti in - invece di quando si è scritto come una tale operazione avrebbe avuto enormi conseguenze IO) - ma vi verrà comunicata non appena accade. A condizione, naturalmente, che hai una sorta di meccanismo in atto per avvisare l'utente di casi in cui viene generato il messaggio di errore 824 - di cui parleremo affrontare nel nostro prossimo post.

Corso SQL Server - Corso Hyper-V -Corso Windows Server –

 Certificazione Microsoft