Strategie di recupero dei database

  • Articolo

 

Ultima modifica dell'argomento: 2006-06-12

In questa sezione viene descritta la struttura di un database e vengono esaminate le strategie di recupero.

Nozioni fondamentali sulla struttura dei database

Per comprendere come è strutturato un database è necessario conoscere i livelli di pagina, i livelli di tabella ESE (Exchange Store Engine) e i livelli di applicazione di un database. Di seguito viene riportata una breve descrizione di ciascun livello.

Livello di pagina: il file contiene una serie ordinata di pagine (solitamente 4 kilobyte o un suo multiplo), con una struttura organizzativa comune condivisa da ciascuna pagina. Ciascuna pagina contiene informazioni di intestazione e dati della pagina. Le informazioni di intestazione contengono i checksum della pagina che consentono la verifica, da parte di Exchange, dell'integrità dei dati e la correzione degli errori relativi a singoli bit contenuti nella pagina.

Livello di tabella ESE: le tabelle gestite dal modulo di database ESE includono gruppi di pagine. Un tipico database di Exchange contiene migliaia di tabelle.

Livello di applicazione: ESE è un database di interesse generale che può essere utilizzato da applicazioni differenti. Ad esempio, sia il servizio directory di Exchange sia quello di Active Directory utilizzano ESE. Il motore del database ESE memorizza informazioni all'interno delle proprie tabelle secondo quanto stabilito da una determinata applicazione. Il modulo ESE da solo non è in grado di comprendere le relazioni che intercorrono tra tabelle, definite dall'applicazione, né il significato dei dati memorizzati in ciascuna tabella.

Nozioni fondamentali sulle strategie di recupero dei database

La strategia più semplice per recuperare eventuali file di database danneggiati prevede il ripristino di una copia valida del database da una copia di backup e l'esecuzione del roll forward del database mediante l'applicazione in sequenza dei file di registro delle transazioni generati successivamente al backup. Per utilizzare questa strategia, è necessario che le tre condizioni indicate di seguito siano soddisfatte.

  • È disponibile una copia di backup valida del database.
  • Tutti i file di registro delle transazioni generati dopo il backup sono disponibili e non sono danneggiati.
  • Il problema del database non è stato causato da un danneggiamento logico o dall'eliminazione involontaria di un suo elemento. Ad esempio, se il danneggiamento o l'eliminazione dei messaggi sono causati da un programma antivirus, le operazioni eseguite da quest'ultimo sono incluse nei registri delle transazioni e vengono riprodotte nel database dopo il ripristino dal backup.

Di seguito vengono descritte altre strategie di recupero dei database.

Spostamento delle cassette postali

Quando si sposta una cassetta postale di Exchange in un database diverso, i contenuti della cassetta vengono elaborati dall'archivio informazioni di Exchange come se fossero appena stati creati. Gli elementi danneggiati vengono ignorati. Di conseguenza, spostare tutte le cassette postali in un nuovo database è un'ottima strategia per rimuovere gli elementi danneggiati e allo stesso tempo recuperare la maggior quantità di dati degli utenti.

Dopo la rimozione di una cassetta postale, i profili dei client di Outlook vengono aggiornati automaticamente per indirizzare i client al nuovo database o server. Perché ciò accada, il server precedente deve rimanere in linea e il relativo servizio Archivio informazioni deve essere in esecuzione finché tutti i client si sono connessi almeno una volta al fine di reindirizzarli. Se il server precedente non rimane in linea, è necessario aggiornare i profili dei client di Outlook manualmente o tramite script.

I file precedenti, relativi ai client che operano in modalità cache o non in linea, continueranno a funzionare anche dopo la rimozione di una cassetta postale. Quando viene rimossa una cassetta postale, la funzionalità relativa alle regole dei client viene mantenuta.

Relativamente agli effetti sul server di destinazione, spostare una cassetta postale è come recapitare nuovamente e contemporaneamente tutti gli elementi contenuti nella cassetta. Di conseguenza, se si spostano più cassette postali, è consigliabile eseguire tale operazione in ore di scarso traffico e fornire preliminarmente ai client informazioni relative al momento previsto per lo spostamento e alle modalità di assistenza disponibili nel caso di problemi di accesso a seguito dello spostamento.

Lo spostamento di più cassette postali genera nel database di destinazione un numero di file di registro delle transazioni del database superiore al normale. È necessario verificare attentamente lo spazio su disco del registro delle transazioni sul server di destinazione durante un'operazione di spostamento globale di cassette postali. Se si sta per esaurire lo spazio sul disco dei file di registro delle transazioni, è possibile eseguire un backup completo o incrementale in linea al fine di cancellare i file di registro oppure abilitare la registrazione circolare prima dello spostamento per disabilitarla subito dopo.

Lo spostamento di tutte le cassette postali in un nuovo database e l'eliminazione di quello precedente consente di aumentare la quantità di dati degli utenti recuperabili e, allo stesso tempo, di ridurre i periodi di inattività del database.

Per informazioni sulle modalità di spostamento di un database di Exchange in un altro server o gruppo di archiviazione, vedere Spostamento di un database delle cassette postali di Exchange in un server o un gruppo di archiviazione diverso.

Correzione del database

In genere, è consigliabile ripristinare un database solo quando è impossibile recuperarlo ed eseguirne il roll forward. Nella maggior parte dei casi, correggere un database richiede più tempo che ripristinarlo dal backup.

Nota   Se il database è gravemente danneggiato, la correzione richiederà un tempo più lungo, con scarse probabilità di riuscire a completare l'operazione con esito positivo. Utilizzando un tipico hardware per server aziendali, la correzione di un database integro o lievemente danneggiato richiederà circa un'ora per 5 GB di dati. Se si intendono includere nella progettazione dei contratti di servizio (SLA) i tempi necessari per la correzione, è opportuno valutare i propri valori di riferimento delle prestazioni utilizzando un database e un computer simili a quelli utilizzati per Exchange nell'organizzazione. Se il database è stato gravemente danneggiato, i tempi di correzione potrebbero aumentare di un fattore pari a 10 volte o più.

Per ulteriori informazioni su come utilizzare Eseutil per la correzione dei database, vedere Modalità di correzione di Eseutil /P.

Ripristino, correzione e unione

Il ripristino, la correzione e l'unione di un database rappresentano un esempio di strategia ibrida. È possibile applicare questa strategia quando si dispone di un backup valido del database, ma non di tutti i registri delle transazioni creati dopo il backup.

In questo caso, è possibile ripristinare il backup e, parallelamente, correggere la copia del database danneggiata in un gruppo di archiviazione di ripristino sullo stesso server o su un server di prova. È quindi possibile utilizzare la funzionalità del gruppo di archiviazione di ripristino per installare separatamente entrambe le copie dei database e unire i dati del database corretto al database ripristinato.

Se la correzione ha esito positivo, questa strategia offre la possibilità di recuperare quasi la stessa quantità di dati recuperabile utilizzando i registri delle transazioni. Per ulteriori informazioni sulle numerose strategie ibride applicabili tramite i gruppi di archiviazione di ripristino, vedere Using Exchange Server 2003 Recovery Storage Groups (https://go.microsoft.com/fwlink/?LinkId=47589).

Ulteriori informazioni

Per ulteriori informazioni vedere gli argomenti seguenti nella Guida dell'utilità di database di Exchange Server: