SQL Q & a: Senza traccia
Processi, quali backup e ripristino e la verifica della coerenza, possono comportare alcuni comportamenti imprevisti ma hanno un senso.
Paul S. Randal
Il rigore di ripristino
D. Sto lavorando fuori requisiti di tempo di inattività per alcune delle nostre istanze di SQL Server come parte della pianificazione del disaster recovery. È sufficiente considerare solo il tempo che necessario per ripristinare i backup?
**R.**No, ci sono alcune altre cose che dovete considerare. In primo luogo, si consideri il tempo totale che necessario per ripristinare tutti i backup necessari. Che include il backup completo del database più recenti, il più recente backup differenziale e tutti i backup del log delle transazioni. Assumere sempre lo scenario peggiore — dove il database viene distrutto appena prima di prendere il successivo backup completo, in modo da avere il maggior numero possibile di backup del log.
Poi, prendere in considerazione il tempo supplementare che ci vorrà per ripristinare il backup completo iniziale per creare i file di registro delle transazioni e dei dati se non sono già presenti. Se hai attivato l'inizializzazione immediata dei file, quindi file di dati verranno creati quasi istantaneamente. Il file di registro delle transazioni, tuttavia, deve essere inizializzata su zero.
Se avete un file di grandi dimensioni che è verso l'alto di centinaia di gigabyte, poi un ripristino potrebbe richiedere diverse ore. Se avete quindi di ripristinare un backup differenziale, che sarà ancora una volta completamente zero-inizializzare il file di registro delle transazioni. Si dovrà tenere conto per questa volta. Se ci è qualsiasi transazione ulteriori file di registro che sono state temporaneamente aggiunti (ma non rimosso) avrai zero-inizializzare queste pure — potenzialmente due volte.
L'ultima fase del processo di ripristino del database è quello di eseguire un ripristino di arresto anomalo. Il tempo necessario per questo dipenderà quanti record del log delle transazioni è necessario eseguire il rollback. Sono parte del rollback delle transazioni al momento del backup del log finale. Se hai transazioni a esecuzione prolungata nel vostro database, supporre il peggio. Si supponga che dovrete ripristinare quasi tutte le operazioni più lungo possibile. È necessario aggiungere quel tempo dell'equazione.
Infine, considerare anche quanto tempo ci vuole il server fisico per arrivare al punto in cui è possibile avviare il ripristino dei backup. In altre parole, quanto tempo impiega il server di avvio (running POST, controlli di memoria e così via) e avviare Windows? Questo potrebbe anche aggiungere il tempo di inattività.
Se si considerano tutte queste cose a loro peggiore dei casi, che vi darà un tempo di inattività massimo possibile. Potreste essere sorpresi quando si sommano tutto.
Non interrompere
D. Mi sono recentemente imbattuto in un problema interessante. Ho cercato di interrompere un processo di DBCC CHECKDB che stava prendendo più tempo del solito. Ho trovato non poteva interromperlo e ho dovuto aspettare a lungo per il processo alla fine. Si può spiegare che cosa stava accadendo?
**R.**Questo comportamento è previsto, ma non intuitiva a tutti. Quando DBCC CHECKDB inizia, si crea uno snapshot del database nascosti. Snapshot del database è necessaria per fornire una visualizzazione coerenza, immutabile del database DBCC CHECKDB. In questo modo, DBCC CHECKDB sa che sta verificando la consistenza di un database statico che non dovrebbe avere le corruzioni.
Il processo crea uno snapshot del database dal primo checkpoint del database. Poi crea snapshot del database vuoto e log delle transazioni del database viene utilizzato per eseguire il ripristino di arresto anomalo su snapshot del database. In altre parole, rotola indietro eventuali transazioni attive in snapshot del database senza intaccare in realtà il vero e proprio database. Snapshot del database diventa così consistente.
Il tempo che necessario per eseguire il recupero crash mentre la creazione di snapshot del database è proporzionale alla quantità e lunghezza del rollback delle transazioni del database all'avvio di snapshot del database. Se c'è una transazione a esecuzione prolungata, potrebbe richiedere molto tempo per eseguire il rollback. Questo significa la creazione di snapshot del database e il processo di DBCC CHECKDB richiederà più tempo.
In casi estremi, quando la creazione di snapshot del database richiede molto più tempo rispetto al normale e si decide di uccidere il processo di DBCC CHECKDB, niente accadrà subito. Devi attendere il ripristino del database snapshot crash completare prima che il processo risponderà al segnale kill. Non è possibile interrompere il crash recovery, e non non c'è nessuna distinzione nel codice di ripristino di arresto anomalo in SQL Server tra real crash recovery dopo un arresto imprevisto e un recupero di crash per uno snapshot del database.
L'unica alternativa in questo caso è riavviare l'istanza di SQL Server, che rimuoverà lo snapshot di database nascosti. Questo non funziona nel caso di un recupero reale crash database normale. In tali casi, crash recovery continuerà dopo riavviare un'istanza.
Ci sono diversi modi si può evitare questo scenario. Provare solo eseguire DBCC CHECKDB quando sai che non c'è long-running transazioni attive nel database. Lei avrebbe dovuto avere questi laminati indietro come parte della creazione di snapshot del database nascosti di DBCC CHECKDB. È anche possibile utilizzare un meccanismo di controllo di consistenza, che è quello di ripristinare il database a un altro server e poi coerenza controllare la copia restaurata. Questo evita la possibilità di transazioni a esecuzione prolungata complessivamente.
Trovare il momento giusto
D. La settimana scorsa ho dovuto ripristinare i backup per salvare una tabella qualcuno aveva accidentalmente caduto. La traccia predefinita aveva già perso le informazioni su quando la tabella è stata eliminata, quindi è stato un processo noioso per trovare la posizione di backup che avevo bisogno di ripristinare. C'è un modo per trovare il punto giusto in tempo a cui devo ripristinare?
**R.**Qualsiasi momento che si sta cercando di determinare quando una tabella è stata eliminata, controllare la traccia predefinita. Che rende nota degli eventi Data Definition Language (DDL). Potete leggere di più circa la traccia predefinita su SQL Server Books Online.
L'unico problema con traccia predefinita è che è una dimensione finita. Inoltre è stato deprecato a favore degli eventi estesi di SQL Server 2012. Così se c'è un sacco di attività che si verificano sul server, il record di quando è stata eliminata la tabella non potrebbe non esiste nella traccia più.
Ciò significa che l'unico modo per trovare quando la tabella è stata eliminata è fare quello che io chiamo "inching attraverso il log delle transazioni". Ripristinare una copia del database di un tempo quando il tavolo era conosciuto per esistere. Poi ripetutamente eseguire ripristini point-in-time utilizzando le opzioni WITH STOPAT e con STANDBY. Spostare leggermente in avanti nel tempo di ogni tempo. Quando trovi il tempo quando la tabella non esiste più, ripristinare il database appena prima di quel tempo ed è possibile recuperare i dati della tabella.
Questo processo è molto noioso e può richiedere molto tempo. Ogni volta che si ripristina il database utilizzando con STANDBY, tutte le transazioni salvate in quel punto rollback in un file undo. Il successivo ripristino del processo Annulla Annulla, ripristina un po' di più e rollback nuovamente le transazioni non salvate nel file undo. Devi ripetere questo processo fino a trovare il tempo corretto.
C'è un modo alternativo pulito per farlo. Analizzare i record del log di backup del log delle transazioni per cercare le transazioni chiamate DROPOBJ. Fare questo con un non documentati table-valued function chiamato fn_dump_dblog. Questo si comporta nello stesso modo come il più noto fn_dblog, quali discariche log record da un log delle transazioni attive, lavorando contro un backup del database.
È possibile utilizzare questa funzione per individuare la transazione che ha abbandonato l'oggetto a cui siete interessati. Quindi è possibile utilizzare o della transazione numero di sequenza del file di Log (LSN) per eseguire un ripristino con STOPBEFOREMARK = ' lsn: < il numero LSN della transazione >'. Questo ripristinerà il log delle transazioni fino a, ma non compresi, la transazione che ha abbandonato il tavolo. Facendo in questo modo si evita di avere in "pollici attraverso il registro," come descritto in precedenza. Potete leggere di più su questa funzione e come si usa sul mio blog.
Evento filtering
D. Ora che traccia SQL has been deprecated in SQL Server 2012, mi piacerebbe capire di più su eventi estesi. Si può spiegare come eventi estesi sono supposti per essere più leggero rispetto a traccia SQL?
**R.**Il motivo principale per il differenziale tra i due meccanismi di prestazioni è come eventi vengono filtrati. Quando si definisce una sessione di traccia o un evento, è possibile filtrare gli eventi in entrambi i casi sulla base di vari criteri di evento. Filtraggio su attività in un database di certo è un buon esempio di questo.
Con SQL Trace, gli eventi vengono generati tutto il tempo. Il consumer di eventi fa il filtraggio. Questo significa che SQL Server è gravato con generazione di tutti gli eventi, anche se alcuni non consumati. Questo processo è molto inefficiente.
Con eventi estesi, il motore degli eventi estesi di SQL Server esegue evento filtering. Il motore degli eventi estesi valuta i predicati specificati quando è stata definita la sessione dell'evento. Questo significa che quando viene generato l'evento, lavoro solo minimo è necessario per raccogliere i dati dell'evento base. In questo modo il motore di eventi valutare il predicato. Se il predicato restituisce false, l'evento viene immediatamente scartato. Il motore di eventi non esegue alcun ulteriore trattamento. Questo riduce il sovraccarico delle prestazioni di raccolta degli eventi rispetto alla traccia SQL.
Inoltre, traccia SQL raccoglie tutte le colonne associate a un evento e scarta tutte le colonne non necessarie. Eventi estesi, d'altra parte, raccoglie solo le colonne e altri dati specificati. Questo ulteriore riduce al minimo lo sforzo necessario per generare un evento.
Anche se eventi estesi è un meccanismo di gran lunga superiore per la raccolta di dati sulla risoluzione dei problemi, possono ancora influire negativamente sulle prestazioni di SQL Server se la sessione dell'evento non è costruita con cura. Se una sessione dell'evento richiede producendo uno stack di chiamata T-SQL, ogni volta che accade un evento molto comune (ad esempio, acquisizione di un blocco o un thread wait), questo influirà ovviamente le prestazioni.
Con meccanismo di entrambi, è necessario testare raccolta eventi prima di metterlo in produzione. È necessario garantire che non vengano compromesse le prestazioni del carico di lavoro.
.jpg)
Paul S. Randal è l'amministratore delegato di SQLskills.com, direttore regionale Microsoft e MVP per SQL Server. Ha lavorato il team di Microsoft SQL Server Storage Engine dal 1999 al 2007. Egli 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 disaster recovery, alta disponibilità e manutenzione del database ed è un presentatore regolarmente a conferenze in tutto il mondo. Ha Blog at SQLskills.com/blogs/paul, e lo si può trovare su Twitter a Twitter.com /PaulRandal..