SQL Server

Informazioni sui backup SQL Server

Paul S. Randal

Informazioni di riepilogo:

• Backup completi
• Backup del log delle transazioni
• Backup differenziali
• Pianificazione della strategia di backup e l'integrità dei backup

Contenuto

Backup completi
Backup differenziali
Backup del log delle transazioni
Pianificazione di strategia di backup
Integrità backup
Riepilogo

È veramente necessario eseguire il backup di SQL Server? Sì. A meno che non interessano i dati o non presente dover ricreare completamente il database in caso di emergenza, è necessario un modo del ripristino del database a un punto utilizzabile. Alcuni utenti sostenere che avere una copia ridondante del database in un altro punto Elimina la necessità di disporre di backup, ma cosa succede se copiare è danneggiato o inaccessibile? Sono necessari per assicurarsi che è sempre possibile ripristinare il backup.

Ma il tipo di backup è azioni? Frequenza con cui si deve consegnarli? Qual è l'effetto avrà sul database e il carico di lavoro? E come si è certi che siano valide?

Creazione di una strategia di backup si verifica effettivamente più facile di quanto si potrebbe pensare, anche se i comandi BACKUP e RESTORE sono un insieme di opzioni. E verrà consentono figura, tutti in uscita.

In questo articolo è il primo di una serie di tre parti. Nella parte 1, qui riguardano i backup. Nella parte 2 (problema settembre 2009), verranno illustrate ripristino di emergenza utilizzando i backup. E nella parte 3 (problema novembre 2009), verrà osservare di ripristino di emergenza senza backup. Sto per passare un po' più profondo maggiore del consueto in questi articoli, ma dovrebbe essere in grado di eseguire insieme con l'aiuto di materiale di sfondo.

Nell'articolo di questo mese, spiegherò delle nozioni di base relative i diversi tipi di lavoro backup e il modo in cui si desideri utilizzare in una strategia di backup. Semplificherà se si dispone di conoscenza del funzionamento del log delle transazioni di (vedere il mio articolo" Informazioni sulla registrazione e il ripristino in SQL Server." Non c'è Nessun punto di disporre di backup se si attiva è danneggiato quando si tenta di utilizzare, in modo che verrà inoltre descritto come aggiungere controlli di alcuni dell'integrità della loro. Lungo il percorso verrà debunk parte il misconceptions comuni e vengono forniti collegamenti a ulteriori informazioni.

Una cosa che non si intende eseguire è spiegare come funziona la sintassi di BACKUP e come eseguire i vari tipi di backup. Documentazione in linea di SQL Server è eccellente sezioni che trattano questo perché in tal caso sprecare spazio qui la duplicazione? Vedere l'argomento" Backup (Transact-SQL)"per ulteriori informazioni, soprattutto la sezione esempi alla fine. L'argomento" Backup e ripristino procedure (SQL Server Management Studio)"viene illustrato come utilizzare gli strumenti per eseguire il backup. È consigliabile esaminare la procedura qui sto per spiegare il significato e il motivo per cui dopo aver letto questo articolo.

L'implementazione della strategia di backup è la parte relativamente semplice. Un'efficace strategia di progettazione è la molto importante, anche se spesso trascurato, parte.

Backup completi

Il tipo più semplice di backup è un backup completo del database. È inoltre possibile eseguire un backup completo di un singolo file di dati o un filegroup. Tuttavia, non vengono comunemente utilizzati e in tutti i principi illustrati sono applicabili a essi, inoltre, sto per lo stato attivo backup a livello di database. Ma come di SQL Server 2005, ciascuno dei tipi più granulari di backup utilizzare esattamente la stessa (non è stato true in SQL Server 2000). Lo stesso vale per i backup differenziali, è possibile eseguire a livello di database, filegroup o file, ma questi tutte le operazioni nello stesso modo, oltre a questo punto, indipendentemente il componente da eseguire backup.

