Ripristino di emergenza di SQL server

SQL Server: Ripristino di emergenza con i backup

Paul s. Randal

T qui non è molto punto accettando i backup di SQL Server, a meno che non si è in grado di ripristinarli. Se si dispone di alcuna operazione più complessa rispetto a un backup di database completo, sarà necessario conoscere alcune opzioni di RESTORE per poter ripristinare correttamente il database al punto desiderato nel tempo.

Ciò avviene ancora maggiore se si dispone di un layout complesso database o una strategia di backup complessa e si desidera essere in grado di ripristinare un singolo file o filegroup, o sfruttare i vantaggi di disponibilità parziale del database.
Purché si dispone di un'efficace strategia di backup e i backup siano validi, deve essere in grado di eseguire il recupero da un'emergenza all'interno il ripristino di emergenza Time Objective (comporta) e per il RILASCIATO (Recovery Point Objective). Nel primo articolo in questa serie di tre parti, ho spiegato i vari tipi di backup e le modalità formulare una strategia di backup (vedere "Understanding i backup SQL Server" nel numero di luglio 2009).

In questo articolo spiegherò come funziona ripristino e come eseguire alcune delle più comuni operazioni di ripristino. Sarà utile che hai letto l'articolo di backup e il materiale sfondo che ho accennato nell'introduzione di tale articolo. Illustrerò inoltre spiegare poche operazioni difficile ulteriori, ad esempio l'operazione di ripristino di un punto nel tempo e un ripristino in linea piecemeal con disponibilità parziale del database.

Come nel precedente articolo su BACKUP non sto per spiegare il funzionamento della sintassi RESTORE o passare attraverso i passaggi specifici di tutte le operazioni di ripristino. Documentazione in linea è un processo di che eccellente. Vedere""RESTORE (Transact-SQL)"per ulteriori informazioni, soprattutto gli esempi di diffondono in tutto l'argomento. Esistono effettivamente così tante opzioni per RESTORE che è un argomento per spiegare loro intero altre! " Backup e ripristino di argomenti relativi alle procedure (SQL Server Management Studio)"questo articolo viene spiegato come utilizzare gli strumenti per eseguire ripristini.

Le quattro fasi di ripristino

Iniziamo con ripristino effettivamente funzionamento. Un'operazione di ripristino è fino a quattro fasi:

1. Creazione di file e l'inizializzazione
2. Copia del log delle transazioni e/o dati
3. Ripeti la fase di ripristino
4. UNDO fase del ripristino

Uno dei principali obiettivi di ripristino di emergenza consiste nel portare in linea il database nel minor tempo. Se il piano di ripristino di emergenza prevede il ripristino dei backup (anziché, ad esempio, failover su un database mirror), si prevede di desidera che il processo di ripristino ad alta velocità. Con ciascuna delle quattro passaggi di ripristino in mente, è presente alcuna operazione da eseguire per aumentare la velocità di?

Il primo passaggio è possibile saltare essenzialmente se i file di dati e di registro esistano già. Ciò significa che se si ha intenzione di sovrascrivere un database esistente, non eliminare il database prima di eseguire il ripristino. Utilizzare invece l'opzione WITH REPLACE nella prima operazione di ripristino per indicare a SQL Server per l'utilizzo di file esistenti. Se i file non esistano, verrà creati e quindi inizializzate. Creazione dei file è molto veloce, ma il processo di zero-inizializzazione li può essere molto lento.

Per motivi di protezione e per impostazione predefinita, tutti i file di database sono inizializzate su zero. È possibile attivare l'inizializzazione file immediata per l'istanza di SQL Server, quali frammentato processo azzerando per file di dati di creare e crescere operazioni, comprese quelle richieste durante un ripristino--un possibile risparmio ore di inattività, anche se i file di dati sono solo gigabyte nella dimensione. I file di registro delle transazioni sono sempre inizializzata a zero a causa della natura circolare del log delle transazioni se stesso.

