Domande e risposte su SQL Verifiche della coerenza impreviste, Risoluzione dei problemi relativi all'utilizzo della memoria e molto altro ancora

Paul S. Randal

D ho notato qualcosa di insolito che si verificano poiché è stata spostata parte i database a SQL Server 2005. Ogni volta che il server di avvio, È possibile visualizzare i messaggi del Registro di errore che indica che SQL Server è in esecuzione verifiche della coerenza sul database durante il processo di avvio. Questa operazione viene eseguita per alcuni database, ma non per i database di sistema. I controlli sembrano molto rapidamente eseguire indipendentemente il database è la dimensione e sempre SQL Server viene avviato. È possibile spiegare cosa sta succedendo?

Rpiuttosto alcuni utenti hanno stato richiede informazioni in vari forum in linea. Ecco un esempio di uno dei messaggi del log errore in questione:

2009-06-16 18:12:16.85 spid5s
CHECKDB for database 'master' finished without errors
on 2009-05-12 16:07:15.647 (local time).
This is an informational message only; 
no user action is required.

Certamente ha l'aspetto come eseguito DBCC CHECKDB (che esegue verifiche di coerenza a livello di database) sul "master"database, ma in realtà non è stato. Questo messaggio segnala semplicemente una statistica sul database chiamato il "noti buona ultima"ora.

Da poi SQL Server 2005, ogni volta che l'istruzione DBCC CHECKDB termina coerenza un database senza la ricerca di eventuali errori di coerenza (vale a dire il database è privo di danneggiamento), l'ora in cui DBCC CHECKDB completata è annotato la pagina di avvio del database (una singola pagina del database che sono archiviati metadati importanti informazioni).

Ogni volta un database viene avviato (su database o avvio istanza connessione), la pagina di avvio è controllata per verificare se è disponibile una stored "ultima nota buona"ora, e se in questo modo, viene segnalato nel log degli errori. Sfortunatamente, non è possibile eseguire query di questo valore documentato, ma è possibile utilizzare un numero di comandi non documentati per individuarlo. Reddy Sankar, un MVP, fellow recente blogged un script che verranno segnalati automaticamente.

Le motivazioni di archiviazione di "noti buona ultima"ora è che può essere molto utile per una situazione di ripristino di emergenza per sapere quanto tempo (potenzialmente) un database è stato danneggiato.

Dsi desidera determinare la quantità di memoria di SQL Server viene utilizzato per ogni database. Ho notato che un'istanza di SQL Server 2005 improvvisamente utilizzando quasi tutta la memoria disponibile sul server e si ritiene che c'è un problema in un punto qualsiasi. È possibile scoprire dove questa memoria viene utilizzata da all'interno di SQL Server?

Rla buona notizia è che questo non è probabilmente un problema. SQL Server 2005 verrà utilizzato come quantità di memoria è in grado quando necessario, ma risponderà alle richieste di pressione della memoria del sistema operativo per liberare memoria. L'utilizzo di memoria imprevisto in visualizzazione è probabilmente il pool di buffer di espansione per consentire più del database per essere contenuto in memoria.

Pool di buffer, detto anche cache del buffer, è parte di livello il motore di archiviazione in SQL Server ed è responsabile della gestione di copie in memoria in parti di file di dati nei vari database nell'istanza di SQL Server. Se si avvia una query che richiede la lettura di numerose pagine di database in memoria (ad esempio per una scansione della tabella di grandi dimensioni o un join), il pool di buffer può catturare più memoria del server dal sistema operativo in modo che è possibile espandere. Questo consente di gestire le immagini di pagina aggiuntiva in memoria senza necessariamente eliminare copie di in memoria di altre pagine di database che vengono utilizzati per altre query.

Come un inciso, uno dei vantaggi di aggiunta di più memoria per SQL Server per l'utilizzo è di che il pool di buffer può essere più grande. Questo significa che altri dati possono essere in memoria in qualsiasi momento particolare, potenzialmente con I/o ridotto e migliore velocità effettiva del carico di lavoro.

Esistono altre possibili cause di SQL Server utilizzando molta memoria, per l'istanza se un numero elevato di piani di query diversi da memorizzati in un'altra area di memoria denominata cache dei piani, ma la stima è che si tratta molto probabilmente il pool di buffer, come descritto in precedenza.

In SQL Server 2005, è possibile determinare quale percentuale del pool di buffer viene utilizzato per ogni database utilizzando sys.dm_os_buffer_descriptors la visualizzazione di gestione dinamica. Questa semplice query indicherà quante pagine di 8 KB sono nel pool di buffer per ogni database:

SELECT   
  (CASE WHEN ([is_modified] = 1) THEN 'Dirty'
ELSE 'Clean' END) AS 'Page State',
  (CASE WHEN ([database_id] = 32767) THEN 'Resource Database'
ELSE DB_NAME (database_id) END) AS 'Database Name',
   COUNT (*) AS 'Page Count'FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id], [is_modified]
   ORDER BY [database_id], [is_modified];GO

Illustrata un po' più nel post del blog "interno il motore di archiviazione: Novità nel pool di buffer?."

Per le altre sezioni di memoria utilizzato da SQL Server, è possibile utilizzare il comando DBCC MEMORYSTATUS per monitorare la quantità di memoria l'istanza di SQL Server utilizza un insieme, ma non consente l'utilizzo di memoria su suddivisi per ogni database. Dare un'occhiata articolo 907877, che descrive "come utilizzare il comando DBCC MEMORYSTATUS per monitorare l'utilizzo della memoria in SQL Server 2005."

Dtanto spesso, uno dei database nell'istanza di SQL Server 2005 diventerà "sospetto". È Impossibile accedere al database e lo stato è SUSPECT. In alcuni casi lo stato indica RECOVERY_PENDING. So che ciò è causato da danneggiamento di qualche tipo, ma possibile illustrate realmente significato e la modalità ripristino? In genere è necessario dover ripristinare da backup precedente e la perdita di dati che non sono ideali.

Rè molta confusione su questi due database indica la media, ma si è corretto che è causati da qualche forma di danneggiamento. Entrambe indicano che un'operazione è stata difetto di ripristino di arresto anomalo del sistema.

Se un database non viene correttamente arrestato (in altre parole, in se di esistono transazioni di cui non è stato eseguito il commit all'arresto del database) quindi, quando il database viene avviato nuovamente, deve passare attraverso ripristino arresto anomalo del sistema. Ripristino di arresto anomalo del sistema è il processo di garantire che tutte le transazioni completate al momento del database di arresto vengono applicate correttamente il database e tutte le transazioni che erano di cui non è stato eseguito il commit al momento dell'arresto non vengono applicate in alcun modo nel database.

Per una quantità maggiore spiegazione del funzionamento di ripristino, vedere l'articolo "informazioni sulla registrazione e il ripristino in SQL Server" dal numero di febbraio 2009.

Un database sa se arresto correttamente è stato premuto o meno, queste informazioni vengono memorizzate nella pagina di avvio database descritto nella risposta alla prima richiesta. Se è necessaria l'arresto anomalo del ripristino, quindi il log delle transazioni deve essere accessibile, come memorizza tutti i dettagli di cui necessario riprodurre (commit) e le transazioni di (cui non è stato eseguito il commie) devono eseguire il rollback. Se il log delle transazioni non è disponibile (poiché è stato eliminato, ad esempio), Impossibile avviare il ripristino di arresto anomalo del sistema, mentre lo stato del database diventa RECOVERY_PENDING. Lo stato RECOVERY_PENDING implica il ripristino potrebbe non essere avviato.

Se il log delle transazioni è disponibile, il ripristino di arresto anomalo del sistema viene avviato in esecuzione. Se Impossibile completare per qualsiasi motivo, il database è incoerente in modo transazionale e lo stato diventa come sospetto. Lo stato sospetto implica Ripristino avviato ma non è in grado di completare.

Esistono due motivi Impossibile completare il ripristino. Il primo è danneggiato nel registro delle transazioni, in un record del log delle transazioni non può essere elaborato da SQL Server. Il secondo è danneggiato i file di dati rilevato durante il sistema di ripristino per applicare un record del log delle transazioni a una pagina di database o per annullare gli effetti di un record del log delle transazioni in una pagina di database.

Un altro problema può inserire un database allo stato sospetto. Se una transazione viene annullata da un utente o da un'applicazione e il database rileva danneggiato durante il rollback gli effetti della transazione, è quindi Impossibile completare il roll-back e il database è incoerente in modo transazionale. In questo caso, il database viene automaticamente disconnesso e lo stato impostato su SUSPECT.

Esistono due modi comuni per il ripristino in questa situazione. Il primo consiste nel ripristino da copie di backup aggiornate. Se le copie di backup precedente, è probabile perdita di lavoro e i dati e necessario rivalutare la strategia di backup con lo scopo di backup più spesso per consentire il ripristino senza perdere una grande quantità di dati. Vedere il mio articolo "backup di informazioni su SQL Server" nel numero di luglio 2009 di TechNet Magazine per alcuni suggerimenti sulla pianificazione di una strategia di backup. Se si prevede per la route di ripristino, è consigliabile tentare sempre un backup della coda di log, come illustrato nell'articolo, come in questo modo sarà possibile ripristinare destra fino al punto del problema che ha effettuato il database come sospetto.

Se non sono disponibili, è possibile utilizzare un meccanismo di ripristino della modalità di emergenza. Esaminiamoil post del blog completo che descrive questa funzionalità, viene illustrato l'utilizzo e vengono illustrati alcuni esempi.

Dche è stata il mirroring del database sincrona installato con SQL Server 2005 e abbiamo notato che in alcuni casi può richiedere molto alcuni secondi per il mirroring del database per eseguire il failover quando un problema con il server principale. Credevo che il mirroring del database sincrono utilizzando un controllo del mirroring doveva per fornire il rilevamento degli errori immediata. Che cosa è successo?

Rl'utilizzo di un server di controllo del mirroring con il mirroring del database consente semplicemente al server di mirroring avviare automaticamente il failover. Il controllo del mirroring accetta (o non) con il mirror se è possibile "vedere"il server principale. Se sia il controllo del mirroring e mirror non è visibile l'oggetto principal, il mirror avvia il failover e diventa la nuova identità. La presenza di un server di controllo in una configurazione di mirroring del database non ha alcun effetto in modalità veloce un errore rilevato o velocità si verifica un failover.

Rilevamento degli errori immediata è un si ritiene, la velocità con cui viene rilevato un errore dipende dal tipo di errore. Ecco alcuni esempi:

1. Istanza di SQL Server (che ospita il database di identità) si blocca. Fino a quando Windows è ancora in esecuzione e reattive, deve essere rilevato l'errore in almeno un secondo. Ogni secondo uno, i server di controllo del mirroring e il mirror eseguire il ping principale. Se l'istanza di SQL Server non è in ascolto sulla porta TCP che è stata configurata, Windows riconosce questo e rispondere immediatamente che SQL Server non è presente.
2. Il server principale intero si blocca. In questo caso, Windows non è presente significa che SQL Server non è in ascolto sulla porta TCP definita, pertanto non è nulla per indicare che non vi c'è niente esiste. In questo caso, l'errore non verrà rilevato finché non scade il timeout di partner di mirroring. Questo è il numero di ping di una volta al secondo che deve non essere risposto a fino a quando il mirror dichiara un errore in parte del principale. Per impostazione predefinita, questo numero è impostato su 10 ping (e in tal caso 10 secondi), ma se è stata aumentata per qualsiasi motivo, il rilevamento degli errori richiederà più tempo.
3. Ha esito negativo un'unità di registro delle transazioni sul principale. Inizialmente non verrà eseguita ad eccezione del fatto che verrà avviato I/o in coda all'unità di registro. Dopo 20 secondi, SQL Server verrà stampato un messaggio di avviso nel log degli errori. È non fino a 40 secondi trascorsi che SQL Server verrà dichiarare l'unità di log di riga ­ e porre il database in modalità non in linea, nonché l'attivazione di un errore di mirroring.
4. Una pagina di database risulta danneggiata. In questo caso, se una query normale raggiunge il danneggiamento, non accade affatto nulla per il mirroring. Tuttavia, se una transazione è rollback e rileva il danneggiamento di pagina, il database diventerà come sospetto, come descritto nella risposta precedente, che verrà attivato immediatamente un errore di mirroring.
5. Se un file o filegroup di disconnessione del database principale e il filegroup primario non è interessato, quindi nell'edizione Enterprise, disponibilità parziale del database verrà avviare e un errore non si verificherà. In Standard Edition, tuttavia, un errore verrà attivato.

Come si può vedere, la velocità con cui viene rilevato un errore del mirroring realmente dipende il tipo di errore si verifica e se si è verificato il timeout di partner di mirroring.

Molti grazie a l. Kimberly Tripp di SQLskills.com per la revisione tecnicamente questo mese è la colonna.

Paul S. Randal è Managing Director di SQLskills.com, un direttore regionale Microsoft e MVP per 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. Randal è un esperto di ripristino di emergenza, disponibilità e la manutenzione del database e un regolare relatore a conferenze in tutto il mondo. Blog in di SQLskills.com/blogs/paul ed è possibile trovare lui Twitter in di Twitter.com/PaulRandal.