Descrizione delle opzioni di ripristino di emergenza per Microsoft SQL Server

Riepilogo

In questo articolo vengono illustrate varie soluzioni per il ripristino dei dati da un database di Microsoft SQL Server, in caso di emergenza. Anche in questo articolo vengono illustrati i vantaggi e gli svantaggi di ciascuna soluzione.

Ripristino di emergenza è un processo che è possibile utilizzare per il recupero di sistemi di informazioni e dati, in caso di emergenza.

Alcuni esempi di situazioni di emergenza includono un naturali o sintetiche o situazioni di emergenza, ad esempio un incendio o tecnica ad esempio un errore di due dischi in una matrice di Array di dischi RAID (Redundant Independent) 5.

Pianificazione del ripristino di emergenza è ciò che è dedicato alla preparazione di tutte le azioni che devono verificarsi in risposta a una situazione di emergenza. La pianificazione include la selezione di una strategia per il recupero di dati importanti. La selezione della strategia di ripristino di emergenza appropriato dipende dalle esigenze aziendali.

Nota: Le soluzioni che vengono trattate in questo articolo forniscono solo descrizioni generali delle tecnologie da utilizzare. Queste descrizioni generali sono per il confronto tra i vari metodi di ripristino di emergenza e piani di ripristino di emergenza. Prima di decidere su quale emergenza è migliore per la soluzione di ripristino, assicurarsi di osservare ognuna delle soluzioni di ripristino d'emergenza suggerito in maggiore dettaglio. Dopo avere illustrato ogni soluzione di ripristino di emergenza, in questo articolo vengono forniti collegamenti in cui è possibile trovare ulteriori informazioni su tale soluzione.

Clustering di failover

Il clustering di failover di Microsoft SQL Server 2000 è progettato per eseguire il failover automaticamente se si verifica un errore hardware o errore software. È possibile utilizzare per creare un cluster di failover per una singola istanza di SQL Server 2000 o più istanze di SQL Server 2000 clustering di failover di SQL Server 2000. Il clustering di failover consente a un sistema di database passare automaticamente l'elaborazione di un'istanza di SQL Server da un server non riuscita per un server funzionante. Di conseguenza, il clustering di failover è utile se si verifica un errore del sistema operativo o se si esegue un aggiornamento pianificato delle risorse di sistema del database. Inoltre, il clustering di failover aumenta la disponibilità dei server con nessun tempo di inattività.

Poiché il clustering di failover è progettato per la disponibilità di server a prestazioni elevate con quasi alcuna inattività del server, i nodi del cluster devono essere geograficamente vicini. Il clustering di failover non può essere utile se si verifica un errore di array di dischi.

Nota: Per implementare il clustering di failover, è necessario installare Microsoft SQL Server 2000 Enterprise Edition.

I seguenti sistemi operativi supportano il clustering di failover:
  • Microsoft Windows NT 4.0, Enterprise Edition
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003, Datacenter Edition
Questi sistemi operativi includono un componente installabile, Microsoft Cluster Service (MSCS). Per implementare il clustering di SQL Server di failover, è necessario installare MSCS.

Per ulteriori informazioni su MSCS e relativa installazione, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

Risorse di installazione di Microsoft Cluster Service 259267

Vantaggi e svantaggi dell'utilizzo del clustering di failover

Vantaggio
È ad alta disponibilità. Se il server primario non si verifica un failover clustering automaticamente.
Svantaggi
  • Sostenere una spesa maggiore. La gestione di due server è due volte il costo di gestione di un singolo server. Poiché è necessario mantenere i due server contemporaneamente, è più costoso installare e gestire i nodi del cluster.
  • I server devono essere nella stessa posizione. Se le filiali dell'organizzazione in tutto il mondo e i cluster attivo/attivo devono essere implementati nelle diramazioni, è molto diverso da un cluster di server a quorum standard di rete e l'infrastruttura di archiviazione che è necessario utilizzare. Pertanto, sebbene sia possibile, è preferibile non utilizzare server geograficamente distanti.
  • Non si dispone di alcuna protezione contro un guasto di matrice.
  • Il clustering di failover non consentono di creare cluster di failover a livello di database o a livello di oggetto di database, ad esempio il livello di tabella.
Per ulteriori informazioni sul clustering di failover, visitare il seguente sito Web Microsoft:Per ulteriori informazioni sul clustering di failover, fare clic sui numeri per visualizzare gli articoli della Microsoft Knowledge Base riportato di seguito:

243218 ordine di installazione per SQL Server 2000 Enterprise Edition on Microsoft Cluster Server

822250 support WebCast: procedure di ripristino di emergenza di clustering di failover di Microsoft SQL Server 2000

Per ulteriori informazioni sui criteri di supporto Microsoft per un cluster di failover di SQL Server, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

327518 criteri di supporto Microsoft per un cluster di failover di SQL Server

Il mirroring del database

Il mirroring del database è una soluzione di software principalmente per aumentare la disponibilità di database. È solo possibile implementare il mirroring su un singolo database. Il mirroring funziona solo con i database che utilizzano il modello di recupero completo. I modelli di recupero semplice e massa non supportano il mirroring del database. Pertanto, tutte le operazioni di massa vengono sempre registrate. Il mirroring del database funziona con qualsiasi livello di compatibilità del database supportati.

Vantaggi e svantaggi dell'utilizzo del mirroring del database

Vantaggi
  • Il mirroring del database aumenta la protezione dei dati.
  • Il mirroring del database aumentano la disponibilità di un database.
  • Il mirroring del database consente di migliorare la disponibilità del database di produzione durante gli aggiornamenti.
Svantaggi
  • Il database mirror deve essere identico al database principale. Ad esempio, tutti gli oggetti, gli account di accesso e le autorizzazioni devono essere identiche.
  • Il mirroring del database prevede il trasferimento di informazioni da un computer a un altro computer in rete. Di conseguenza, la protezione delle informazioni per il trasferimento di SQL Server è molto importante.

Replica transazionale peer-to-peer

La replica transazionale peer-to-peer è progettata per le applicazioni che possono leggere o potrebbero modificare i dati in qualsiasi database che partecipa alla replica. Inoltre, se tutti i server che ospitano i database sono disponibili, è possibile modificare l'applicazione per instradare il traffico ai server rimanenti. I rimanenti server contengono copie identiche dei dati.

Vantaggi e svantaggi dell'utilizzo della replica transazionale peer-to-peer

Vantaggi
  • Prestazioni di lettura sono migliorata in quanto è possibile distribuire attività tra tutti i nodi.
  • Aggregare le prestazioni di aggiornamento, inserire le prestazioni ed eliminare le prestazioni per la topologia simile le prestazioni di un singolo nodo, perché tutte le modifiche vengono propagate a tutti i nodi.
Svantaggi
  • La replica peer-to-peer è disponibile solo in SQL Server 2005 Enterprise Edition.
  • Tutti i partecipanti database devono contenere dati e schemi identici.
  • È consigliabile che ogni nodo di utilizzare il proprio database di distribuzione. Questa configurazione Elimina il rischio di SQL Server 2005 per avere un singolo punto di errore.
  • Non è possibile includere tabelle e altri oggetti in più pubblicazioni peer-to-peer all'interno di un database di pubblicazione.
  • È necessario disporre di una pubblicazione abilitata per la replica peer-to-peer, prima di creare le sottoscrizioni.
  • È necessario inizializzare le sottoscrizioni utilizzando una copia di backup o impostando il valore di tipo di sincronizzazione della sottoscrizione per la replica supporta solo.
  • La replica transazionale peer-to-peer non fornisce il rilevamento dei conflitti o la risoluzione dei conflitti.
  • Si consiglia di non utilizzare le colonne identity.

Manutenzione di un server di standby

È possibile creare e gestire un server di standby utilizzando uno dei seguenti metodi:
  • Distribuzione dei log
  • Replica transazionale
Ulteriori informazioni su ognuno di questi due metodi seguono.

Distribuzione dei log

La distribuzione dei log è incluso nel resource kit di Microsoft SQL Server 7.0, ed è completamente incorporato in Microsoft SQL Server 2000 Enterprise Edition e Microsoft SQL Server 2000 Developer Edition. La distribuzione dei log viene utilizzato un server di riserva che non viene utilizzato durante il normale funzionamento. Un server di standby è utile per il recupero dei dati in caso di emergenza. Livello di database, è possibile utilizzare solo la distribuzione dei log. È possibile utilizzare il livello di istanza.

Quando un server di standby in corso il ripristino dei log delle transazioni, il database è in modalità esclusiva e è inutilizzabile. Tuttavia, è possibile eseguire batch processi tra i ripristini di registro delle transazioni di report o Console comandi DBCC (Database) controlla per continuamente verificare l'integrità del server di standby. Per applicazioni quali server di supporto di decisione che richiedono l'elaborazione continua su un server di database, la distribuzione dei log non è un'opzione appropriata.

La latenza del server di riserva è basata su frequenza il backup del log delle transazioni vengono eseguite nel server primario e quindi applicata al server di standby. Se il server primario non riesce, si potrebbero perdere le modifiche apportate dalle transazioni avvenute dopo il log delle transazioni più recente backup.

Ad esempio, se backup del log delle transazioni vengono effettuate ogni 10 minuti, transazioni durante la più recente 10 minuti potrebbero essere perse. Ciò non significa necessariamente che gli aggiornamenti dei dati che vengono apportati al server primario durante il periodo di latenza andranno persi. In genere, è possono recuperati e applicati al server di warm standby con solo un lieve ritardo nel passare dal server primario al server di riserva nuovi aggiornamenti nel registro delle transazioni principale. Lo scopo principale della distribuzione dei log è di mantenere un server di standby. Se la gestione di che un server di standby è l'obiettivo principale, la distribuzione dei log è probabile che sia più adatta di altre soluzioni citati in questo articolo.

Vantaggi e svantaggi dell'utilizzo della distribuzione dei log

Vantaggi
  • È possibile recuperare tutte le attività di database. Il ripristino include tutti gli oggetti che sono stati creati come tabelle e viste. Include inoltre modifiche di protezione, ad esempio i nuovi utenti che sono stati creati e le eventuali modifiche di autorizzazioni.
  • È possibile ripristinare il database più veloce. Il ripristino del database e del log delle transazioni si basa sui formati di basso livello di pagina. Pertanto, la distribuzione dei log consente di velocizzare il processo di ripristino e comporta il rapido recupero dei dati.
Svantaggi
  • Il database non è utilizzabile durante il processo di ripristino perché il database è in modalità esclusiva nel server di standby.
  • Non vi è la mancanza di granularità. Durante il processo di ripristino, vengono applicate tutte le modifiche nel server primario al server di standby. È possibile utilizzare la distribuzione dei log per applicare le modifiche di alcune tabelle e per rifiutare le modifiche rimanenti.
  • Non vi è alcun failover automatico delle applicazioni. Quando il server primario non riesce a causa di una situazione di emergenza, il server di standby failover non viene eseguita automaticamente. Pertanto, è necessario reindirizzare in modo esplicito le applicazioni che si connettono al server primario al server di standby (failover).
Nota: Se lo scopo principale è di mantenere un server di standby, Microsoft consiglia di utilizzare la distribuzione dei log. Server di warm standby riflette tutte le transazioni che si verificano sul server primario. Tuttavia, è possibile utilizzare il server di standby quando il server primario non è disponibile.


Per ulteriori informazioni su come impostare un server di standby per la distribuzione dei log, fare clic sui numeri per visualizzare gli articoli della Microsoft Knowledge Base riportato di seguito:

323135 Microsoft SQL Server 2000 - come impostare il log shipping (white paper)

325220 support WebCast: distribuzione dei log di Microsoft SQL Server 2000

Per ulteriori informazioni sulla distribuzione dei log, visitare i seguenti siti Web Microsoft:

Replica transazionale

La replica transazionale consente inoltre di mantenere un server di standby. La replica transazionale replica i dati in un unico server (autore) a un altro server (server di sottoscrizione) con minore latenza più la distribuzione dei log. È possibile implementare la replica transazionale livello di oggetto di database come livello di tabella. Di conseguenza, Microsoft consiglia di utilizzare la replica transazionale quando è minore di dati per la protezione che è necessario disporre di un piano di ripristino rapido.

È possibile utilizzare una sottoscrizione push per imporre la replica transazionale tra due server con il server principale del server di pubblicazione e server di riserva come server di sottoscrizione. La replica transazionale assicura la replica dei dati. Quando il server di pubblicazione non riesce, il server di sottoscrizione può essere utilizzato.

Questa soluzione è esposto il mancato funzionamento del server di pubblicazione e server di sottoscrizione allo stesso tempo. In questo caso, non è possibile proteggere i dati. In tutti gli altri scenari, ad esempio il malfunzionamento di un distributore o un server di sottoscrizione, è consigliabile risincronizzare i dati nel server di sottoscrizione con i dati nel server di pubblicazione.

Utilizzare per gestire un server di standby solo quando non si implementano le modifiche dello schema o altre modifiche al database non viene implementato come protezione assume che la replica non supporta la replica transazionale.