Un backup completo del database fornisce una copia completa del database e fornisce un singolo punto di tempo a cui è possibile ripristinare il database. Anche se potrebbe richiedere molte ore eseguire il processo di backup, è possibile ripristinare solo il backup in un singolo punto (in modo efficace in fondo il backup, ma mi occuperò esattamente quali informazioni che punto è più avanti in questo articolo). Un backup completo non consente il ripristino in un punto qualsiasi in tempo durante l'esecuzione del backup. Questo corrisponde anche a quello per i backup differenziali.

È presente un si ritiene su questo, tuttavia, fuelled dal fatto che è possibile utilizzare STOPAT WITH = < un numero sequenza ora o registro > opzione un ripristino di backup completi e differenziali. Sebbene la sintassi consenta, l'opzione non ha alcun effetto ed è solo disponibile per comodità.

Un altro si ritiene sui backup completo è che contengono solo dati. Sia i backup completi e differenziali inoltre contengono alcuni record del log delle transazioni in modo che il componente ripristinato (database, file o filegroup) consenta di renderli coerente in modo transazionale.

Prendere in considerazione una transazione di esempio che inserisce un record in una tabella con un singolo indice non cluster. Le pagine della tabella e indice vengono diffusi tramite il file di dati. La transazione viene suddivisa internamente in due parti: un inserimento di record in una pagina dati della tabella e quindi l'inserimento del record richiesti in una pagina di indice nell'indice non cluster. Se il processo di backup appena si leggere la pagina di indice non cluster prima dell'inserimento di record, ma legge la pagina di dati di tabella dopo l'inserimento di record, il database che rappresentato da solo i dati nel backup è incoerente in modo transazionale.

Si tratta, in cui il log delle transazioni entra in gioco. Includendo anche alcuni record del log delle transazioni nel backup, ripristino è possibile eseguire la copia del database, renderlo coerente mediante transazioni ripristinato. Per questa transazione di esempio, a seconda di quando salva, la parte di ripristino per ripristino potrebbe rollforward (ovvero verrà visualizzato come salvata nella copia del database ripristinata) o distribuire nuovamente non è (significato non verrà visualizzato affatto nella copia del database ripristinata). In entrambi i casi, viene mantenuta la coerenza delle transazioni, che è fondamentale.

Un backup completo effettua le seguenti operazioni:

1. Imporre un checkpoint del database e prendere nota del numero di sequenza del log a questo punto. Questo elimina tutte le pagine aggiornate in memoria su disco prima della lettura dal backup per ridurre al minimo la quantità di lavoro che la parte di ripristino di ripristino è nulla.
2. Avviare la lettura dai file di dati nel database.
3. Interrompere la lettura dal file di dati e creare una nota del numero sequenza di registro dell'inizio a questo punto la transazione meno recente attiva (vedere il mio articolo "Informazioni sulla registrazione e ripristino in SQL Server" per una descrizione di tali termini).
4. Consente di leggere più log delle transazioni è necessario.

Che indica quanti log delle transazioni è necessario migliore viene eseguita con lo strumento visivo nella Figura 1 . In questo elenco sono spiegati i numeri di colore rossi nella sequenza temporale:

1. Punto di arresto e iniziare la lettura dal database.
2. L'operazione di lettura legge pagina X.
3. Viene avviata una transazione.
4. Transazione A apporta una modifica alla pagina X. La copia nel backup ora è aggiornata. Si noti che il backup non leggerà pagina X di nuovo, viene passata già tale punto nel database.
5. Verrà avviata la transazione B. Non completa prima che i dati letti al completamento dell'operazione.
6. Esegue il commit delle transazioni A. Questo esegue il commit a pagina X delle modifiche.
7. I dati di backup leggere al completamento dell'operazione e l'avvio del log delle transazioni durante la lettura.

Nella figura 1 cronologia di esempio delle modifiche durante un backup completo

Backup del log delle transazioni sufficiente è necessario in modo che ripristino possa eseguire correttamente durante il ripristino e tutte le pagine nel database sono nello stesso punto nel tempo, l'ora in cui i dati per la lettura di parte dell'operazione backup completato (punto 7). Log delle transazioni dall'inizio della transazione meno recente attiva (o cui non è stato eseguito il commit) (5 punti, Transaction B) il termine del backup (punto 7), è necessario per consentire l'esecuzione del ripristino. Il log delle transazioni dal checkpoint di backup (Point 1) alla fine del backup (7 Point) è necessaria per consentire tutte le pagine diventare allo stesso punto nel tempo.

Se il log delle transazioni è stato incluso solo dall'inizio della transazione attiva meno recente (punto 5), quindi la copia di X che è stato ripristinato da backup lettura al punto 2 pagina sarebbe Impossibile aggiornare con le modifiche dalla transazione A cui si è verificato al punto 4. Ciò significa che potrebbe non essere mediante transazioni è coerente con il resto del database al momento l'operazione di lettura dei dati completata (punto 7).

In questo modo, il numero di sequenza di registro minimo (LSN) del log delle transazioni è incluso nel backup completo è MIN (LSN del checkpoint di backup, il numero LSN della transazione attiva meno recente) e potrebbe essere per una transazione che ha iniziato a anche prima il backup. In questo modo la copia del database ripristinata (o qualsiasi ripristinato, pagina, il file, il filegroup, database) è completamente coerente.

Questo meccanismo significa che le transazioni sono sospesa in alcun modo dalle operazioni di backup, sebbene l'ulteriore carico di lavoro I/O sul database potrebbe rallentare i leggermente. Lo svantaggio di questo meccanismo è che il log delle transazioni Impossibile cancellare per tutta la durata del backup completo perché è necessario. Se c'è molta attività di aggiornamento e il backup completo richiede molto tempo per completare, questo può causare crescita del log delle transazioni, un problema che già trattati in vari articoli precedenti e nella colonna SQL q &.

I dati contenuti in un backup completo non sono necessariamente tutto il contenuto di tutti i file di dati. Il backup conterrà solo le pagine allocate dai file di dati. Ad esempio, un database a file singolo può essere 100 GB ma contiene solo 15 GB di dati allocati. In questo caso, il backup completo conterrà solo il 15 GB di dati allocati più del log delle transazioni necessari. (Tuttavia, il database ripristinato sarà sempre la stessa dimensione originale, in questo caso, 100 GB.)

Si ritiene di un altro è che il processo di backup esamina o modifica i dati che è backup. Ciò risulta falsi, fatta eccezione per in un singolo caso sono attivati i checksum di backup, che spiegherò in breve tempo.

Backup differenziali

L'altro tipo di backup dei dati è un backup differenziale. Un backup differenziale esegue le stesse operazioni un backup completo, ma solo contiene tutti i dati che sono stato modificato o aggiunti dopo l'ultimo backup completo. Un si ritiene comunemente qui è che i backup differenziali sono incrementali. Sono effettivamente cumulativo e successivi backup differenziali dopo un backup completo e aumenta di dimensioni quando più dati viene modificati o aggiunto.

In ogni 4 GB sezione (denominato di un intervallo GAM) di ogni file di dati è una pagina di database speciale denominata una bitmap differenziale che tiene traccia di quali parti di tale sezione 4 GB (denominati extent) modificati dopo l'ultimo backup di completo, che indica i dati modificati o aggiunti al database. (Esistono diversi altri bitmap di allocazione troppo ed è possibile trovare ulteriori informazioni su questi nel mio articolo di blog" All'interno di il motore di archiviazione: GAM, SGAM, PFS e altri mapping di allocazione").

Un backup differenziale esegue la scansione tramite tali bitmap ed esegue solo il backup i dati degli extent file contrassegnati come modificati. Le bitmap vengono reimpostate per il successivo backup completo, in modo da vedere che più delle modifiche del database maggiore verranno contrassegnate le bitmap differenziale e i backup differenziali successivi sarà più grande e più grande. Infine, se la maggior parte del database è cambiato, un backup differenziale potrebbe diventare grande quanto il backup completo. È possibile individuare le dimensioni del backup differenziale successivo verrà utilizzato uno script che ho scritto che è disponibile dal mio articolo di blog" Nuovo script: quanti del database ha modificati dall'ultimo backup completo?." Per inciso, questo script è possibile utilizzare per avere un'idea del tasso di varianza di un database, ad esempio, in un database di contenuto SharePoint.

Come una nota rapida, se si desidera eseguire un backup completo ad hoc e non sono ripristinate le bitmap differenziale, occorre utilizzare l'opzione WITH COPY_ONLY l'istruzione BACKUP. Questo è molto utile, come in caso contrario i successivo backup differenziali potrebbero basarsi sul ad hoc backup completo è stata eseguita, anziché sul normale backup completo (probabilmente pianificato). Questo potrebbe causare problemi di grandi dimensioni quando si tenta di ripristinare in una situazione di emergenza.

Pertanto, perché sono i backup differenziali utile? Come verrà illustrato nella sezione strategia di backup, backup differenziali possono realmente velocizzare le operazioni di ripristino consentendo numerosi backup del log delle transazioni che venga ignorata nel processo di ripristino. È molto più veloce per essenzialmente spostarsi in avanti nel tempo utilizzando un backup differenziale rispetto per riprodurre numerosi record del log delle transazioni necessario per ottenere lo stesso punto nel tempo.

Backup del log delle transazioni

Backup del log delle transazioni sono possibile solo nei modelli di recupero completa o con registrazione minima delle transazioni di massa (BULK_LOGGED), mentre i backup completi e differenziali sono inoltre disponibili nel modello di recupero con registrazione minima.

Un backup del log delle transazioni contiene tutti i record di registro delle transazioni generati dopo l'ultimo backup del log (o backup completo che inizia una catena di backup del registro) e viene utilizzato per consentire al database da ripristinare in un punto specifico nel tempo (in genere l'ora a destra, prima di una situazione di emergenza colpisce). Ciò significa che sono incrementali, a differenza dei backup differenziali sono cumulativi. Poiché questi sono incrementali, se si desidera ripristinare il database in un determinato punto nel tempo, è necessario affinché tutti i transazione record necessari per riprodurre le modifiche apportate al database fino a che puntano in tempo. Queste sono contenute nella catena di backup del log.

Una catena di backup del log è una serie ininterrotta di backup del log che contengono tutti i record di registro di transazione necessari per ripristinare un database a un punto nel tempo. Una catena inizia con un backup completo del database e continua fino a quando qualcosa interruzioni della catena, impedendo così ulteriori backup del log viene eseguito finché non viene eseguito un altro backup completo (o differenziale).

Operazioni che interrompe la catena di backup del log includono il passaggio al modello di recupero con registrazione minima, ripristino da uno snapshot di database e forzatamente cancellazione del log utilizzando le opzioni WITH NO_LOG o TRUNCATE_ONLY (che non sono disponibili in SQL Server 2008). È inadvisable per interrompere la catena di backup del log, in quanto impone un altro backup completo (grandi) da eseguire.

Sebbene una catena di backup del log si estende a un backup completo, non è necessario ripristinare tutti i backup del log durante il ripristino. Se è stata eseguita una copia completa backup, ad esempio, in domenica sera e notte mercoledì, con backup log ogni mezz'ora dopo la domenica sera, quindi ripristinare il database dopo un'emergenza venerdì possibile utilizzare backup completo del mercoledì e tutti i backup del log dopo mercoledì notte invece di dover passare in modo eseguire il backup della notte della domenica. (Il secondo articolo della serie verrà registrati più approfondito in questo argomento.)

