Comprensione e l'analisi degli errori di database di Exchange -1018, 1019 e -1022

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

In questa pagina

Sommario

In questo articolo vengono fornite informazioni per comprendere e analizzare gli errori-1018, 1019 e -1022 del database di Exchange. In questo articolo vengono descritte le differenze tra questi tre errori e i tipi di problemi nel database che causano ciascuno di questi tre errori da segnalare.

Informazioni

Exchange include la funzionalità per rilevare danni a livello di file per le pagine nei relativi database. Di seguito sono elencati i tre errori più comuni sono associati a danni a livello di file a un database di Exchange:
  • JET_errReadVerifyFailure -1018
  • JET_errPageNotInitialized -1019
  • JET_errDiskIO -1022
I seguenti tre livelli di danno possono verificarsi in un database di Exchange:
  • Livello di pagina (file system)
  • Livello del database (database Microsoft Jet)
  • Livello di applicazione (archivio informazioni)
L'utilità Esefile. exe è in grado di rilevare gli errori nei database a livello di pagina. L'utilità Eseutil. exe è in grado di rilevare e correggere i problemi a livello di pagina e il livello del database. L'utilità Isinteg. exe rileva e corregge i problemi a livello di applicazione.

I danni a un basso livello (il livello di pagina) quasi sempre risultati problemi ai livelli più alti (il livello di database o applicazione). Di conseguenza, dopo il ripristino di un database con Eseutil, è quasi sempre necessario utilizzare Isinteg in un secondo momento.

Danni a livello di database e dell'applicazione sono legati a problemi nel codice di Exchange o in programmi di terze parti che si integrano con Exchange. Danni a livello di pagina sono in genere causato da driver, firmware o problemi relativi all'hardware, sebbene danni a livello di pagina potrebbero essere causato anche da problemi di Exchange.

Quasi sempre individuare la causa principale di un errore -1018 in uno dei sistemi sottostanti da cui dipende Exchange, non al codice di Exchange. Esistono pochissime eccezioni a questa regola. Le eccezioni di data sono stati relativamente a Exchange reporting una condizione -1018, non perché Exchange stesso provoca un errore -1018. Per ulteriori informazioni, fare clic sui numeri degli articoli della Microsoft Knowledge Base riportato di seguito:
237953Errore -1018 restituito durante il backup in linea
230215 Checksum di backup non eseguito su computer monoprocessore
Sebbene la maggior parte degli errori-1019 e -1022 sono causati anche da un errore in un sistema sottostante, è possibile escludere la possibilità che gli errori-1019 e -1022 possono verificarsi a causa di un errore di Exchange codice più rapidamente.

Errore -1018 è l'errore più frequenti, che indica che un database di Exchange ha subito un danno a livello di sistema di file. Di conseguenza, la maggior parte di questo articolo riguarda l'errore -1018.

Esistono tre modi fondamentali che potrebbero danneggiare i dati sul disco:
  • Viene scritto il supporto di archiviazione dati non corretti.
  • I dati vengono scritti nella posizione sbagliata sul supporto di archiviazione.
  • I dati vengono danneggiati o modificati dopo l'archiviazione.
Sebbene sia molto difficile prevenire o correggere al 100% di tutti i danni, è relativamente semplice rilevare un problema che si è verificato. Exchange rileva i dati non corretti e spostati nei file dei database e segnala un errore -1018 o -1019. Se un file è gravemente danneggiato o parti di esso mancano completamente oppure sono inaccessibili in caso contrario quando viene effettuato il tentativo di leggere il file, viene generato un errore -1022.

Modalità di calcolo di checksum e pagine di Database di numeri in Exchange

Per comprendere il funzionamento del meccanismo che attiva gli errori-1018 e -1019, è necessario comprendere come le pagine di dati vengono memorizzati in un database di Exchange.

A livello logico più basso è possibile visualizzare un file di database di Exchange come un insieme di pagine di 4 kilobyte (KB), numerati in ordine sequenziale. I dati scritti a una pagina di un database di Exchange alla volta e letti.

Ogni pagina che contiene i dati vengono memorizzati il proprio numero di pagina, insieme a un checksum calcolato da tutti i dati nella pagina. Il valore di checksum è l'unica parte della pagina che non è incluso nel calcolo.