È possibile leggere ulteriori informazioni su tutto questo con riferimenti a documentazione in linea, nel mio "Inizializzazione immediati" categoria di post del blog.

Ci si potrebbe chiedere sulla seconda fase--perché l'elemento visualizzato "e/o log delle transazioni"? Se si legge l'articolo precedente, si verrà ricordare che tutti i backup completi e differenziali includono anche alcuni record del log delle transazioni, per attivare il database venga ripristinato a un punto coerenza mediante transazioni in tempo. Fase 2 è un'operazione di copia pure--Nessuna elaborazione dei dati viene eseguita--il principale per velocizzare questo consiste nel disporre di un sottosistema di I/O better-performing. Si tratta di uno dei pochi casi in cui è accettabile "throw hardware al problema."

Il modo per aumentare la velocità della fase di copia è possibile utilizzare un tipo di tecnologia di compressione di backup, entrambi nativo a SQL Server 2008 o tramite una delle varie soluzioni di terze parti. Le due parti della fase di copia sono la lettura dal supporto di backup e la scrittura ai file di registro e/o dati. Se è possibile eseguire un minor numero di letture (utilizzando supporti di backup compressi), è possibile accelerare il processo complessivo, a scapito di una piccola quantità di risorse della CPU.

Fasi tre e quattro stanno in corso il ripristino del log delle transazioni per portare il database a un punto coerenza mediante transazioni in tempo. Ho spiegato i dettagli di ripristino nell'articolo febbraio 2009"Registrazione di conoscenza e il ripristino di emergenza in SQL Server". Si noti che fase quattro sono facoltativo, come spiegherò in un secondo momento.

Basti dire che il log delle transazioni più che deve essere ripristinato durante un ripristino, richiederà più tempo del ripristino. Ciò significa che se, ad esempio, si dispone di un backup completo del database da una settimana scorsa e ogni ora i backup del log delle transazioni dal quindi il processo di ripristino verrà essenzialmente riprodurre tutte le transazioni dall'ultima settimana prima del completamento. Ho parlato di una soluzione per questo nell'articolo precedente--aggiunta di una strategia di backup del log full e backup differenziali.

Un backup differenziale del database contiene tutte le pagine del file di dati che sono stati modificati dopo l'ultimo backup completo del database e possono essere utilizzate in un'operazione di ripristino per evitare di dover riprodurre tutte le transazioni che si sono verificati nel periodo compreso tra il backup completo del database e il backup differenziale del database. Ciò può ridurre notevolmente il tempo necessario per ripristinare il database, ma a scapito di una strategia di backup leggermente più complicata.

È possibile trovare ulteriori informazioni nell'argomento della documentazione in linea"L'ottimizzazione delle prestazioni di backup e ripristino in SQL Server".

Tutto quanto è necessario per il ripristino?

Quando necessatà di emergenza, prima cosa è scoprire cosa è stato danneggiato,: ciò sta per dettare le azioni che è necessario intraprendere per il ripristino di emergenza. Per errore supporti di archiviazione, i valori possibili sono:

• Danni all'intero database (ad esempio, tutto ciò è stato cui è archiviato il database è stato eliminato in modo permanente, o il database era un singolo file di dati ed era danneggiato).
• Causare danni a un unico filegroup di un database di più filegroup.
• Causare danni a un unico file di un filegroup a più file.
• Causare danni a una singola pagina nel database.
• Danni si diffondono attraverso il database.

È possibile verificare i danni mediante la ricerca tramite il log degli errori di SQL Server per le notifiche di file sono inaccessibili, pagina di lettura si sono verificati errori (per istanza, gli errori di checksum di pagina o un errore di rilevamento pagine incomplete) o che è stato rilevato danneggiamento generale. Se si è verificato danno, è prassi consueta per eseguire l'operazione di verifica della coerenza di DBCC CHECKDB per avere un'idea di come pervasiva il danno è.