Per gestire la dimensione del registro delle transazioni sono necessari anche i backup del log. Nei modelli di recupero completa o con registrazione minima delle transazioni di massa (BULK_LOGGED), il log non verrà cancellata fino a quando non un backup del log viene eseguito (vedere l'articolo di febbraio per informazioni dettagliate di quale mezzo di cancellazione di registro), in modo che deve eseguire il backup del log regolari per impedire che il file di registro cresce all'esterno del controllo. Se non può cancellare il registro, il registro aumentano fino a esaurimento dello spazio. Di conseguenza, se non si desidera eseguire l'operazione di ripristino in un momento utilizzando il backup del log, l'opzione più semplice è passare al modello di recupero con registrazione minima e non utilizzare i modelli di recupero completa o con registrazione minima delle transazioni di massa (BULK_LOGGED). Questo illustrare in maggiore dettaglio nel post del blog" Importanza della gestione dimensione dei registri delle transazioni appropriato."

Presenta un caso speciale in registrazione che migliora le prestazioni, consentendo di alcune operazioni da eseguire come operazioni con registrazione minima, in cui vengono registrate solo le allocazioni di pagina, non l'effettivo inserimento di dati. Questo può migliorare le prestazioni delle operazioni, ad esempio caricamenti di massa e ricrea indice. In questi casi, non tutte le informazioni relative all'operazione viene registrata, in modo che il backup di registro record è in non di contengono informazioni sufficienti per la riproduzione completamente l'operazione. In questo caso, ripristino e ripristino eventualmente utilizzo assenza di informazioni sufficienti?

La risposta è che il primo backup del log dopo un'operazione con registrazione minima conterrà anche alcuni dati. Come le bitmap differenziale indicato in precedenza, è un altro bitmap denominata la bitmap con registrazione minima (detta anche la mappa di modifica di massa). Questa bitmap tiene traccia di quali estensioni di un file di dati sono stati modificati a causa di un'operazione con registrazione minima.

Il backup del log seguito a un'operazione con registrazione minima analizza tramite tali bitmap e il backup anche tali estensioni di dati che sono contrassegnati come modificato. Le bitmap vengono cancellate dopo aver analizzato. Ciò significa che il backup del log ha informazioni sufficienti per riprodurre completamente gli effetti dell'operazione minima registrate nel database, quando viene ripristinato il backup del log. C'è tuttavia una sorpresa: esiste niente nel che backup del log che indica quando è stato modificato qualsiasi estensione di dati specifico. Un backup del log che contiene anche i dati da un'operazione di registrazione minima non può essere ripristinato in un punto qualsiasi in un momento, tranne la fine del tempo periodo coperto (o oltre, se il backup del log fa parte di una catena di backup di registro che si sta ripristinando da). In questo modo, mentre è possibile ottenere miglioramenti delle prestazioni quando si passa al modello di recupero con registrazione minima delle transazioni di massa (BULK_LOGGED), è necessario considerare modificare come operazione temporanea, solo per migliorare il processo batch e una volta completato il processo batch, si dovrebbe tornare a FULL eseguire un backup di registro appena possibile.

È inoltre disponibile un backup del log caso speciale Consenti l'accesso da sottoporre a backup dopo un'emergenza che danneggia i file di dati. Si tratta di un backup finale di registro (o coda-log), in cui i file di dati possono essere danneggiati o eliminati, ma il backup tutti i log delle transazioni con backup il punto d'emergenza può essere eseguito. In questo modo una perdita di lavoro minimo, denominata ripristino aggiornata, quando successivamente viene ripristinato il database; tuttavia, è supportato solo quando il database è in esecuzione nel modello di recupero completo. Ulteriori informazioni su tali e restrizioni con registrazione minima operazioni sono disponibili nell'argomento della documentazione in linea" Backup di log di coda." La prima schermata cast che accompagna questo articolo viene illustrato me che illustrano backup coda di log.

Nelle versioni di SQL Server precedenti a SQL Server 2005, i backup del log delle transazioni non è possibile eseguire contemporaneamente con completo del database o backup differenziali del database, consente di bloccare fino a quando il backup a livello di database completato. File e backup basati su filegroup non determinava il backup del log per il blocco. Mentre questo complesso il processo di ripristino di backup di file e filegroup, assegnato loro un vantaggio bloccando non backup del log. In SQL Server 2005, tutti i backup completi e differenziali (indipendentemente dal componente) vengono funziona nello stesso modo. Il comportamento è ora completato il backup del log delle transazioni simultanee, ma il log delle transazioni non viene cancellato fino al completo o anche completamento del backup differenziale (che richiede il registro).

Pianificazione di strategia di backup

Ora che conosci sui tre tipi di backup e il loro funzionamento, viene illustrato come è possibile inserirli insieme in una strategia di backup.

Una domanda frequente che è possibile ottenere è come iniziare a pensare una strategia di backup. Mi piace sempre indicare che non dovrebbe progettare una strategia di backup. È necessario progettare una strategia di ripristino, che consente di ripristinare leggermente per quanto possibile in caso di emergenza è il tempo di inattività al minimo mantenendo i dati. Dopo che si è lavorato che in uscita, quindi utilizzare il backup è necessario pertanto è possibile eseguire il ripristino è necessario. In altre parole, la strategia di backup deve consentono di soddisfare le comporta (ripristino ora obiettivo) e l'obiettivo di punto di ripristino (RILASCIATO).

Con una strategia che include solo i backup completi piuttosto è limitato in operazioni eseguibili con il ripristino. In sostanza, è possibile ripristinare solo al momento di ogni backup completo, come illustrato nella Figura 2 . Se d'emergenza colpisce in 23: 59 sabato, appena prima che il backup completo successivo è pianificato, quindi tutte le operazioni dall'ultimo backup completo potrebbero andare persa. Per questo motivo, se deve essere evitato perdita di dati e Impossibile ricreare i dati, i backup del log sono inoltre inclusi, come illustrato nella Figura 3 .

Nella figura 2 strategia di backup con un solo backup completi

Nella figura 3 strategia di backup completo e di backup del log

Si supponga che i backup del log vengono intraprese ogni 30 minuti. Purché tutti i backup sono disponibili, ciò significa che è possibile ripristinare il database in un punto qualsiasi nel tempo. Tuttavia, questo ancora non è la strategia migliore. Che cosa fare se d'emergenza colpisce in 23: 59 sabato con questa strategia posto? Innanzitutto, è possibile eseguire un coda-di-di-registro di backup e quindi avviare il ripristino.

Per ripristinare il database fino a punto dell'emergenza implica ripristino di backup completo dell'ultima domenica e quindi i backup del log 336 (che sei giorni di backup del log 48 per giorno, sommato 47 sabato e il backup della coda di log). A seconda della quantità della varianza del si è verificato nel database attraverso la settimana che può essere una grande quantità di log delle transazioni che avranno tempi molto lunghi per la riproduzione. Ecco chiaramente non una strategia di ripristino ottimale, ma è una strategia comune viene visualizzato nel campo. Se si dispone di una strategia di come questo, assicurarsi che in precedenza, che si è visto così un ripristino si è certi se grado di soddisfare il comporta in caso di emergenza.

Per attenuare questo problema, alcune strategie utilizzare più frequenti backup completi, ma queste potrebbero essere troppo grande per eseguire ogni giorno, ad esempio. L'alternativa consiste nell'utilizzare i backup differenziali, solo contengono i dati che sono stato modificato dopo l'ultimo backup completo. Continuando l'esempio, questa strategia è illustrata nella Figura 4 .

Nella figura 4 strategia di backup con completo, file di log e differenziali

Con questa strategia, il ripristino da un'emergenza in 23: 59 sabato è molto più veloce. Tenere presente che un backup differenziale è cumulativo, è la strategia di ripristino del backup completo di lunedì, il backup differenziale sabato di 00: 00 e tutti i backup del log da sabato. Con il backup differenziale 00: 00 Sabato significa che è possibile che tutti i backup del log prima che venga ignorato, come il backup differenziale contiene lo stesso risultato net-di ripristino di tutti i backup del log.

Questo era un esempio molto semplice e forzato, ma viene illustrato chiaramente i vantaggi di ogni tipo di backup. Una volta progettato la strategia di backup, assicurarsi di che testing per garantire che consente di eseguire il ripristino desiderato.

Ecco un esempio che ho visto una faccia cliente pochi anni nuovamente. Un cliente ha un database danneggiato e si desidera ripristinare con zero perdita di dati. Sono stati riluttanti utilizzare i loro backup e si è tentato di esecuzione di ripristino su una copia del database, ma è necessario eliminare i dati, li imporre in utilizzando i loro backup. Attiva che avevano un backup completo da gennaio e un backup del log ogni mezz'ora su aprile, backup oltre 5.000 in totale e su nastro! Si è sicuri che si è in sequenza gli occhi e pensare "Scommetto non funziona," ma in effetti era; tuttavia necessari tre giorni per eseguire questa operazione! Il cliente pensato che avevano una grande strategia di backup, ripristino FULL modello più log backup, ma la strategia di backup non di eseguire i ripristini che si desideravano.

Integrità backup

Non c'è Nessun punto di disporre di backup se si rileva che siano danneggiati, quando si tenta di ripristinare da essi. Naturalmente, il modo migliore per verificare la validità del backup, è possibile ripristinarli in un altro server, ma in SQL Server 2005 è stata introdotta una nuova funzionalità che alcuni l'integrità dei backup consente di essere eseguite senza dover effettivamente ripristinarli. È possibile utilizzare l'opzione WITH CHECKSUM, quando un backup (di qualsiasi gamma).

Questo crea un checksum di tutto il backup flusso, memorizzato nel backup stesso. Se il backup è un completo o differenziale e il database ha attivati i checksum di pagina, questa opzione provocherà inoltre tutti i checksum di pagina esistente da verificare come il processo di backup legge le pagine. Se viene trovato un checksum di pagina non valido, l'operazione di backup non verrà effettuata. Questo offre grande contro accidentalmente backup a un database che è già danneggiato in qualche modo. (È possibile trovare ulteriori informazioni i checksum di pagina nell'articolo "Principali suggerimenti per valide manutenzione database" da agosto 2008.)