Gli algoritmi di checksum, compresi quelli utilizzati da Exchange, sono trasparenti e relativamente semplici. Sono progettati in modo che la probabilità che due diverse pagine generino lo stesso checksum sono bassi, anche se la differenza tra le pagine di un solo bit.

Sebbene un test di checksum sia sufficiente per determinare o meno la pagina è stata modificata dal momento della creazione, un test di checksum non è sufficiente per assicurarsi che la pagina sia nella posizione corretta. Di conseguenza, Exchange contrassegna ogni pagina con il proprio numero di pagina, nonché un checksum.

Le prime due pagine di 4 KB nel database sono riservate per il database "header". Quando il database è stato arrestato, è possibile utilizzare l'utilità Eseutil /MH opzione per visualizzare l'intestazione. L'intestazione contiene informazioni di identificazione del database nel suo complesso.

Dopo queste prime due pagine di intestazione, tutte le altre pagine del database sono i dati. Tutte le pagine di dati condividono una struttura comune. Ogni pagina contiene un'intestazione, che contiene le informazioni di identificazione su quella pagina, seguita dai dati effettivi.

Poiché la prima pagina di dati in un database di Exchange si trova dopo il prima due pagine di intestazione, pagina fisica 3 nel database è pagina logica 1. 2 è il numero di pagina logica della pagina fisica 4 e così via.

I numeri di pagina logica nel database corrispondono direttamente ai numeri di pagina fisica mediante la seguente formula:
numero di pagina logica = numero di pagina fisica - 2
Poiché le strutture di pagine logiche e fisiche del file di database così strettamente correlate, Exchange può determinare facilmente se ogni pagina logica si trova nella posizione fisica corretta nel file.

Le sole pagine del database per cui non viene calcolato un checksum sono "pagine non inizializzate". Si tratta di blocchi di pagine che vengono create quando le dimensioni del database viene estesa per fare posto ad altri dati. Una pagina non inizializzata è quello che ha un valore di checksum pari a zero e un numero di pagina pari a zero. In genere, ogni byte di una pagina non inizializzata viene inserito con carattere 0x00.

Dopo che una pagina non inizializzata viene utilizzata per la prima volta, non viene restituito lo stato non inizializzato, anche se viene svuotato. Al contrario, la pagina vuota viene impostato un flag per indicare che è disponibile per il riutilizzo. La pagina continuerà ad avere un numero di pagina e il checksum, anche quando è vuoto.

Exchange Server 2003 Service Pack 1 (SP1) modificato l'algoritmo di checksum e il formato di pagina vengono utilizzati. Inoltre, Exchange Server 2003 SP1 Ha introdotto un algoritmo di codice (ECC) per rilevare e correggere automaticamente gli errori bit singolo di correzione degli errori.Per ulteriori informazioni su questa nuova funzionalità, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
867626Nuovo error correcting code è incluso in Exchange Server 2003 Service Pack 1

Qual è la causa un errore -1018

In Exchange viene segnalato un errore -1018 quando una pagina non inizializzata nel file di database si trova in una delle seguenti condizioni:
  • Il checksum memorizzato nella pagina non corrisponde al risultato del ricalcolo eseguito durante la lettura della pagina.
  • Il numero di pagina che si trova nella pagina non corrisponde al numero di pagina nel punto della pagina, data la posizione fisica della pagina nel file di database.
Exchange potrebbe essere incaricato di generare automaticamente un errore -1018 se Exchange viene eseguita una delle seguenti operazioni:
  • Crea una pagina con il checksum errato.
  • Crea una pagina correttamente, ma indica al sistema operativo per scriverla nella posizione errata.
Dopo che un amministratore di sistema viene rilevato un errore -1018, se l'amministratore esegue test diagnostici hardware sul server e questi rilevato alcun problema, l'amministratore potrebbe concludere che Exchange deve essere responsabile del rilascio perché l'hardware superato l'analisi iniziale.

Tuttavia, in casi ulteriori indagini condotte da Microsoft o hardware fornitori problematiche più complesse riconducibili nell'hardware, firmware o driver di periferiche effettivamente responsabili per danneggiare il file di database.

I normali test diagnostici potrebbero non rilevare tutti gli errori temporanei per diversi motivi. Problemi nel software del firmware o driver potrebbero non rientrare le funzionalità dei programmi di diagnostica. Test di diagnostica potrebbero essere in grado di simulare adeguatamente processi lunghi o carichi complessi. Inoltre, l'aggiunta di registrazione diagnostica per il monitoraggio o debug può modificare il sistema per evitare il problema di ripresentarsi.