Una spiegazione di coerenza non rientra nell'ambito di questo articolo, ma è possibile guardare un video di una presentazione che dopo aver apportato al forum IT a Tech-ed in novembre 2008 dal titolo"Danneggiamento Survival tecniche"e ascoltare un colloquio di TechNet Radio da versioni precedenti di quest'anno in cui verranno illustrati danneggiamento del database (download diretto sono collegamenti qui).

Calamità non sono limitati a errori di I/O sottosistema o server--errore umano da considerare è inoltre disponibile. Tabelle di database (o dati da essi) vengono spesso accidentalmente eliminati dalle applicazioni programmate in modo inadeguato o istruzioni Transact-SQL da (lo scenario "non sono stati realizzare che ero sul server di produzione"). In questi casi, può essere molto difficile figura out cosa deve essere ripristinato e da cosa scegliere nel tempo, soprattutto se nessun utente è proprietario a rendere l'errore. È possibile ottenere fortunata utilizzando report standard dalla traccia predefinita in cui l'operazione DDL è ancora disponibile o è stata rilevata l'istruzione DELETE per la propria registrazione--ma spesso non è presente alcun record di chi ha cosa nel database. Mi occuperò di ripristino da questa situazione in maggiore dettaglio più avanti. Indipendentemente chi ha eseguito l'eliminazione accidentale dei dati o quando si è verificato, più il tempo attesa per il ripristino--o il tempo che passa prima che vengano apportate a conoscenza del problema--più complesso può essere per il ripristino.

In tal caso, come un passaggio prima se il database è in esecuzione nel modello di recupero completo e il log delle transazioni è non danneggiato, eseguire un backup della parte finale del log per garantire che tutte le transazioni fino al punto dell'emergenza vengono sottoposti a backup. Questo backup del log delle transazioni "finale" disporrà di tutti gli elementi fino al momento dell'emergenza e può essere utilizzato per riportare il database da ripristinare quanto possibile, eventualmente aggiornati al minuto.

In breve, è necessario scoprire cosa è necessario ripristinare. Diventa quindi una domanda di che cosa sono in grado di ripristinare.

Ciò che sei in grado di ripristino?

L'obiettivo di qualsiasi operazione di ripristino consiste nel ripristinare i backup possibili minor numero, in modo che l'operazione di ripristino è ad alta velocità e viene completata entro il comporta, consentendo anche rispettare l'ordine di produzione RILASCIATO.

La domanda principale a questo campo è "What i backup sono?" Se il backup solo che si dispone è un backup completo del database da una settimana scorsa e l'intero database è stata persa, è disponibile l'opzione di ripristino di un solo--in un punto nel tempo una settimana scorsa, perdere tutto il lavoro dopo quindi. In poche parole, la strategia di backup necessario assicurarsi sempre che siano in grado di ripristinare ciò che è necessario in caso di emergenza, come spiegato nell'articolo precedente.

Come determinare quali i backup sono disponibili? Innanzitutto, è possibile eseguire una query che varie tabelle di cronologia nel database msdb di backup. Queste tabelle contengono una registrazione di tutti i backup sono state adottate nell'istanza di SQL Server dall'ultima volta che le tabelle di cronologia di backup sono state cancellate.

Dal punto di vista a come i backup stessi sono l'obiettivo, è buona norma denominare i file di backup includono il database, digitare di backup, data e l'ora in modo che il backup può essere identificato in modo immediato. Se non è stato fatto ciò, è possibile individuare quale un file di backup contiene utilizzando il comando RESTORE HEADERONLY. Verrà visualizzato il contenuto dell'intestazione del file di backup, essenzialmente i metadati che descrivono il backup stesso. Per ulteriori informazioni nell'argomento della documentazione in linea "Visualizzazione di informazioni su backup".

Utilizzando uno dei due metodi, si sta tentando di scoprire la sequenza di ripristino da utilizzare per ripristinare i dati danneggiati o eliminati. Una sequenza di ripristino è un set di backup devono essere ripristinati e l'ordine appropriato in cui ripristinarli. La sequenza di ripristino potrebbe essere semplice come un solo backup completo (di un database, file o filegroup), o una serie complicata di completo, differenziale e i backup del log delle transazioni.

Ad esempio, si immagini uno scenario in cui implica la strategia di backup completo del database, backup differenziale del database e backup del log delle transazioni. Se si verifica un arresto anomalo del sistema e i file di dati sono danneggiati, qual è la sequenza di ripristino? Nella figura 1 illustrato in questo esempio.

In questo caso, la sequenza di ripristino più rapido e più breve è il più recente backup completo del database (F), il backup differenziale del database più recente (D2) e quindi tutti i successivi backup del log delle transazioni, incluso il backup della parte finale del log (L7 e L8).

Uno dei problemi di difficile quando si pianifica una sequenza di ripristino è in corso la ricerca il backup del log più vicina richiesto per le transazioni da ripristinare (talvolta denominata ricerca di "numero LSN minimo" o "minimo-Log Sequence Number"). Nell'esempio riportato in di Figura 1 solo backup del log delle transazioni L7 e L8 sono necessari, poiché il backup differenziale del database D2 riporta il database in un punto più recente nel tempo rispetto alla transazione precedente backup del log.

Figura 1: Sequenza di ripristino configurazione di esempio

SQL Server consentirà precedente, non necessari transazione backup del log da ripristinare, ma non verranno utilizzati e ripristino di emergenza essenzialmente semplicemente rifiuti time.Continuing mio esempio, che cosa accadrebbe se D2 eseguire il backup differenziale del database è stato danneggiato o mancante? Nella figura 2 viene illustrato in questo caso.

Figura 2: Ripristinare la sequenza con un BackUp di database differenziale danno

In questo scenario, la sequenza di ripristino più rapido e più breve è il più recente backup completo del database (F), il successivo backup differenziale del database più recente (D1) e quindi tutti i successivi backup del log delle transazioni (L4, L5, L6, L7 e L8). Ciò è possibile solo, purché i backup D1, L4, L5 e L6 sono ancora disponibili. È importante che i backup non vengono eliminate troppo presto; in caso contrario è possibile eseguire in problemi durante una situazione di emergenza.

Ad esempio, se il backup completo del database F è danneggiato, a meno che non è ancora disponibile il backup completo del database precedente, il database non saranno recuperabile. Se il backup differenziale del database D1 viene eliminato, non appena viene completata D2, quindi lo scenario in di Figura 2 non sarà più possibile e la sequenza di ripristino implica che tutti i backup del log delle transazioni dopo il backup completo del database--una sequenza di ripristino potenzialmente molto lunghi.

Ciò genera la domanda di "Quando dovrebbero si elimina i backup precedenti?" La risposta è indubbiamente "IT varia!" Se non si dispone di un obbligo legale per mantenere le copie di backup intorno a un certo periodo di tempo, quindi spetta all'utente e varia a seconda della strategia di backup che è necessario ed è necessaria la quantità di spazio su disco. A prescindere dal fatto che, non eliminare immediatamente i backup precedenti, non appena viene eseguita una nuova, è consigliabile mantenere almeno uno o due completo cicli di backup prima di ottenere liberarsi dei backup meno recenti. Idealmente, dovrebbe verificare le copie di backup prima di rimuovere quelli meno recenti.

Per i backup del log delle transazioni, in genere è necessario disporre tutti gli da quando è stato eseguito l'ultimo backup completo del database, come che è la sequenza di ripristino di fallback finale. Se una singola transazione backup del log del log delle transazioni "catena" di backup è danneggiato o mancante, l'operazione di ripristino non può continuare oltre il divario. Come affermato in precedenza nell'articolo precedente, la verifica dell'integrità dei backup è una parte fondamentale di poter ripristinare correttamente.

È possibile trovare ulteriori dettagli su capire che cosa si è in grado di ripristinare nell'argomento della documentazione in linea completa"Utilizzo di sequenze di ripristino configurazione di database di SQL Server".

Scenari di ripristino configurazione di esempio

Lo scenario di ripristino più comune prevede un backup completo del database e quindi uno o più backup del log delle transazioni per portare avanti il database nel tempo. È possibile farlo tramite SQL Server Management Studio (SSMS) o tramite Transact-SQL, anche se c'è qualcosa che è necessario essere a conoscenza se si prevede di utilizzare direttamente i comandi RESTORE.

Quando viene ripristinato un backup, sono disponibili tre opzioni per il modo in cui viene completata l'operazione di ripristino e tutte le relative alla fase di ripristino comando Annulla. Come viene ripristinato ogni backup successivi nella sequenza di ripristino, la fase di ROLLFORWARD del ripristino viene sempre eseguita, ma la fase di comando Annulla non può essere eseguita fino a quando non è stato ripristinato il backup molto l'ultimo della catena di backup del log delle transazioni. Infatti, non appena viene completato il ripristino, è possibile applicare nessun ulteriore backup del log delle transazioni, in modo che tutti consente di ripristinare non per eseguire la fase di comando Annulla del ripristino deve specificare la sequenza di ripristino.

L'impostazione predefinita, è purtroppo, per eseguire la fase di comando Annulla del ripristino--l'equivalente di utilizzando l'opzione WITH RECOVERY dell'istruzione RESTORE. Quando si ripristinano più copie di backup, occorre fare attenzione che ciascuna di esse specifica WITH NORECOVERY. Infatti, il modo più sicuro è utilizzare l'opzione WITH NORECOVERY in tutte le operazioni di ripristino nella sequenza di ripristino e quindi manualmente completare il ripristino in seguito. Ecco alcuni esempio di codice Transact-SQL per ripristinare un backup completo del database e due backup del log delle transazioni e quindi completare manualmente il ripristino per portare in linea il database:

RESTORE DATABASE DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Full_051709_0000.bak'
CON LA SOSTITUZIONE, CHECKSUM, RECUPERO;
VAI

DBMaint2008 REG RESTORE FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0100.bak'
CON RECUPERO;
VAI

DBMaint2008 REG RESTORE FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
CON RECUPERO;
VAI

RESTORE DATABASE DBMaint2008 WITH RECOVERY;
VAI

Si noti che ho utilizzato inoltre l'opzione di CHECKSUM sul ripristino del backup completo del database per fare in modo che eventuali checksum di pagina presenti nel database da ripristinare sono verificate come essi vengono ripristinati.

Se non è stato specificato WITH NORECOVERY nella prima istruzione RESTORE, viene restituito il seguente errore:

Msg 3117, livello 16, stato 1, riga 1
Impossibile ripristinare il registro o un backup differenziale perché nessun file pronti per il rollforward.
Msg 3013, livello 16, stato 1, riga 1
RESTORE LOG verrà terminato in modo anomalo.

È necessario prestare particolare attenzione a utilizzare l'opzione a destra, in caso contrario si corre il rischio di dover avviare di nuovo una sequenza di ripristino lunga--non esiste un modo per annullare ripristino una volta completato.

È disponibile, tuttavia, un'interessante opzione che effettua che--tipo di opzione WITH STANDBY. Questo è l'ultimo delle tre opzioni menzionato in precedenza. Funziona eseguendo la fase di comando Annulla del ripristino, ma mantiene una nota di quanto accadeva (in un file di "ripristino" cui nome e il percorso specificato) e quindi consente l'accesso in sola lettura al database. Il database è coerente mediante transazioni, ma hanno la possibilità di continuare con la sequenza di ripristino. Se si decide di continuare, il comando Annulla viene stornato (utilizzando il contenuto del file annullamento) e quindi viene ripristinato il successivo file di registro delle transazioni. Ciò risulta utile in due scenari: Per consentire l'accesso in sola lettura per un database secondario di distribuzione dei log e per esaminare il contenuto del database durante la sequenza di ripristino.