Una volta completato il backup, può essere verificata utilizzando un comando simile a quello riportato di seguito:

RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM

Verrà ricalcolare il valore di checksum su tutto il flusso backup e confrontarlo con quello memorizzato nel backup. Per i backup completi e differenziali, verrà inoltre verificare i checksum di pagina nelle pagine nel backup. Se vengono rilevati eventuali problemi, si saprà che il backup è stato danneggiato in qualche modo.

Naturalmente, vi sono le eccezioni alla regola, è possibile che in cui si desideri backup di un database danneggiato (se è la copia del database è che sarà necessario eseguire il ripristino, ad esempio sola). In questo caso, è possibile forzare il backup completata utilizzando l'opzione WITH CONTINUE_AFTER_ERROR.

È possibile trovare ulteriori informazioni sulla convalida dei backup in informazioni sulla convalida di backup sul mio bloge inoltre osservare me illustrano alcuni aspetti della convalida di backup nella seconda schermata cast che accompagna questo articolo.

Riepilogo

Come con qualsiasi argomento complesso, sono disponibili numerose aree di backup che non ho di spazio sufficiente per coprire, ma dopo che sono trattate le nozioni di base, è possibile esplorare alcuni collegamenti documentazione in linea e blog per informazioni più approfondite. Il modo migliore per avviare in linea è l'argomento" Panoramica di backup (SQL Server)." Sul mio blog, è possibile iniziare con il Categoria di backup e ripristino.