La semplicità e la stabilità dei meccanismi di Exchange che generano checksum e scrivono pagine nel file di database è un altro motivo per cui la probabilità che la causa principale di un errore -1018 sia un problema di Exchange è bassa. Il checksum e i meccanismi di rilevamento di pagina non corrette sono semplici, affidabili e sono rimasti invariati dal momento che il prima versione di Exchange, ad eccezione delle modifiche di lieve entità per adattarsi alle modifiche di formato di pagina database tra versioni di database.

In altre parole, che viene generato un checksum per una pagina che sta per essere scritti su disco dopo tutti gli altri dati sono stati scritti nella pagina, tra cui la pagina stesso numero. Dopo l'aggiunta del checksum alla pagina, Exchange richiede il sistema operativo Microsoft Windows per la scrittura della pagina su disco utilizzando standard, pubblicati Windows application programming interface (API).

Il valore di checksum è possibile che venga generato correttamente per una pagina, ma quindi la pagina potrebbe essere scritta nella posizione errata sul disco rigido. Ciò può essere causato da un errore di memoria temporanea, ad esempio "inversione di bit". Si supponga, ad esempio, che venga creata una nuova versione della pagina 70. La pagina stessa non si verificano errori, ma la copia del numero di pagina che viene utilizzato dal controller del disco o dal sistema operativo viene alterata casualmente. Questo problema può verificarsi se 70 (numero binario 100110) è stato modificato in 6 (numero binario 000110) da una cella instabile della memoria. Il checksum della pagina sia corretto, ma la posizione della pagina nel database è errata. Exchange segnala un errore -1018 per la pagina quando viene rilevato che il numero di pagina logico non corrisponde la posizione fisica della pagina. Un altro tipo di numerazione delle pagine (causato da Exchange) errore può verificarsi se viene scritto il numero di pagina errato nella pagina stessa. Ma in questo modo, altri errori, non l'errore -1018. Se Exchange scrive 71 nella pagina 70 e quindi non correttamente il checksum della pagina, la pagina viene scritta nella posizione 71 e supera sia i test a numero e il checksum di pagina.

Spesso, un unico errore -1018 riportato in un database di Exchange non implica il database interrompere o provocare altri sintomi oltre la presenza dell'errore -1018. La pagina potrebbe essere in una cartella non utilizzata frequentemente (ad esempio, la posta inviata o eliminato cartelle), o in un allegato che viene raramente aperto o è vuoto.

Anche se un singolo errore -1018 è improbabile che possano provocare perdita di dati estesa, errori -1018 sono comunque motivo di preoccupazione in quanto un errore -1018 costituisce la prova che il sistema di archiviazione non è riuscito ad archiviare o recuperare dati almeno una volta. Anche se l'errore -1018 potrebbe essere un problema temporaneo che non si ripresenterà, è più probabile che questo errore è un preavviso di un problema che potrebbe progressivamente peggiorare. Anche se il primo errore-1018 è una pagina vuota del database, è impossibile conoscere quale pagina potrebbe essere danneggiata successivamente. Se una tabella globale importante è danneggiata, il database potrebbe diventare instabile e riparazione del database potrebbe essere o non riusciti solo in parte.

Una volta che viene registrato un errore -1018, è necessario prendere in considerazione e prevede la possibilità di errore imminente o di un ulteriore danno casuale al database fino a quando non si individua ed elimina la causa principale.

Ripristino in caso di errori -1018

Exchange considera una pagina in cui è associato un errore -1018 considerata completamente illeggibile, per impedire l'azione causali sui dati creino ulteriori problemi nel database.

Una pagina in cui è associato un errore -1018 non può essere ripristinata o recuperata. Sarà necessario eliminarla dal database. Sono disponibili tre metodi che è possibile utilizzare per effettuare questa operazione la pagina dal database:
  • Ripristinare il database da un backup in linea.
  • Utilizzare Eseutil. exe /D switch per effettuare una deframmentazione non in linea del database.
  • Utilizzare Eseutil. exe /P opzione per ripristinare il database.

Ripristinare il Database da un Backup in linea