Nota: La replica non è progettata per la manutenzione dei server di standby. Con la replica, è possibile utilizzare i dati replicati nel server di sottoscrizione per generare rapporti. È possibile utilizzare anche la replica ad altri usi generali senza dover eseguire l'elaborazione nel server di pubblicazione relativamente occupato.

Vantaggi e svantaggi dell'utilizzo della replica transazionale

Vantaggi
  • È possibile leggere i dati su un server di sottoscrizione mentre vengono apportate modifiche.
  • Le modifiche vengono applicate con minore latenza.

    Nota: Questo vantaggio potrebbe non essere applicabile in presenza di una delle operazioni seguenti:
    • Gli agenti di replica non sono impostati su Continua.
    • Gli agenti di replica vengono interrotti a causa di errori che possono verificarsi durante la replica.
La replica transazionale può richiedere più tempo per applicare le modifiche, poiché gli aggiornamenti batch di grandi dimensioni devono essere eseguiti durante la replica.
Svantaggi
  • Modifiche dello schema o modifiche di protezione che vengono eseguite nel server di pubblicazione dopo che la replica non saranno disponibili nel server di sottoscrizione.
  • Il server di distribuzione nella replica transazionale utilizza una connessione Open Database Connectivity (ODBC) o una connessione di Database OLE (OLEDB) per distribuire i dati. Tuttavia, la distribuzione dei log utilizza l'istruzione Transact-SQL basso livello ripristino transazione per la distribuzione dei log delle transazioni. Un'istruzione RESTORE TRANSACTION è molto più veloce di una connessione ODBC o una connessione OLEDB.
  • In genere, passare ai server Cancella configurazioni di replica. Pertanto, è necessario configurare la replica due volte:
    Quando si passa al server di sottoscrizione.
    Quando si passa al server di pubblicazione.
  • Se si verifica una situazione di emergenza, è necessario passare manualmente i server mediante il reindirizzamento di tutte le applicazioni server di sottoscrizione.
Per ulteriori informazioni sulla replica, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

195757 domande frequenti - SQL Server 7.0 - replica

Funzionalità di backup e ripristino

La funzionalità di Backup e ripristino di SQL Server fornisce un'importante misura di sicurezza per proteggere i dati importanti memorizzati nel database di SQL Server. È possibile creare una copia di un database (una copia di backup) utilizzando la funzionalità di Backup e ripristino e quindi archiviare la copia del database in una posizione protetta in caso di potenziale errore del server che esegue l'istanza di SQL Server. Se si verifica un errore di sistema di database o il danneggiamento del database, è quindi possibile utilizzare la copia di backup per ricreare il database o per ripristinare il database.

Quando si pianifica il ripristino di emergenza utilizzando la funzionalità di Backup e ripristino, inoltre determinare l'importanza dei dati nel database. Inoltre, determinare i requisiti di ripristino per il database. Ad esempio, determinare i requisiti di ripristino seguenti:
  • Il punto che si ripristina il database. È necessario decidere quale dei due seguenti si desidera eseguire:
    Ripristinare il database per la condizione della notte prima dell'errore.
    Ripristinare il database per la condizione di un punto di tempo più vicino possibile al momento dell'errore.
  • Per quanto tempo il database può essere disponibile. Se è necessario ripristinare il database immediatamente.
Dopo aver determinato i requisiti di ripristino, è possibile pianificare un processo di backup che gestisce un set di backup per soddisfare i requisiti

È possibile ripristinare un database solo alla condizione del punto di tempo in cui è eseguito il backup più recente. Transazioni eseguite dopo che il backup potrebbe andare perso. Di conseguenza, Microsoft consiglia di utilizzare la funzionalità di Backup e ripristino solo per le applicazioni non-database mission-critical.

Vantaggi e svantaggi dell'utilizzo della funzionalità di backup e ripristino

Vantaggi
  • È possibile eseguire il backup del database fino a supporti rimovibili per proteggersi dagli errori del disco.
  • Non è necessario dipendono dalla rete quando si utilizza il clustering di failover o la distribuzione dei log.
Svantaggi
  • Quando si esegue il backup del database, è possibile eseguire operazioni quali la creazione di tabelle, la creazione dell'indice, la compattazione del database o operazioni non registrate.
  • Se si verifica un errore, si potrebbero perdere i dati più recenti.
  • Se si verifica una situazione di emergenza, è necessario ripristinare manualmente il database.
Nota: Prima di utilizzare la procedura di Backup e ripristino in un ambiente di produzione, è consigliabile verificare accuratamente questa procedura in un ambiente di test.