Un'area che si può pensare è conspicuous in sua assenza è la compressione dei backup. Questa è intenzionale verrà essere nascosto in un secondo momento nell'anno in un articolo in tutte le tecnologie di compressione nuovo in SQL Server 2008. Nel frattempo, è possibile estrarre l'argomento nella documentazione in linea" Compressione backup (SQL Server)"e anche in mio blog.

Se dispone di riassumere in questo articolo in tre punti elenco, saranno:

• Assicurarsi di che disporre dei backup.
• Assicurarsi che sia backup valido.
• Assicurarsi che sia i backup a destra.

In altre parole, backup hanno se si desidera per poter ripristinare il database, eseguire un'operazione in modo che si conosce i backup funzionerà quando sono necessari per e assicurarsi che consente di recuperare le copie di backup e di soddisfare le comporta e RILASCIATO.

Nel prossimo articolo spiegherò tutta una questione ripristino da backup, inclusi i diversi tipi di operazioni di ripristino e il loro funzionamento, ripristino da più copie di backup e disponibilità parziale del database.

Nel frattempo e come sempre, se si dispone di eventuali commenti e suggerimenti o domande, rilasciare automaticamente una riga nella Paul@SQLskills.com.

Paul s. Randal è Managing Director di SQLskills.com, un MVP per SQL Server e Microsoft Regional Director. 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, alta disponibilità e manutenzione del database e un regolare relatore a conferenze di tutto il mondo. Blog di ha all' SQLskills.com/blogs/paul.