Se viene rilevato un errore -1018 durante il backup in linea, l'operazione viene interrotta. Ciò garantisce che la pagina danneggiata non esiste dall'ultimo backup completato. Se la registrazione circolare è disattivata, è possibile ripristinare il backup completo più recente disponibile e quindi procedere al rollforward dai registri delle transazioni successivi.

Utilizzare Eseutil. exe "/d" per effettuare una deframmentazione non in linea del Database

Questo metodo è efficacia se viene segnalato l'errore -1018 una pagina vuota. Se l'errore -1018 si verifica solo durante il backup in linea o la manutenzione notturna in linea, indica che la pagina viene utilizzata raramente o che può anche essere vuoto. Deframmentazione non in linea vengono eliminate tutte le pagine vuote e gli indici secondari in un database.

Utilizzare Eseutil. exe "/ P" Switch per ripristinare il Database

Una pagina non valida non può essere risolto se si utilizza questo metodo, ma la pagina non valida viene scartata. Se la pagina in questione è una "pagina foglia", si verifica una perdita di dati. Una pagina foglia nel database è una pagina contenente dati effettivi. Le pagine interne comprendono informazioni solo logiche e strutturali. Nella maggior parte dei casi, Eseutil può ricostruire completamente una tabella se una pagina interna viene persa. Tuttavia, la maggior parte delle pagine in un database sono le pagine foglia.

Works funzionalità di ripristino di Eseutil ben e nella maggior parte dei casi possibile ripristinare un database con perdita di dati minima. Tuttavia, se sono molte pagine danneggiate o sono andate perdute tabelle di sistema critici, la perdita di dati può essere grave o il database potrebbe essere non ripristinabili.

Riparazione di un database è in genere una strategia meno apprezzabile rispetto al ripristino da backup e il rollforward del database perché ripristino in genere richiede più di ripristino ed è anche più rischiosa. Scegliete Ripristina solo se:
  • Non si dispone di una copia di backup.
  • È impossibile rollforward completo dal backup.
Prima di riparare o ripristinare un database, eseguire sempre una copia di backup dei file del database corrente. Se il ripristino non dovesse funzionare, è possibile ripristinare il database esistente. Se la riparazione non dovesse funzionare, ma la copia precedente del database è tuttora avviabile, è possibile salvare i dati che altrimenti andrebbero perdute.

Importante Dopo il ripristino di un database, è necessario controllare il numero delle riparazioni nell'intestazione del database. Se il conteggio è maggiore di zero, è necessario eseguire una deframmentazione non in linea utilizzando Eseutil e quindi è necessario ripristinare il database a livello dell'archivio informazioni con l'utilità Isinteg. Non in questo caso, gli utenti potrebbero rilevare problemi, ad esempio l'impossibilità di aprire messaggi o allegati o i riferimenti nelle cassette postali per gli elementi che non esistono più.

Per controllare il numero delle riparazioni, esaminare l'output generato quando si esegue il comando riportato di seguito:
ESEUTIL /MH [nome_file_database]
Per eseguire una deframmentazione non in linea del database riparato, eseguire il comando riportato di seguito:
ESEUTIL /D [nome_file_database]
Per effettuare una correzione completa con Isinteg dopo il ripristino in Exchange 2000, è necessario eseguire il servizio Archivio informazioni, ma è necessario disinstallare il database che si desidera ripristinare. Eseguire il seguente comando per la correzione del database:
ISINTEG -S [nome_server]-FIX - TEST ALLTESTS
Per eseguire una correzione completa con Isinteg dopo il ripristino di Exchange Server 5. 5, l'archivio informazioni di servizio deve essere arrestato. Eseguire il comando riportato di seguito, utilizzando i (opzione appropriata-PRI o -PUB), a seconda se si sta eseguendo il ripristino su un database privato o pubblico:
ISINTEG-PRI |PUB-FIX - TEST ALLTESTS
Nota È possibile eseguire Eseutil ed Esefile su file di database non elaborato, indipendentemente dal loro file percorsi di sistema. I file di database non sono necessario anche in un server di Exchange. Ma è necessario eseguire Isinteg il database è posto su un server di Exchange completamente configurato perché Isinteg opera a livello dell'archivio informazioni e utilizza il servizio Archivio informazioni di accesso al database.

Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
244525Come eseguire Eseutil su un computer senza Exchange Server

Ripristino da un errore -1019

Quando una pagina che deve essere in uso è inizializzata o è vuota, viene generato un errore -1019 (JET_errPageNotInitialized). Se il campo del numero di pagina in una pagina in uso è 0x00000000, viene generato un errore -1019 anziché un errore -1018, anche se la pagina potrebbe non superare il test di checksum.

I metodi per correggere un errore -1019 sono identiche a quelle per correggere un errore -1018. Si noti che un problema -1019 potrebbe rimanere non rilevato più di un problema -1018 poiché 1019 non vengono rilevati dal backup in linea.

Anche se la causa principale di un errore -1018 è molto probabile che all'esterno di Exchange, un errore -1019 potrebbe essere causato da Exchange se i puntatori logici o i collegamenti tra le pagine non sono validi.

Tuttavia, è più comune che un errore -1019 è causato dal momento che il file system è stato danneggiato o associazione di pagine nel file di database che non appartengono al file.

Ripristino da un errore -1022

Se Exchange richiede al sistema operativo per una pagina nel database e si verifica un errore anziché i dati della pagina restituiti, verrà generato un errore -1022 (JET_errDiskIO). L'errore -1022 è un errore generico che compare ogni volta che un disco di input/output (i/O) problema che impedisce l'accesso a una pagina richiesta nel database di Exchange.

La causa più comune di un errore -1022 è un file di database gravemente danneggiato o troncato. Se si verifica questo problema, Exchange richiede un numero di pagina che è maggiore del numero di pagine nel file di database e un errore -1022. Questo problema può verificarsi a causa di problemi nel file system o a causa di riproduzione del registro delle transazioni non corretta.

Exchange 2000 sono disponibili numerose misure per impedire la riproduzione del registro delle transazioni che potrebbe danneggiare il database, ma in Exchange Server 5. 5 è possibile eseguire un insieme incompleto di file di registro e danneggiare il database. Ad esempio, questo problema può verificarsi se la riproduzione deve iniziare dal file di registro 9, ma viene forzato per l'avvio da file di registro 10. Riproduzione potrebbe essere costretta se un amministratore elimina il file di checkpoint e il file di registro 9. Se una transazione nel file di registro 9 estende la dimensione del database, ma non viene riprodotto il file di registro 9 nel database, un riferimento nel file di registro 10 alle nuove pagine aggiunte al database genera un errore -1022. Improvvisi arresti anomali del sistema, si interrompe (sporgente), e le violazioni di accesso sono sintomatici della riproduzione di un set di log delle transazioni incomplete in un database.

La comprensione e la risoluzione dei problemi della causa principale di un errore -1022 è più complessa rispetto a risolvere i problemi di un errore-1018 o -1019. Se l'errore è causato dal danneggiamento del database nel file system, è necessario verificare o riparare il file system e ripristinare Exchange da una copia di backup. Sebbene il ripristino del database è ancora disponibile, offre meno probabilità di ottenere risultati positivi con gli altri errori, poiché un errore -1022 i danni.

La causa più comune di un errore -1022 con un database non danneggiato di gran lunga un'altra applicazione mantiene i file aperti e impedendo l'archivio informazioni di servizio di accedervi. In tal caso, è possibile visualizzare anche gli errori -1032 (JET_errFileAccessDenied). Riavviare tutti i servizi di Exchange o il server potrebbe risolvere il problema.

Programmi di terze parti, ad esempio programmi antivirus possono bloccare l'accesso a dati di Exchange Exchange. Consente di configurare sempre antivirus a livello di file per escludere i file di dati di Exchange dall'operazione di analisi dei file. Sono disponibili numerose applicazioni antivirus che sfruttano l'antivirus di Exchange application programming interface (API) per analizzare i messaggi e allegati nell'archivio informazioni.

Analisi degli errori-1018 e -1019

Le informazioni contenute in questa sezione sono destinate principalmente di assistenza tecnica e personale del fornitore che sono coinvolti nella directory principale dell'analisi delle cause.

Dopo che un amministratore rileva un errore-1018 o -1019, l'amministratore deve conoscere almeno tre elementi:
  • Che cosa è stato della pagina danneggiata
  • Che cos'è la probabilità di ripristino riuscito
  • Che cosa ha provocato il danno in primo luogo