Se l'emergenza che sta recuperando dal comporta l'eliminazione accidentale di una tabella, ad esempio, si desideri eseguire un ripristino in un momento. Esistono diversi modi per eseguire questa operazione, ma è più comune in cui si desidera ripristinare il database, ma garantire che il ripristino non passaggio oltre un certo periodo di tempo. In tal caso è possibile utilizzare l'opzione WITH STOPAT per impedire il ripristino del log delle transazioni da verrà passato l'ora che si è certi che la tabella è stata eliminata. Ad esempio, utilizzando l'esempio di Transact-SQL sopra, volevo impedire che il database da ripristinare oltre 1: 45 del mattino, potuto utilizzare la sintassi seguente nella seconda istruzione RESTORE LOG:

DBMaint2008 REG RESTORE FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
CON RECUPERO STOPAT = ' 2009 - 05 - 17 01:45:00.000 ';
VAI

Potuto anche combinare STOPAT e STANDBY per vedere se il punto corretto che è stato in tempo e quindi, se non, ripristinare il backup del log delle transazioni stesso con un tempo di pochi secondi in un secondo momento e così via. Questo tipo di operazione diventa molto noioso, ma potrebbe essere l'unica soluzione se non si conosce l'ora in cui un'operazione ha avuto luogo.

Una trattazione completa di queste e altre opzioni per l'istruzione RESTORE sono reperibili nell'argomento della documentazione in linea"RESTORE argomenti (Transact-SQL)".

Una delle più interessanti nuove funzionalità introdotte in SQL Server 2005 Enterprise Edition era disponibilità parziale del database. Questa funzionalità consente a un database di filegroup multi essere in linea e disponibile come long come almeno il filegroup primario è in linea. Ovviamente, non è possibile accedere ai dati in qualsiasi filegroup non in linea, ma questa funzionalità consente a un database di dimensioni molto grande essere suddivisi in filegroup separati per recuperabilità più facile e veloce. Un'altra funzionalità sola Enterprise è stato aggiunto è la possibilità di eseguire ripristini piecemeal (ad esempio, un unico filegroup da un database di filegroup multi) in linea, mentre il resto del database è in uso per l'elaborazione.

Queste due funzionalità combinate abilitare alcuni scenari di ripristino abbastanza sofisticato ed efficiente, purché il database è stato ideato in questo modo e le copie di backup corrette esiste.

Troverete un'eccellente, approfondite articolo tecnico su SQL Server dal titolo "Microsoft SQL Server 2005 parziale database disponibilità" con alcuni esempi esaurienti sul disponibile all'indirizzo tinyurl.com/mbpa65. È inoltre disponibile una registrazione 75 minuti di Kimberly l. Tripp recapito di una sessione di area EMEA Tech-ed intitolata"Disponibilità di SQL Server 2005 VLDB e strategie di ripristino"che è anche opportuno guardando.

Considerazioni sul ripristino di un altro percorso

Lo scenario di ripristino più semplice è quando il database è stato ripristinato nella stessa istanza di SQL Server a cui esso è in genere collegata e con lo stesso nome. Come allontanare ulteriormente da tale scenario, aftermath dell'operazione di ripristino diventa più complesso.

Se viene ripristinato il database sulla stessa istanza, ma con un nome diverso, potrebbe essere necessario apportare modifiche a elementi quali i pacchetti DTS/SSIS, i piani di manutenzione del database, le stringhe dell'applicazione e così tutto ciò che si basa su un nome di database.

Se il database è stato ripristinato in un'altra istanza nello stesso server, le cose ottenere molto più complicate:

• Gli account di accesso di SQL Server saranno diverse o potrebbe non esistere.
• Processi di Agente SQL e i pacchetti DTS/SSIS saranno diversi o potrebbero non esistere.
• Il database master è diverso, pertanto qualsiasi stored procedure definite dall'utente potrebbero essere mancante.
• Il nome dell'istanza di SQL Server saranno diverso, in modo che potrebbero verificarsi problemi di connettività client.
• Se viene ripristinato il database in un'istanza di un altro server, tutti gli elementi elencati viene applicato, ma vi possono essere aggiunti i problemi di protezione come account di Windows potrebbero essere diversi e potrebbero essere in un altro dominio di Windows.
• Un'altra considerazione è l'edizione di SQL Server viene ripristinato il database. Alcune funzionalità che, se utilizzato nel database, impostare il database "Enterprise sola"--non può essere ripristinato in edizione standard (o inferiore) istanza di SQL Server.
• In SQL Server 2000 e versioni precedenti, non si tratta di un problema. In SQL Server 2005, se viene utilizzato la tabella o indice di partizionamento, il database è "Sola organizzazione." In SQL Server 2008, l'elenco di funzionalità è:
• Acquisizione dei dati di modifica
• Crittografia dati trasparente
• Compressione dei dati
• Partizionamento

Tutti questi richiedono i privilegi sysadmin per attivare, ad eccezione di compressione dei dati, che può essere attivata da un proprietario della tabella, pertanto potenzialmente danneggiare un piano di ripristino di emergenza che riguardano il ripristino a un'istanza di Standard Edition. È possibile sapere se una di queste funzionalità vengono utilizzata nel database utilizzando sys.dm_db_persisted_sku_features DMV e regolare di conseguenza il piano di ripristino di emergenza.

Esaminare più profondo

Come avviene con il primo articolo della serie nei backup sono molti gli aspetti delle operazioni di ripristino che non ho spazio sufficiente per coprire. Ora che conosci le nozioni di base, tuttavia, è possibile esplorare alcuni collegamenti documentazione in linea e blog per informazioni più approfondite. Il modo migliore per l'avvio nella documentazione in linea è l'argomento"Cenni preliminari su ripristino (SQL Server) e di ripristino". È inoltre possibile trovare numerose informazioni su mio blog, a partire da categoria backup o ripristino.

Il principale takeaway che mi piacerebbe di ottenere da questo articolo è che per recuperare correttamente un database utilizzando i backup, è necessario mettere in pratica per assicurarsi di che sapere cosa fare. Non si desidera essere apprendere la sintassi per il comando RESTORE durante una situazione di ripristino di emergenza high-pressure. È inoltre possibile trovare che la strategia di backup non consente di recuperare all'interno dei requisiti aziendali. Forse richiedono troppo tempo per ripristinare i backup, forse i backup del log vengono sovrascrivere accidentalmente reciprocamente o forse si è dimenticato di eseguire il backup del certificato del server utilizzato per attivare la crittografia trasparente dei database in SQL Server 2008.

Il modo migliore per preparare per d'emergenza è di gran lunga predisporre un piano di ripristino sono elencati i passaggi per passare e disporre di un set di script utili per identificare quali i backup esistono e l'ordine in cui ripristinarli. Mi piace sempre a dire che questo deve essere scritto da DBA più senior del team e testato dall'amministratore di grado inferiore più--per garantire che tutti gli utenti possono attenersi alla procedura in modo sicuro. Tuttavia, se si è un amministratore del database involontari, sarà necessario assemblare un piano di se stessi e assicurarsi che è possibile seguire.

Nel prossimo articolo spiegherò come ripristinare il danneggiamento del database se non si dispone di alcun backup e il motivo per cui è possibile scegliere di eseguire un'operazione di ripristino anche se si dispone di copie di backup.
Nel frattempo e come sempre, se si dispone di eventuali commenti e suggerimenti o domande, eliminare mi riga-- Paul@SQLskills.com.

Grazie a Kimberly l. Tripp per fornire una revisione tecnica di questo articolo.

Paul s. Randal è la gestione director di SQLskills.com, un MVP per SQL Server e Microsoft direttore regionale. Ha lavorato nel team SQL Server Storage Engine in Microsoft dal 1999 al 2007. Randal 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, un'elevata disponibilità e la manutenzione del database ed è un normale relatore a conferenze di tutto il mondo. Ha blog all'indirizzo SQLskills.com/blogs/paul e si trova in Twitter come @ PaulRandal.