Cenni preliminari su architettura di database di Exchange Server e il motore di database

Traduzione articoli Traduzione articoli
Identificativo articolo: 271987 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

In questo articolo viene fornita una panoramica di generale dell'architettura di database e motore di database per Microsoft Exchange Server. La discussione include informazioni sui componenti di database, manutenzione di coerenza del database, possibili tipi di errori di database e utilità del database.

Informazioni

Exchange Server utilizza database basati su transazione a tolleranza d ' errori per archiviare i messaggi e informazioni di directory, prima di applicare al database. Per Exchange Server 5.5 Standard Edition, ogni database può aumentare a un massimo di 16 gigabyte (GB). Per Exchange Server 5.5 Enterprise Edition, dimensione è limitata solo dall'hardware.

Se si verifica un'interruzione dell'alimentazione o altro errore di chiusura anomala del sistema, Exchange Server utilizza i file di registro delle transazioni per ricostruire i dati già accettati dal server ma non ancora scritti nel database.

Componenti di database

La struttura di server si basa su tecnologie standard del database. Il sistema si basa su un motore di database incorporato che viene disposto la struttura del disco per Exchange Server e gestisce la memoria. La tecnologia di database viene inoltre utilizzata dietro le quinte da altre applicazioni di Windows, ad esempio, WINS (Windows Internet Name Service) e DHCP (Dynamic Host Configuration Protocol).

Archivio informazioni

L'archivio di informazioni, ovvero il componente chiave per la gestione di database in Exchange Server, è effettivamente due database distinti. Database dell'archivio informazioni privato Priv.edb, gestisce i dati nelle cassette postali utente. L'archivio informazioni pubblico Pub.edb, gestisce i dati nelle cartelle pubbliche.

L'archivio informazioni funziona con l'interfaccia MAPI (Messaging Application Programming Interface) e il motore di database per garantire che tutte le azioni dell'utente vengono registrate sul disco rigido del server. Ad esempio, quando un utente salva un messaggio in Microsoft Outlook, MAPI chiama innanzitutto l'archivio informazioni, che quindi chiama il motore di database, che quindi scrive le modifiche su disco.

Motore di database JET

Database di Exchange Server si basano sul formato di JET, file di cui Registro utilizza per tenere traccia e gestire informazioni. Microsoft JET è un motore di avanzate database di multithreading di 32 bit che combina la velocità e le prestazioni con altre funzionalità avanzate per migliorare la funzionalità di elaborazione basato sulle transazioni.

Il motore di database memorizza nella cache il disco nella memoria per lo swapping di pagine di (KB) di 4 kilobyte di dati in e out di memoria. Aggiorna le pagine in memoria e si scrive le pagine nuove o aggiornate sul disco. In questo modo il sistema più efficiente poiché quando le richieste provengono, i dati del buffer motore di database in memoria anziché verrà costantemente sul disco.

Nelle versioni precedenti di Exchange Server 5.5, la cache del buffer è di dimensioni fisse. Se è necessaria più memoria, è necessario che l'amministratore di modificare manualmente la dimensione del buffer.

In Exchange Server 5.5, allocazione del buffer dinamici consente la cache del buffer aumentare o ridurre, seconda quanta memoria è disponibile e quali risorse sono in uso da altri servizi in esecuzione sul computer Microsoft Windows NT Server. Se altri servizi non siano utilizzando memoria, il motore di database di Exchange Server occupa tutta la memoria è necessario. Se necessario memoria per altri servizi, il motore di database fornisce alcuni memoria copiandola pagine sul disco rigido e ridurre la dimensione del buffer.

Quando un utente effettua una richiesta, il motore di database Carica la richiesta in memoria e contrassegna le pagine come "modificato" (una pagina "dirty" consente di è una pagina è stata scritta con i dati che è ancora correntemente in memoria). Queste pagine dirty in un secondo momento vengono scritti sul disco per database dell'archivio informazioni.

Mantenere la coerenza database

Anche se la memorizzazione nella cache in memoria è il modo più efficiente per elaborare i dati, un effetto è che informazioni sul disco non completamente aggiornate. Pagine dirty in memoria che i database siano contrassegnate come incoerente anche se Exchange Server è in esecuzione normalmente. I database sono realmente in uno stato coerente solo quando tutte le pagine dirty sono correttamente trasferite su disco durante un arresto del sistema in cui non si verificano errori.

Che se ne cosa succede se si perda il contenuto della memoria? Se ad esempio se il server si blocca prima che i dati venga scritto su disco e si sono sinistro con un database incoerente? Exchange utilizza i file di registro delle transazioni per risolvere questa situazione.

File di registro delle transazioni

I file di registro delle transazioni conservare una copia protetta di dati volatili presente in memoria. Se il sistema si blocca, presupponendo che il database sia non danneggiato, i file di registro consentono recuperare i dati fino all'ultima transazione cui è stato eseguito il commit prima dell'arresto anomalo. (Si noti che è consigliabile che si archiviano i file di registro su un disco rigido dedicato, in modo che i registri non sono risentono di errori del disco possibili che possono danneggiare il database.)

Exchange è un sistema di messaggistica "basate su transazioni" e l'archivio informazioni è un database transazionale. Una transazione è un insieme di modifiche a un database, quali inserimenti, eliminazioni e aggiornamenti, in cui il sistema segue le quattro condizioni invarianti "ACID":
  • Verificano è tutte le operazioni di atomic: O nessuno di essi si verificano.
  • Coerenti: Il database viene trasformato da uno stato corretto in un altro.
  • Isolata: Modifiche non sono visibili solo dopo il commit.
  • Permanenti: Le transazioni di commit vengono conservate nel database anche se il sistema si blocca.
Seguendo questi condizioni invarianti significa che il motore di database di una transazione il commit solo quando è possibile garantire che i dati sono durevoli o permanente, contro gli arresti anomali o altri errori. Il motore di database esegue il commit dei dati solo quando i dati sono stati trasferiti dalla memoria il file di registro delle transazioni sul disco rigido.

Per spostare un messaggio dalla cartella Posta in arrivo nella cartella importante, ad esempio, Exchange Server esegue tre operazioni:
  1. Elimina il messaggio dalla cartella Posta in arrivo
  2. Inserisce il messaggio nella cartella importante
  3. Aggiorna le informazioni relative a ogni cartella per riflettere il numero di elementi non letti e
Queste operazioni vengono eseguite in un'unica transazione. L'ordine delle operazioni è irrilevante. Server possibile eliminare il messaggio dalla cartella Posta in arrivo poiché l'eliminazione è stato eseguito il commit, in solo quando il messaggio viene inserito in modo sicuro la cartella importante. Anche se il sistema si blocca, Exchange Server non si perde un messaggio durante lo spostamento e non finisce con due copie del messaggio.

Dal punto di vista logico, si potrebbe pensare di dati come spostare dalla memoria il file di registro e quindi al database sul disco, ma cosa succede in realtà è che dati verranno spostati dalla memoria del database sul disco. I file di registro sono ottimizzati per operazioni di scrittura ad alta velocità, in modo che durante il normale funzionamento, il motore di database legge mai effettivamente i file di registro. Legge i file di registro solo se il servizio Archivio informazioni si interrompe in modo anomalo o blocco e il motore di database da ripristinare riproducendo i file di registro.

il file di checkpoint

Il motore di database mantiene un file di checkpoint denominato EDB.chk per ogni sequenza di file di registro per tenere traccia dei dati che non sono ancora stato scritti nel file di database sul disco. Il file di checkpoint è un puntatore nella sequenza di registro che indica in cui nel Registro di file dell'archivio informazioni deve avviare il ripristino in caso di un errore. Il file di checkpoint è essenziale per il ripristino efficiente. Senza di essa, l'archivio informazioni iniziare dall'inizio del file registro meno recente sul disco e controllare tutte le pagine di ogni file di registro per determinare se è stato già stati scritti del database, un processo richiede molto tempo, soprattutto se si desidera eseguire è rendere coerente il database.

Il file di checkpoint si trova sul disco di sistema. Se si dispone per ripristinare il disco di sistema, questo file è probabilmente manca o con solo una versione non valida. Ma nella maggior parte dei casi il file di checkpoint si occupa di se stesso.

registrazione normale

I passaggi seguenti illustrano il processo di "registrazione normale" in cui i dati vengono scritti i file di registro delle transazioni:
  1. L'utente invia un messaggio.
  2. MAPI chiama l'archivio informazioni per indicare che l'utente invia il messaggio.
  3. L'archivio informazioni avvia una transazione nel modulo del database e apporta le modifiche corrispondenti ai dati.
  4. Il motore di database registrata la transazione in memoria dirtying una nuova pagina in memoria.
  5. Contemporaneamente, il motore di database protegge la transazione nel file di registro delle transazioni e crea un record di log. Quando viene il motore di database raggiunge la fine di un file di registro delle transazioni, esegue il rollback e crea di un nuovo file registro nella sequenza.
  6. Il motore di database scrive la pagina dirty nel file di database sul disco rigido.
  7. Il file di checkpoint viene aggiornato.
registrazione circolare

Exchange Server supporta una funzionalità denominata registrazione circolare, in cui è stata implementata in un momento quando gli amministratori erano più preoccuparsi di spazio su disco server rispetto a informazioni sul ripristino dei dati.

La registrazione circolare funziona molto la stesso modo come normale registrazione ad eccezione del fatto che il file di checkpoint è essenziale per tenere traccia delle informazioni che vengono trasferite su disco. Durante la registrazione circolare, come i miglioramenti del file di checkpoint nel file di registro successivo, il file obsoleti vengono riutilizzati. In questo caso, non è possibile utilizzare i file di registro sul disco in combinazione con supporto di backup per ripristinare la transazione di commit più recente.

Per impostazione predefinita, la registrazione circolare è attivata in Exchange Server 5.5 per mantenere una dimensione fissa per i file di registro e impedire la crescita. Quando un file di registro raggiunge il limite di 5 MB, il motore di database verrà eliminato e crea un nuovo file di registro nella sequenza. Di conseguenza, Exchange Server mantiene solo dati sufficienti sul disco rigido per rendere coerente se si verifica un arresto anomalo il database.

Si consiglia di disattivare la registrazione circolare sul computer Exchange Server. La registrazione circolare può riduce la necessità di spazio su disco, ma elimina inoltre la possibilità di ripristinare l'ultima transazione di cui è stato eseguito il commit prima di un errore. È Impossibile riprodurre file di registro e solo possibile ripristinare i dati fino all'ultimo backup completo. Anche se un solo file di log viene sovrascritto, non è possibile ripristinare le altre 99 percento di dati del registro.

In effetti, la registrazione circolare Nega i vantaggi di un sistema basato su transazioni. Lasciare attivata la registrazione circolare è utile solo se i dati non è necessario o se si dispone di altri metodi di ripristino dei dati. Se si è preoccupati per i file di registro utilizzo delle risorse disco, è preferibile per essi pulire effettuando regolari backup in linea. Backup rimuove automaticamente i file di registro delle transazioni quando non sono più necessari.

Protezione dei dati

Sembra logico che i file di database sono l'aspetto più importante di recupero dei dati. Ma, in Exchange Server, i file di registro delle transazioni sono più importanti poiché contengono informazioni che non sono nei file di database. (Questo è motivo per cui sarà necessario individuarli su un server stabile e inserirli nei dischi dedicati e ad alte prestazioni, anche se ciò significa che inserire i file di database su dischi più lenti).

I file di registro delle transazioni conservare una copia protetta sul disco di dati volatili presente in memoria in modo che il sistema possibile ripristinare in caso di errore. Se il sistema si blocca, ma il database è non è danneggiato, purché i file di registro, è possibile ripristinare i dati fino all'ultima transazione cui è stato eseguito il commit prima dell'errore.

I file di registro delle transazioni inoltre rendere la scrittura dei dati più efficienti, perché è più rapido per aggiornare le pagine in sequenza in un file di registro da per inserire le pagine del database. Quando avviene una modifica nel database, il motore di database aggiorna i dati in memoria. Scrive in modo sincrono di un record della transazione nel file di registro, indicando come ripetere la transazione, se il sistema non. Il motore di database quindi scrive i dati al database sul disco. Per ridurre l'input/output del disco, il motore di database trasferisce pagine per il disco in batch.

Ogni file di registro in una sequenza è in può di contenere fino a 5 MB di dati. Quando un file registro è pieno, viene rinominato come file di registro precedente, e un altro viene creato con il nome del file edb.log. Server associa ogni file di log a un numero di generazione esadecimale. Poiché i file di registro possono avere lo stesso nome, gli indicatori di motore di database l'intestazione in ogni file nella sequenza con una firma univoca in modo che è possibile distinguere tra diverse generazioni di file di registro.

Database legata al danneggiamento della

Exchange potrebbe verificarsi un errore, ad esempio un guasto hardware, che richiede il sistema tenta di tornare in uno stato coerente. Poiché esistono diversi tipi di danneggiamento del database con diversi sintomi, per diagnosticare e risolvere i problemi sono necessari diversi strumenti e tecniche.

Esistono due tipi di danneggiamento:
  • Danni fisici
    Al livello più basso, è possono che i dati vengano danneggiati fisicamente sul disco. In genere si tratta di un problema hardware che richiede sempre di eseguire il ripristino da backup.
  • Danneggiamento logico
    Danneggiamento logico tipica viene a livello di database. Ad esempio, database modulo di gestione potrebbero verificarsi voci di indice puntare a valori mancanti. Danneggiamento logico può verificarsi anche a livello di applicazione, in cassette postali, i messaggi, cartelle e gli allegati. Ad esempio, danneggiamento a livello di applicazione potrebbe causare conteggi dei riferimenti non corretti, accesso non corretto di livelli di controllo, un'intestazione di messaggio senza un corpo del messaggio e così via.

Danneggiamento fisica della

Danni fisici sono grave poiché è possibile eliminare i dati e l'unica cosa che è possibile eseguire è ripristinare Exchange da copia di backup. È importante di subito danni fisici di rilevare e risolvere rapidamente i problemi.

rilevamento di danneggiamento fisica della

Danni fisici nell'archivio informazioni genera i seguenti errori nel registro applicazione del Visualizzatore eventi:
  • ? 1018 (JET_errReadVerifyFailure) I dati per leggere dal disco non sono identico i dati che è stato scritto su disco.
  • -1022 (JET_errDiskIO) il sistema operativo, hardware o driver di periferica ha restituito errori.
  • -510 JET_errLogWriteFail I file di registro dell'istruzione sono esaurimento dello spazio su disco oppure è presente un errore hardware con il disco di file registro.
Anche se viene visualizzato in genere un messaggio di errore 1018 o-1022 viene danni fisici, è anche possibile rilevare danni fisici eseguendo il backup in linea, ovvero il metodo consigliato Microsoft per il backup dei dati. Backup in linea è anche il modo migliore per rilevare danni in un file di database perché è il solo processo sistematicamente controlla ogni singola pagina nel database.

Quando si esegue un backup in linea, il software di Windows NT backup legge ogni pagina di 4 KB nel file di database, lo passa al modulo di gestione di database e quindi lo scrive su nastro. Il motore di database verifica che il checksum ogni pagina sia corretto. Se il checksum della pagina non corrisponde al checksum che calcola il motore di database, è database fisico danneggiato sul disco rigido e i registri di backup NT un errore -1018.

impedire il danneggiamento fisica della

Il modo migliore per evitare il danneggiamento fisico è consiste da configura il server con componenti hardware di qualità e configurare correttamente il sistema. Assicurarsi che sono non eseguire utilità per il livello di file, ad esempio software antivirus, con i file di database e di log sul computer che esegue Exchange Server.

Se si dispone di hardware affidabile, non sarà presente indicazioni di danni fisici. Se si esegue in modo coerente in errori ? 1018, probabilmente dispone un problema hardware, probabilmente di un errato disco né controller del disco.

Una parola sulla cache write-back: alcuni controller matrice per la memorizzazione nella cache write-back erroneamente restituire commit corretto nelle transazioni prima che i dati sono stato effettivamente protetti su disco. Il metodo più sicuro consiste nel disattivare write-back a meno che il processo della batteria non disponga di backup. Se si utilizza la memorizzazione nella cache write-back, evitare verificando che i dati sono completamente protetti e di disporre le procedure per garantire che dati memorizzati nella cache sono ripetuti per i dischi a destra dopo un arresto anomalo di un database danneggiato.

ripristino da un danneggiamento fisica della

Il solo recuperare dal danneggiamento del database fisico consiste nel ripristinare dal backup buona ultimo (se è stato eseguito un backup senza errori, è buona) e inoltrare i file registro per portare il sistema in uno stato coerente e non danneggiato. Errore ripetuti indica probabilmente un problema con il disco in cui si trova il database.

Non realmente esiste un modo sicuro per ripristinare il danneggiamento fisico al database. È possibile eseguire Eseutil.exe Utilità in modalità di ripristino per ottenere il database di nuovo funzionanti, ma questa è sconsigliata poiché Eseutil elimina semplicemente le pagine non valide.

Nota: Se sia affatto possibile, evitare di utilizzare Eseutil in modalità di ripristino (Eseutil/p). Eseutil, fornito con Exchange Server, è l'ultima risorsa per ripristinare il database danni quando tutte le altre non riesce. In modalità di ripristino, viene ottenuto un database interrotto rieseguire semplicemente eliminando pagine danneggiate. Eseutil non deve mai essere utilizzato per recuperare i dati. Se si esegue il comando Eseutil /p , è inoltre necessario eseguire una deframmentazione non in linea ( Eseutil /d ) ed è necessario eseguire il comando Isinteg - test alltests - correzione per ripristinare il database in uno stato coerente.

Legata al danneggiamento della logica

Danneggiamento logico è molto più difficile diagnosticare e risolvere più danni fisici perché danneggiamento logico non è prevedibile e in genere è causato da errori software. In genere richiede un problema per avvisare l'utente danneggiamento logico. (Danneggiamento logico è estremamente raro in Exchange Server 5.5.)

impedire legata al danneggiamento della logica

Poiché danneggiamento logico è così imprevisto, non è possibile infallibile per evitare. Tuttavia, esistono modi per ridurre il rischio:
  • Installare il service pack più recente per Microsoft Exchange Server versione 5.5 appena possibile. I Service Pack consente di correggere un numero di problemi in Exchange Server 5.5.

    Per ulteriori informazioni sui service pack e su come ottenerli, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportato di seguito:
    241740Elenco dei bug corretti in Exchange Server 5.5 Service Pack 3
    254682XADM: Correzioni di motore di database al Service Pack 3 per Exchange Server 5.5
    191014Come ottenere Exchange Server 5.5 Service Pack più recente
  • Assicurarsi che il computer di Exchange Server è protetto e che la configurazione non viene modificata.
Se si rileva un problema e il problema persiste dopo aver eseguito su queste precauzioni, aver può essere trovato un nuovo bug. Se questo è il caso, indicare di presto Microsoft.
ripristino legata al danneggiamento della logica

Danneggiamento logico può verificarsi nell'archivio informazioni o nel modulo del database. Poiché danneggiamento logico può causare seri danni ai dati, non ignorare segnalazioni degli errori.

È possibile utilizzare il Isinteg utilità per il controllo dei problemi l'archivio informazioni o l'utilità Eseutil per il controllo dei problemi nel motore di database. Nota si consiglia di utilizzare queste utilità solo come ultima risorsa dopo che si è tentato di ripristinare il sistema dal backup.

l'utilità Isinteg

Information Store Integrity Checker (ISINTEG) individua ed elimina errori dal database dell'archivio informazioni pubblico e privato. Questi errori possono impedire l'avvio dell'archivio informazioni o impedire agli utenti di accesso e ricezione, apertura o l'eliminazione di posta elettronica.

Isinteg non è destinato all'utilizzo come parte della manutenzione dell'archivio informazioni normale, si è fornita per facilitare in situazioni di ripristino di emergenza. Ad esempio, è possibile eseguire Isinteg per correggere contatori di archivio di informazioni in memoria quando si ricevono sincronizzati dopo un arresto anomalo del sistema.

Poiché l'utilità Isinteg funziona a livello di schema logico, è possibile recuperare dati che è Impossibile recuperare l'utilità Eseutil. Infatti, i dati sono validi per l'utilità Eseutil a livello di schema fisici possono essere dal punto di vista semantico non validi a livello di schema logico. Isinteg registra informazioni nel registro applicazione nel Visualizzatore eventi in modo che consente di monitorare l'avanzamento delle operazioni di ripristino.

L'utilità Isinteg è possibile eseguire due operazioni principale:
  • Patch l'archivio informazioni dopo un ripristino da un backup non in linea.
  • Esegue il test e gli errori eventualmente corretti nell'archivio informazioni.
Per ulteriori informazioni sulla risoluzione dei problemi l'archivio informazioni e utilità Isinteg, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
182081XADM: Descrizione dell'utilità ISINTEG

oppure vedere il documento Isinteg.rtf sul CD di Exchange Server 5.5, nella directory Support\Utils.

l'utilità Eseutil

L'utilità Eseutil esamina la struttura della tabelle di database e i record e deframmenta, Ripristina e verifica l'integrità dell'archivio informazioni e la directory. Poiché l'esecuzione di Eseutil in modalità di ripristino elimina semplicemente pagine danneggiate, è necessario utilizzare questa utilità solo dopo che si è tentato di eseguire il ripristino da backup.

Per ulteriori informazioni sull'utilità Eseutil, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
192185XADM: How deframmentazione con l'utilità ESEUTIL (Eseutil.exe)
oppure vedere il documento di Eseutil.rtf in Exchange 5.5 su un CD nella directory Support\Utils.

Backup dei dati

Poiché Exchange Server è basato sulle transazioni, evitare di eseguire un backup a livello di file o non in linea dei file di database sul disco. Il modo migliore per garantire la mantenendo inalterata di tutti i dati nel sistema, incluse le transazioni che non sono ancora stati scaricati su disco, consiste nell'eseguire regolari backup in linea.

Backup in linea

Backup in linea consente di eseguire il backup database di Exchange Server il supporto di backup senza arrestare il server. Quando Exchange Server sta eseguendo un backup in linea, tutti i servizi, tra cui l'archivio informazioni, continuano a funzionare normalmente. Pagine continuano a essere aggiornato in memoria e trasferire i file di database sul disco, le transazioni vengono registrate nei file di registro e il file di checkpoint continua a spostarsi.

Exchange viene utilizzato un file pat (patch) tiene traccia delle pagine aggiornate durante l'esecuzione il software di backup, per assicurarsi che le pagine che vengono modificate durante il backup vengono inoltre eseguito il backup. Esistono due file pat, Priv.pat per l'archivio informazioni privato e Pub.pat per l'archivio informazioni pubblico.

Quando si esegue un backup in linea, controllare regolarmente il Registro di applicazione nel Visualizzatore eventi per assicurarsi che i backup sono completata.

processo di backup in linea

Un programma di backup, ad esempio Windows NT backup (Ntbackup.exe), svolge le seguenti durante un backup completo o un backup di copia:
  1. Crea una copia del database ed esegue il backup su nastro.
  2. Aggiunge un sottoinsieme di pagine al file pat, le pagine che modificare dopo essere copiati su nastro.
  3. Il file edb.log corrente rinominato Edb x . log, dove x è il numero di generazione del file di registro in formato esadecimale e crea una nuova generazione log.
  4. In un backup completo, backup il file .pat e tutti i file registro dopo il checkpoint (tranne il nuovo EDB.log) su nastro. In un backup di copia, esegue il backup tutti i file di registro prima e dopo il checkpoint.
  5. In un backup completo, è necessario Elimina file di registro delle transazioni precedenti al checkpoint. In un backup di copia, non elimina qualsiasi file di registro delle transazioni.
Un programma di backup effettua le seguenti operazioni durante un backup differenziale o un backup incrementale:
  1. In un incrementale rende backup, una copia del Registro di file e ne esegue il backup su nastro. In un backup differenziale, copia il database su nastro.
  2. Aggiunge un sottoinsieme di pagine al file pat, le pagine che modificare dopo essere copiati su nastro.
  3. Rinomina il file edb.log corrente al log x Edb e crea una nuova generazione log.
  4. Esegue il backup il file .pat e tutti i file registro prima e dopo il checkpoint, tra cui il nuovo EDB.log, su nastro.
  5. Nella finestra di un backup incrementale, Elimina file registro delle transazioni meno il checkpoint. In un backup differenziale, non elimina i file di registro.

Backup non in linea

Provare a evitare di eseguire backup non in linea. In un backup in linea, il programma di backup gestisce i file, ma copia di backup non in linea è un processo manuale, laborioso è soggetto a errori umani. Inoltre, in un backup non in linea, è Impossibile convalidare il checksum ogni pagina del database. Backup in linea sono lo singolo strumento di più importante per il rilevamento danneggiamento e l'esecuzione di ripristino dei dati.

Per ulteriori informazioni sui backup, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportato di seguito:
191357XADM: Ripristino di un singolo database da backup completo in linea
179308XADM: Come verificare il backup in linea di Exchange

Proprietà

Identificativo articolo: 271987 - Ultima modifica: sabato 28 ottobre 2006 - Revisione: 5.1
Le informazioni in questo articolo si applicano a:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Chiavi: 
kbmt kbinfo KB271987 KbMtit
Traduzione automatica articoli
Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 271987
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com