-gli errori 1018 e -1019 potrebbero verificarsi nella riga di comando quando si avvia il servizio Registro eventi dell'applicazione o l'output dell'utilità di Exchange come Eseutil. Errore -1018 nel registro eventi dell'applicazione potrebbe non essere segnalato quando si esegue un controllo di integrità del database con il Eseutil /G comando. In questo caso, è probabile che la pagina errata sia vuota.

Nella maggior parte dei casi, gli errori vengono segnalati in un form che consente di identificare la pagina che segnala il problema. È inoltre possibile eseguire la scansione dell'intero database con Esefile per identificare le pagine. Per ulteriori informazioni su Esefile, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
248406Utilità di supporto Esefile per Exchange Server 5. 5 ed Exchange 2000
Negli esempi che seguono sono le descrizioni di errori-1018 tipici dal registro eventi dell'applicazione per le diverse versioni di Exchange, unitamente all'analisi dei dettagli per ogni errore.
MSExchangeIS (248) Synchronous read page checksum error -1018
((1:3106 1:3106)(0-310013)(0-312215)) occurred.
Please restore the databases from a previous backup.
					
Nell'esempio precedente, è possibile interpretare i numeri tra parentesi come segue:
  • (3106 3106) rappresenta la pagina del database che è stata richiesta (pagina 3106) e il numero di pagina effettivamente scritto sulla pagina (pagina 3106). 1: Indica che si tratta di database 1, ovvero Priv. edb per Exchange Server 5. 5. Database 2 corrisponde a pub.
  • (0-310013) rappresenta il dbtime valore attualmente scritto sulla pagina. Il dbtime valore è un valore a 64 bit che viene scritto su ciascuna pagina che mette in correlazione più o meno con il tempo trascorso dall'ultima pagina è stata modificata.
  • (0-312215) rappresenta la corrente dbtime valore per il database nel suo complesso: probabilmente il dbtime valore che verrebbe scritto in questa pagina se la pagina è stata alterata in questo momento. Il dbtime valore già nella pagina deve essere sempre minore di corrente dbtime valore.
Dato che il numero di pagina è stato letto correttamente nella pagina e il dbtime i valori sono ragionevoli (con il primo dbtime valore inferiore al secondo), questa pagina non è stata completamente sostituita con una pagina esterna al database o a un'altra pagina.

È possibile utilizzare Esefile per generare la pagina con un comando analogo al seguente:
Esefile /d database.edb 3106 > 3106.txt
Perché questa pagina sembra essere sostanzialmente intatta in materia di struttura, è anche possibile utilizzare Eseutil per visualizzare ulteriori informazioni logiche sulla pagina. È possibile utilizzare la versione di Exchange 2000 di Eseutil per visualizzare le informazioni sulla struttura di pagina da un database di Exchange 2000 ed Exchange Server 5. 5.

Messaggio di avviso Non utilizzare la versione di Exchange 2000 di Eseutil su un database di Exchange Server 5. 5 in qualsiasi modalità che scrive nel database. Per sicurezza, utilizzare solo il /M gli switch e mai utilizzare la /P, /G, o /R. Inoltre, non copiare le versioni di Exchange 2000 di Eseutil. exe ed ESE. dll per un computer Exchange Server 5. 5. Copiare i file in un server remoto e forniscono un percorso UNC (Universal Naming Convention) esplicito riga di comando per il database in esame.

Un comando simile al seguente comando restituisce informazioni logiche di una pagina in un file di testo:
Eseutil /M \\exchange1\d$\exchsrvr\mdbdata\priv.edb /p3106 > 3106.txt

Initiating FILE DUMP mode...
      Database: priv.edb
          Page: 3106

                        pgnoThis <0x02360004,  4>:  3106 (0x00000c22)
                        objidFDP <0x02360018,  4>:  19 (0x00000013)
                ulChecksumParity <0x02360000,  4>:  4269350574 (0xfe791eae)
        ** computed checksum: 157180847 (0x095e63af)
                   dbtimeDirtied <0x02360008,  8>:  310013 (0x000000000004bafd)
                          cbFree <0x0236001c,  2>:  436 (0x01b4)
                       ibMicFree <0x02360020,  2>:  3608 (0x0e18)
                     itagMicFree <0x02360022,  2>:  3 (0x0003)
               cbUncommittedFree <0x0236001e,  2>:  0 (0x0000)
                        pgnoNext <0x02360014,  4>:  3108 (0x00000c24)
                        pgnoPrev <0x02360010,  4>:  3088 (0x00000c10)
                          fFlags <0x02360024,  4>:  2050 (0x00000802)
                Leaf page
                Primary page
Da questo output, è possibile vedere che la pagina è una pagina foglia, vale a dire che contiene dati effettivi. Se si ripristina il database, la riparazione comporterà la perdita di almeno i dati. Per ulteriori informazioni su come individuare la tabella o la cassetta postale a cui appartiene la pagina, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
262196Come determinare quale cassetta postale appartiene una determinata pagina di un database
Se l'output di Eseutil pagina foglia non risulta disponibile per la pagina, la probabilità che il ripristino verrà completamente lavoro sono elevati. Più pagine interne o strutturale possono essere completamente ricostruite dal processo di ripristino.

L'output potrebbe anche essere indicato in questo come una "pagina vuota. In questo caso, una deframmentazione non in linea verrà annullate la pagina errata dal database.

È importante ricordare che se una pagina è stata completamente sostituita da un blocco di dati che non appartengono al file di database, l'output di Eseutil potrebbe risultare insignificante.

Il seguente messaggio di errore è un altro esempio:
MSExchangeIS ((247) ) Synchronous read page checksum error -1018
((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) occurred.
Please restore the databases from a previous backup.
In questo esempio, il numero di pagina effettivamente letto dalla pagina (3688618971) non corrisponde la pagina richiesta, vale a dire che l'area di intestazione di pagina in cui è memorizzato il numero di pagina è danneggiato. È probabile che il numero di pagina non è presente anche nel database. Per determinare se questo è il caso, moltiplicare il numero di pagina per 4096 e confrontare tale valore per la dimensione in byte del file di database. In questo caso, il numero di pagina è improbabile che avevo scritto Exchange, a meno che il database è di 15 terabyte di dimensione (3.688.618.971 x 4096 = 15.108.583.305.216).

Si noti inoltre che il primo dbtime valore ripete esattamente il formato del numero di pagina. Se si converte 3688618971 in esadecimale (utilizzando Calc. exe in modalità scientifica), diventerà 0xDBDBDBDB. In Exchange 2000 ed Exchange Server 5. 5, 8 byte dbtime valore viene memorizzato subito dopo il valore del numero di pagina di 4 byte. Di conseguenza, si è certi che almeno 12 byte contigui per due diversi campi sono stati sovrascritti con uno specifico modello. Se si utilizza Esefile per visualizzare questa pagina viene visualizzata direttamente, si scoprirà probabilmente che l'intera pagina è stato sovrascritto con lo schema 0xDB. Un altro modello di byte non valida di frequente è 0xFF. Se questo era il caso di errore precedente, il dbtime valore risulterebbe 4294967295.

L'errore riportato di seguito vengono fornite informazioni di pagina come un offset di byte nel file, non come un numero di pagina:
Information Store (2160) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 897024 (0x00000000000db000)
for 4096 (0x00001000) bytes failed verification due to a page checksum
mismatch. The expected checksum was 2651583211 (0x9e0bf2eb) and the
actual checksum was 2651582996 (0x9e0bf214). The read operation will
fail with error -1018 (0xfffffc06). If this condition persists then
please restore the database from a previous backup.
					
È possibile convertire il primo offset per il numero di pagina rimuovendo i tre zero finali, sottraendo 1 e convertendo il risultato in decimali. In questo esempio, 0x00000000000db - 1 = 0xda = 218 decimale. È possibile utilizzare questo numero di pagina decimale con Esefile o Eseutil.

Nota Sottrarre solo 1 anziché 2, per tenere in considerazione le due pagine di intestazione del database perché degli offset Inizia conteggio da 0x0 anziché da 0x1. Se si desidera controllare le pagine di intestazione con Esefile o Eseutil, fare riferimento a pagina -1 e 0.

Intestazione di un database di Exchange richiede effettivamente una sola pagina. La seconda è una copia "shadow" dell'intestazione. I valori di checksum indicati quando si utilizza il Esefile /D funzione di immagine della pagina siano sempre lo stesso per le pagine -1 e 0 dopo il database viene chiuso correttamente. Se l'intestazione viene riscritta durante un arresto anomalo del sistema, Exchange utilizza la copia dell'intestazione con un nuovo checksum al riavvio di Exchange.

Riprendendo l'esempio precedente, i valori di checksum sono effettivamente molto ravvicinate, che differiscono solo due caratteri. Quando i valori di checksum sono molto simili, significa che le modifiche nella pagina sono minime: è possibile che un solo errore di bit. È molto probabile che in questa pagina sono comunque sufficienti alla struttura logica per giustificare un'analisi con Eseutil /M /P.

Il checksum previsto nel messaggio di errore è quello effettivamente letto dalla pagina ora esistente nel database. Il checksum effettivo nel messaggio di errore è quello che viene ricalcolato dinamicamente durante la lettura della pagina.

Se il checksum effettivo in una pagina è 0x89abcdef, la pagina contiene tutti caratteri 0x00. Se il checksum effettivo è 0x76543210, la pagina contiene tutti caratteri 0xFF.

Nell'esempio riportato di seguito è un errore -1019:
Information Store (3928) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 1675264 (0x0000000000199000)
for 4096 (0x00001000) bytes failed verification because it contains
no page data.  The read operation will fail with error -1019 (0xfffffc05).
If this condition persists then please restore the database from a
previous backup.
					
Durante un'operazione tipica, se una pagina in grado di segnalare un errore -1019 o un errore -1018, l'errore -1019 ha la precedenza e viene segnalato. È importante ricordare che un errore -1019 si verifica ogni volta che il numero di pagina viene scritto in una pagina è 0x00000000, ma Exchange prevede che la pagina sia in uso. Può essere difficile verificare se un errore -1019 è causato dal momento che il file system mappato a un blocco di zeri nel file di database o perché Exchange commesso un errore e fa riferimento a una pagina non utilizzata come "in uso".

Non è possibile stabilire dall'errore precedente se la pagina non è inizializzata o in un altro stato. È necessario utilizzare Esefile ed Eseutil per un'ulteriore analisi della pagina. In questo esempio, il numero di pagina è 408 decimale (derivato da 0x199).

È possibile utilizzare Eseutil per un'ulteriore analisi della pagina. Il pgnoThis valore deve corrispondere al numero di pagina che viene eseguita una query, e il ulChecksumParity Segnala un ulteriore valore ** checksum calcolato valore se il checksum della pagina è errato. È possibile utilizzare Esefile /D Passare a esaminare la pagina non elaborata per determinare se non è inizializzata (tutti caratteri 0x00).

Falsi errori -1018

Quando la pagina sul disco è corretta, ma il sistema dei / O recupera i dati in modo errato, verrà generato un errore -1018 "false". Tali errori sono solitamente temporanei e difficili da isolare. Ma anche un "falso" errore -1018 merita particolare attenzione. È comunque compromessa l'affidabilità del sistema di archiviazione e il sistema potrebbe essere esposto a ulteriori problemi o errori.

Se si sospettano di errori di letti temporanei del sistema, utilizzare Esefile /D passare o Eseutil /M /P Per verificare le singole pagine coinvolte. Se si utilizza uno dei due utilità per eseguire la scansione dell'intero database, è possibile inserire ceppo nel sistema i/O che si verifichino ulteriori errori falsamente positivi.

Funzionalità per facilitare l'identificazione di errori di letti temporanei aggiuntive di Exchange Server 5. 5 Service Pack 2 (SP2). Pagina viene riletta 16 volte dopo un errore di verifica della lettura. Se la lettura della pagina ha esito positivo dopo diversi tentativi, significa che è un problema di sistema durante la lettura in modo affidabile dal disco. Anche se tutte le operazioni di 16 lettura non riesce, non significa necessariamente che la pagina è errata. Eseguire un test secondario con Esefile o Eseutil.

Azzeramento del database

Azzeramento del database consente di nascondere le informazioni eliminate in un database di Exchange in modo che non possono essere ripristinata o lette mediante un esame diretto del file di database. Per ulteriori informazioni sull'azzeramento del database, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
223161Informazioni sull'azzeramento ESE
Se è attivato l'azzeramento del database, le sezioni di pagine vuote o parzialmente vuote potrebbero essere sovrascritte con particolari schemi di caratteri, ma la pagina non viene ripristinata lo stato non inizializzato.

Proprietà

Identificativo articolo: 314917 - Ultima modifica: martedì 24 maggio 2011 - Revisione: 0.1
Le informazioni in questo articolo si applicano a:
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Chiavi: 
kbinfo kbmt KB314917 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: 314917
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