Q&A SQL Problemi di checksum, scelta del modello di recupero corretto e altro ancora

Paul S. Randal

QSono un amministratore di SharePoint e di recente è scoperto che uno dei miei database del contenuto è danneggiato quando la coerenza mensile verifica errori rilevati. È ricondotto un controller RAID difettoso e, dopo aver eseguito alcune ricerche, si sta attivate checksum nelle pagine di database. La mia domanda è: come è possibile stabilire quando c'è un problema di checksum senza attendere fino al piano di manutenzione mensile?

AEsistono alcune operazioni che è possibile eseguire. In primo luogo, è possibile aggiungere l'opzione WITH CHECKSUM per i backup. Per i backup completi e differenziali, questa opzione determinerà l'operazione di backup verificare eventuali checksum di pagina viene visualizzato e genereranno un errore se viene rilevato un danneggiamento. (Descritto in questo in dettaglio nell'articolo del mese scorso, "Informazioni su SQL Server backup".)

In secondo luogo, prendere in considerazione in esecuzione i controlli di coerenza più frequentemente di mensile. Si consiglia di esecuzione almeno settimanale qualche forma di controllo di coerenza sia un DBCC CHECKDB sul database o magari una copia del database ripristinata. Che, naturalmente, sarà variano a seconda del livello comfort con il sottosistema di I/O.

In terzo luogo, è possibile aggiungere alcuni avvisi di Agente SQL. È possibile impostare un avviso per generare su numerosi fattori, ad esempio un numero specifico di errore generati da SQL Server, un errore con una particolare gravità la generazione o di un contatore delle prestazioni attraversare una soglia. Questa funzionalità fornisce un meccanismo molto potente per monitorare i problemi del server.

Quando viene generato un avviso, un messaggio viene inviato a un "operatore" predefinito utilizzando una o tutte queste opzioni: un messaggio di spostamento, in posta elettronica oppure NET SEND. È possibile utilizzare procedura sp_add_notification la stored procedure per definire un operatore.

Fintanto che i problemi del sottosistema di I/O sono coinvolta, gli errori che si è interessati sono 823 e 824 825. I primi due vengono generati quando si verifica un problema di I/O (in particolare, 824 è quando viene rilevato un checksum di pagina sia interrotto e 825 è quando dispone di SQL Server eseguire un'operazione di lettura più volte prima del completamento). Questi sono tutti i problemi che si desiderano conoscere appena possibile per limitare ulteriormente i danni causati al database (e possibilmente il tempo di inattività per recuperare).

823 e 824 sono entrambi gli 24 errori a livello di gravità è solo un livello di gravità 10 "" messaggio informativo (per ulteriori informazioni, vedere il blog,"825 Un segno di poco nota dell'imminente doom: errore 825.") Per segnalare questi errori, è necessario definire un avviso per tutti gli 24 errori a livello di gravità e uno in particolare per errore 825 (infatti, è buona norma disporre di un avviso per ogni-livello di gravità da 19 a 25).

Per definire gli avvisi effettivi, è possibile utilizzare T-SQL o Management Studio. Di seguito è un esempio del codice T-SQL, per aggiungere un avviso per l'errore 825.

USE msdb;
GO 
EXEC msdb.dbo.sp_add_alert @name = N'825 - Read-Retry Required', 
    @message_id = 825,
    @severity = 0,
    @enabled = 1,
    @delay_between_responses = 0,
    @include_event_description_in = 1,
    @category_name = N'IO Subsystem Error';
GO

È possibile trovare categoria "(per ulteriori informazioni sulla definizione e l'aggiunta di avvisi, incluse una panoramica dettagliata sull'aggiunta di avvisi utilizzando Management Studio, nel mio blog di Agente SQL Bug di piano di manutenzione SQL 2005 SP2 mascheramento danneggiamento)."

QSono un DBA sviluppatore che è responsabile del codice e il database che viene eseguito in. Già stato arguing con alcuni altri sviluppatori di database su come ottenere un valore univoco per identificare le righe della tabella. Si desidera utilizzare un GUID come chiave dell'indice cluster, ma gli altri sono arguing che può causare problemi di prestazioni con indici. È questo true e, in caso affermativo, possono è spiegare perché?

UN Sì, è vero, GUID sono le cause principali di frammentazione dell'indice nei database di SQL Server.

Un GUID è un identificatore univoco globale. In SQL Server, questo è un valore a 16 byte generato in SQL Server o in un' posizione (ad esempio tramite .NET nel client o mid-tier). GUID hanno in genere un valore casuale, a meno che non generato con la funzione NEWSEQUENTIALID introdotta in SQL Server 2005.

Questa funzione produce gli intervalli di GUID, il quale è possibile per risolvere alcuni dei problemi che verrà descritto di seguito. Ma richiede la generazione di un GUID di lato server, che non funziona in molti ambienti di applicazione perché l'identificatore univoco deve essere generato prima di inviare i dati verso il basso il livello dati.

Indipendentemente da dove viene generato il GUID non sequenziale, come la chiave iniziale di un indice significa che, poiché la chiave è essenzialmente casuale, che il punto di inserimento di un nuovo record nell'indice si trova anche casuale, il valore di chiave di un record determina il selezione host nell'indice. Significa inoltre che il GUID di 16 bit sarà presente in ogni riga di ogni indice non cluster come parte del collegamento che consente il motore di archiviazione passare dai record di indice non cluster a record di indice cluster per ottenere valori di colonna per un elenco di selezione query che non sono nell'indice non cluster utilizzato (anche noto come una ricerca di segnalibro).

Come altri record viene inserito in corrispondenza dell'indice, le pagine di archiviare i record occupare. Se inserito un record in una pagina che è già completa (tenere presente che, il valore della chiave determina dove inserire il nuovo record), quindi è necessario suddividere la pagina, con alcuni record, lo spostamento in una pagina appena allocata. Divisione di pagina è un'operazione costosa per eseguire una nuova pagina viene allocata e collegata in corrispondenza dell'indice, e i record vengono spostati nella nuova pagina, determinando la frammentazione.

Divisioni di pagina causare la frammentazione logica dell'indice (influenzando le prestazioni di scansione intervallo) causando il fisici e logici ordine delle pagine dell'indice può essere diverso. Causa inoltre densità di pagina scarsa (dove è presente lo spazio inutilizzato nelle pagine), che comporta lo spazio inutilizzato nelle pagine e l'utilizzo di disco, I/O e memoria insufficiente.

Per ulteriori informazioni sulla frammentazione dell'indice e su come rilevare e rimuovere, vedere il mio articolo dell'agosto 2008 " Suggerimenti per la manutenzione di database valido." Prelievo di una chiave di indice cluster buona esula dall'ambito di questo articolo, verrà lasciare alla mia moglie, l. Kimberly Tripp, per illustrare. Vedere il suo blog eccellente sull'argomento, viene anche ulteriori dettagli su GUID e strutture di indice cluster "( GUID come PRIMARY KEY e/o la chiave di clustering.")

QStrategia di elevata disponibilità consiste nell'utilizzare un paio di server secondari della distribuzione dei log. Il team di gestione è pressuring per utilizzare alcuni server ridondanti per salvare su spese di capitale. Mia idea consiste nell'utilizzare i server secondari per consentire la segnalazione query da eseguire, avrebbe inoltre il vantaggio di carico il carico di lavoro report dal server primario. Quali problemi si potrebbe eseguire in questo modo?

UN Questo tipo di scenario è diventato molto più comune nel clima economica corrente, in cui la società non quali server trova aggirare il problema sembra essere inattivo (anche se si sta fornendo una copia ridondante del database).

Come è probabilmente già noto, quando si imposta la distribuzione dei log, è possibile definire come i backup del Registro di transazione sono ripristinati su un server secondario, a WITH NORECOVERY o WITH STANDBY. Il primo non consentire alcun accesso al database, mentre quest'ultimo consente l'accesso in sola lettura al database. Utilizza una modalità speciale in cui viene eseguito di ripristino e il database è coerente mediante transazioni, ma le operazioni eseguite vengono memorizzate in un file di ripristino separato in modo che ulteriori backup del log delle transazioni possono essere ripristinati (tratterò questo in dettaglio il mese successivo in un articolo sull'utilizzo di ripristino).

Per consentire la creazione di report sul server secondario, che si desidera utilizzare WITH STANDBY in modo che le query di creazione di report possono connettersi al database. Una volta è necessario consentire connessioni utente, è immediatamente eseguire backup su alcuni problemi.

In primo luogo, utilizzo l'opzione WITH STANDBY può rendere per il backup del log delle transazioni seeming di richiedere parecchio tempo per ripristinare un server secondario, come il contenuto del file annullamento deve essere rieseguito prima possibile ripristinare il backup del log delle transazioni successivo. Può trattarsi di un problema se il file di annullamento contiene un numero elevato di operazioni.

In secondo luogo, il ripristino di un backup del log delle transazioni non è un'operazione in linea. Non possono essere connesse al database per la durata del ripristino. Ciò significa che tutte le connessioni al server di report secondario devono essere eliminate, quindi riconnessa termine del ripristino. Qui si dispone di un problema: quando si tratta di tempo per ripristinare il successivo backup del log delle transazioni, è terminano le connessioni utente o consentire loro di completare le query? Ecco completamente spetta all'utente.

Una domanda da tenere presenti se si decide di non terminare connessioni: come lungo è consentire le query continuare la prima è interrompere forzatamente li? Più tempo di attesa, il tempo è stato l'ultimo backup del log è stato ripristinato, e il sottostante ulteriormente il database primario quello secondario ottiene. Potrebbe trattarsi di un problema se è quindi necessario eseguire il failover secondaria, poiché può esistere una coda di backup del log in attesa di essere ripristinati per riportare il database quanto aggiornato possibile, riducendo al minimo perdite di dati.

È possibile trovare ulteriori informazioni su queste opzioni, nonché sul monitoraggio dei problemi, quali periodo di tempo dopo l'ultimo ripristino backup del log nel server secondario, nell'argomento della documentazione in linea" Utilizzo di server secondario per l'elaborazione di query."

QCome è possibile scegliere il modello di recupero corretto? Da ciò che ho letto, sembra I devono essere operazioni di massa registrate per limitare le dimensioni del log delle transazioni, ma sembra che le dimensioni del registro ancora continua crescita. È possibile utilizzare una modalità di non utilizzare affatto il Registro di transazione e evitare completamente il problema intero?

UN ne ho sentito più volte le richieste è per un database non registrato, quando nessun record del log delle transazioni viene generato affatto, soprattutto per tempdb, cui persone visualizzazione come database di lavoro perché viene ricreato all'avvio del server.

Fintanto che so, ciò non accade per SQL Server. Le migliori che si ottengono sono la modalità di con registrazione minima delle transazioni di massa (BULK_LOGGED), che drasticamente Taglia verso il basso la quantità di log delle transazioni generato per determinate operazioni (ad esempio ricrea l'indice e il caricamento di massa). Tutti i database, anche tempdb, dispone di necessario un certo livello di registrazione per consentire transazioni eseguire il rollback (vale a dire per annullare tutte le operazioni che facevano parte della transazione) in caso di un utente di annullare l'operazione o un errore che causa l'operazione di eseguire.

Qual è il più importante, per i database ad eccezione di tempdb, è che se si verifica un arresto anomalo del sistema, il database deve essere possibile ripristinare senza uscire da dati incoerenti in modo transazionale o di dal punto di vista strutturale incoerenti (vale a dire danneggiata) database. Si supponga che se non si sono Nessun record di ciò che era stato modifica nel database prima dell'arresto anomalo, come SQL Server dovrebbe eseguire Ripristino? Per ulteriori informazioni sull'utilizzo di registrazione e il ripristino nel mio articolo di febbraio 2009 " Informazioni sulla registrazione e il ripristino in SQL Server."

Per scegliere un modello di recupero, una domanda di override determinerà la scelta: si desidera per eseguire il ripristino "in un momento" o "aggiornate" in caso di emergenza? In tal caso, si prevede di utilizzare il modello di recupero FULL (e, eventualmente, il modello _LOGGED BULK) tanto in tanto. Se non si è interessati a questa operazione, utilizzare il modello di recupero semplice.

Utilizzo di SIMPLE anziché FULL se si desidera ripristinare il database (senza perdere il lavoro dall'ultima del database o backup differenziale) il motivo è che con il modello di recupero con registrazione minima, non è necessario eseguire transazione i backup del log per gestire le dimensioni del log delle transazioni.

A questo punto, vi possono essere altri motivi perché è necessario utilizzare il modello di recupero completo, ad esempio, se si desidera utilizzare database di mirroring (DBM supporta solo il modello di recupero completo) o (registro spedizione supporta entrambi i modelli di recupero con registrazione minima delle transazioni di massa (BULK_LOGGED) e FULL) di distribuzione dei log. In entrambi i casi, sarà necessario assicurarsi che si consegna transazione i backup del log in modo che il registro non aumentano eccessivamente (anche se si finisce eliminazione li).

Detto che è possibile che occasionalmente si desidera utilizzare il modello di recupero con registrazione minima delle transazioni di massa (BULK_LOGGED), anziché costantemente in esecuzione in tale modalità. Infatti, esistono alcune limitazioni acquisizione e ripristino da backup del log quando vi è stata un'operazione di minima registrate nel modello di recupero con registrazione minima delle transazioni di massa (BULK_LOGGED) dopo l'ultimo backup del log delle transazioni. I dettagli sono troppo complessi per illustrare in questa colonna, ma è possibile reperire informazioni su questo e sulla scelta di un modello di recupero in generale, nell'argomento della documentazione in linea" Cenni preliminari sul modello di ripristino."

S. Paul Randal è Managing Director di SQLskills.com, un director internazionali di Microsoft e un MVP di SQL Server. Ha lavorato nel team SQL Server Storage Engine in Microsoft dal 1999 al 2007. Paul ha scritto il comando DBCC CHECKDB/repair per SQL Server 2005 ed era responsabile di Core Storage Engine durante lo sviluppo di SQL Server 2008. Paul è un esperto di ripristino di emergenza, disponibilità e la manutenzione del database e un regolare relatore a conferenze in tutto il mondo. Blog di ha all' SQLskills.com/blogs/paul, ed è possibile ottenere lui Twitter in Twitter.com/PaulRandal.