Per ulteriori informazioni sulla funzionalità di Backup e ripristino, fare clic sui numeri per visualizzare gli articoli della Microsoft Knowledge Base riportato di seguito:

Webcast del supporto tecnico 325257 : ripristino del Database di SQL Server 2000: Backup e ripristino

Descrizione di 281122 di ripristino dei backup di file e filegroup in SQL Server

Per ulteriori informazioni sulla funzionalità di Backup e ripristino, visitare i seguenti siti Web Microsoft:

Ridondanza di disco dei dati utilizzando una matrice ridondante di dischi indipendenti (RAID)

Un RAID archivia i dati ridondanti su più dischi per fornire maggiore affidabilità e tempi di inattività ridotti per i server. Livelli RAID 0, 1 e 5 vengono generalmente utilizzati come opzioni di ripristino di SQL Server. Le tecnologie RAID menzionati consentono l'errore e la conseguente sostituzione di un singolo disco senza il server si. Se si verificano più errori del disco, i dati potrebbero non essere recuperabili. Si consiglia pertanto, che la gestione di dati ridondanti con una procedura di Backup e ripristino per assicurarsi che per evitare di perdere dati se un errore hardware o altri guasto.

RAID 0 utilizza la tecnologia di striping per un accesso più rapido mentre RAID 1 mirroring tecnologia per l'affidabilità dei dati. Una tecnica comune utilizzata nella gestione di database relazionali prevede l'utilizzo combinato di RAID 0 e RAID 1. Questa tecnica, due matrici di striping identiche di unità vengono aggiornate continuamente in modo che le informazioni memorizzate su entrambe le matrici siano identici. Se una matrice non riesce, in altro array ha automaticamente su fino a quando la matrice originale viene ripristinata.

RAID 5 (noto anche come striping con parità) utilizza un array di dischi con striping singolo con bit di parità scritte con i dati. Quando ogni disco non riesce, è possibile utilizzare i bit di parità per calcolare i dati mancanti, fino a quando non si sostituisce il disco. Quando si sostituisce il disco, è possibile utilizzare le informazioni di parità e i dati rimanenti per ricreare i dati dal disco e copiare i dati di ricreare sul nuovo disco. Tutte queste operazioni vengono eseguiti senza inattività del sistema di database. RAID fornisce molte altre opzioni e funzionalità per poter garantire che i sistemi di database esperienza come i tempi di inattività minimo possibile.

Vantaggi e svantaggi dell'utilizzo di un volume RAID

Vantaggio
Per evitare di perdere dati in caso di ogni disco.
Svantaggi
  • Potrebbero occorrere molto tempo per recuperare i dati.
  • Se non vengono più dischi, non sarà possibile ripristinare i dati importanti.
Per ulteriori informazioni su RAID, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

Panoramica di 100110 array ridondante di dischi (RAID)

Riferimenti

Per scaricare una versione aggiornata della documentazione in linea di SQL Server 2000, visitare il seguente sito Web Microsoft:Per ulteriori informazioni sulle altre opzioni di ripristino di emergenza, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

307775 gli articoli di ripristino di emergenza per Microsoft SQL Server

Per ulteriori informazioni sul clustering di failover, fare clic sui numeri per visualizzare gli articoli della Microsoft Knowledge Base riportato di seguito:

195761 domande frequenti - SQL Server 7.0 - Failover

260758 domande frequenti - SQL Server 2000 - domande del clustering di Failover

Aggiornamento di 274446 alla soluzione di failover di SQL Server 2000 consigliato per tutti i server virtuali non SQL Server 2000

280743 Windows clustering e siti geograficamente separati

Per ulteriori informazioni sulla funzionalità di Backup e ripristino, visitare il seguente sito Web Microsoft:Per ulteriori informazioni sulla funzionalità di Backup e ripristino, fare clic sui numeri per visualizzare gli articoli della Microsoft Knowledge Base riportato di seguito:

253817 come eseguire il backup dell'ultimo log delle transazioni quando il master e i file di database vengono danneggiati in SQL Server

314546 come spostare database tra computer che eseguono SQL Server

Per ulteriori informazioni sui file e cartelle catalogo full-text, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:

240867 come spostare, copiare ed eseguire il backup di file e cartelle catalogo full-text

Proprietà

ID articolo: 822400 - Ultima revisione: 30 gen 2017 - Revisione: 1

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2000 Standard Edition

Feedback