Κατανόηση και ανάλυση-1018-1019 και-1022 του Exchange σφάλματα της βάσης δεδομένων

Μεταφράσεις άρθρων Μεταφράσεις άρθρων
Αναγν. άρθρου: 314917 - Δείτε τα προϊόντα στα οποία αναφέρεται το συγκεκριμένο άρθρο.
Ανάπτυξη όλων | Σύμπτυξη όλων

Σε αυτήν τη σελίδα

Περίληψη

Αυτό το άρθρο παρέχει πληροφορίες που θα σας βοηθήσουν να κατανοήσετε και να αναλύετε-1018-1019 και-1022 σφάλματα βάσης δεδομένων του Exchange. Αυτό το άρθρο περιγράφει τις διαφορές μεταξύ αυτών των τριών σφάλματα και τους τύπους των θεμάτων στη βάση δεδομένων που οδηγούν στην καθεμία από αυτές τις τρεις σφάλματα θα αναφερθούν.

Περισσότερες πληροφορίες

Exchange περιλαμβάνει τη λειτουργικότητα να εντοπίζει καταστροφή αρχείου επιπέδου σε σελίδες σε βάσεις δεδομένων της. Τα τρία πιο συνηθισμένα σφάλματα που σχετίζονται με την καταστροφή του αρχείου επιπέδου σε μια βάση δεδομένων του Exchange είναι οι εξής:
  • JET_errReadVerifyFailure-1018
  • JET_errPageNotInitialized-1019
  • JET_errDiskIO-1022
Τα ακόλουθα τρία επίπεδα ζημιά μπορεί να προκύψει σε μια βάση δεδομένων του Exchange:
  • Επίπεδο σελίδας (σύστημα αρχείων)
  • Επίπεδο βάσης δεδομένων (ο μηχανισμός βάσης δεδομένων JET)
  • Επίπεδο εφαρμογής (χώρος αποθήκευσης πληροφοριών Exchange)
Το βοηθητικό πρόγραμμα Esefile.exe μπορεί να εντοπίσει σφάλματα στις βάσεις δεδομένων σε επίπεδο σελίδας. Το βοηθητικό πρόγραμμα Eseutil.exe να εντοπίσετε και να επιδιορθώσετε προβλήματα σε επίπεδο σελίδας και το επίπεδο βάσης δεδομένων. Το βοηθητικό πρόγραμμα Isinteg.exe εντοπίζει και επιδιορθώνει προβλήματα σε επίπεδο εφαρμογής.

Καταστροφή του ενός κατώτερου επιπέδου (επίπεδο σελίδας) σχεδόν πάντα αποτελέσματα σε προβλήματα στα υψηλότερα επίπεδα (το επίπεδο βάσης δεδομένων ή εφαρμογής). Επομένως, μετά την επιδιόρθωση μιας βάσης δεδομένων με το Eseutil, σχεδόν πάντα πρέπει να χρησιμοποιήσετε Isinteg αργότερα.

Βλάβη στο επίπεδο της βάσης δεδομένων και εφαρμογή σχετίζεται με θέματα στον κώδικα του Exchange ή σε προγράμματα άλλων κατασκευαστών, τα οποία ενσωματώνουν με το Exchange. Βλάβη σε επίπεδο σελίδας συνήθως προκαλείται από το πρόγραμμα οδήγησης, υλικολογισμικού ή ζητήματα υλικού, παρόλο που η ζημιά στο επίπεδο σελίδας μπορεί επίσης να προκαλείται από προβλήματα στο Exchange.

Βρείτε την κύρια αιτία για ένα σφάλμα-1018 σχεδόν πάντα σε ένα από τα συστήματα βάσης που εξαρτάται από το Exchange, όχι στο Exchange κώδικα στον εαυτό. Υπάρχουν πολύ λίγες εξαιρέσεις σε αυτόν τον κανόνα. Οι εξαιρέσεις σε ημερομηνία έχουν ΑΦΟΡΑ ΑΥΤΕΣ Exchange αναφέρει μια συνθήκη-1018, όχι επειδή Exchange στον εαυτό προκαλεί ένα σφάλμα-1018.Για περισσότερες πληροφορίες, κάντε κλικ στους αριθμούς των άρθρων παρακάτω για να προβάλετε τα άρθρα της Γνωσιακής Βάσης (Knowledge Base) της Microsoft:
237953Εσφαλμένες-1018 σφάλματος που επιστρέφεται κατά την ηλεκτρονική δημιουργία αντιγράφων ασφαλείας
230215Αντιγράφων ασφαλείας checksuming δεν εκτελούνται σε υπολογιστές μονός επεξεργαστής
Παρόλο που η πλειοψηφία των-1019 και-1022 σφάλματα είναι επίσης προκαλείται από ένα σφάλμα σε ένα υποκείμενο σύστημα, δεν είναι δυνατό να εξαλείψετε την πιθανότητα ότι-1019 και-1022 ενδέχεται να παρουσιαστούν σφάλματα εξαιτίας ενός σφάλματος στο Exchange κώδικα ως γρήγορα.

Σφάλμα-1018 είναι το πιο συχνά εμφανίζεται σφάλμα, το οποίο δηλώνει ότι μια βάση δεδομένων του Exchange έχει Παρουσιάστηκε βλάβη στο επίπεδο του συστήματος αρχείων. Επομένως, οι περισσότεροι από αυτό το άρθρο εστιάζεται στην σφάλμα-1018.

Υπάρχουν τρία θεμελιώδη τρόπους να καταστραφούν δεδομένα στο δίσκο:
  • Εσφαλμένα δεδομένα εγγράφονται στο μέσο αποθήκευσης.
  • Δεδομένα γράφονται στη λάθος θέση στο μέσο αποθήκευσης.
  • Δεδομένα είναι κατεστραμμένα ή να αλλάξει μετά την αποθήκευση.
Αν και είναι πολύ δύσκολο να αποτρέψετε ή να διορθώσετε το 100 τοις εκατό των όλες τις ζημιές, είναι σχετικά εύκολη να εντοπίσει ένα πρόβλημα που παρουσιάστηκε. Exchange εντοπίζει εσφαλμένα και σε λανθασμένη θέση δεδομένων με τα αρχεία της βάσης δεδομένων και αναφέρει ένα σφάλμα-1018 ή σφάλμα-1019. Εάν ένα αρχείο είναι κατεστραμμένο σας επηρεάζει και τμήματα του λείπουν εντελώς ή είναι μη προσβάσιμο, αλλιώς όταν Exchange προσπαθεί να διαβάσει το αρχείο, είναι ανέφερε ένα σφάλμα-1022.

Πώς Exchange υπολογίζει αθροισμάτων ελέγχου και των δεδομένων αριθμών σελίδων

Για να κατανοήσετε τον τρόπο λειτουργίας των μηχανισμών που προκαλούν σφάλματα-1018 και-1019, πρέπει να κατανοήσετε τον τρόπο αποθήκευσης σελίδες δεδομένων από μια βάση δεδομένων του Exchange.

Στο κατώτατο λογικό επίπεδο, μπορείτε να προβάλετε ένα αρχείο βάσης δεδομένων του Exchange ως ένα σύνολο 4 kilobyte (KB) σελίδων, αριθμούνται με διαδοχική σειρά. Δεδομένα διαβάζονται και εγγράφονται σε μια βάση δεδομένων Exchange κατά μία σελίδα τη φορά.

Each page that contains data stores its own page number, along with a checksum that is calculated from all of the data on the page. The checksum value itself is the only part of the page that is not included in this calculation.

Checksum algorithms, including the checksum algorithm that Exchange uses, are well understood and relatively simple. They are designed so that chances that the same checksum will result for any two different pages are low, even if the difference between the pages is only a single bit.

Although a checksum test is sufficient to determine whether or not the page has been altered since it was written, a checksum test is not enough to make sure that the page is in the right place. Because of this, Exchange stamps each page with its own page number as well as a checksum.

The first two 4-KB pages in the database are reserved for the database "header." When the database is stopped, you can use the Eseutil utility's/MHswitch to view this header. The header contains identifying information about the database as a whole.

After these first two header pages, all of the other pages in the database are data. The data pages all share a common structure. Each page has its own page header, which contains identifying information about the particular page, followed by actual data.

Because the first data page in an Exchange database is located after the first two header pages, physical page 3 in the database is logical page 1. 2 is the logical page number of physical page 4, and so on.

Logical page numbers in the database map directly to physical page numbers by the following formula:
logical page number = physical page number - 2
Because the logical and physical page structures of the database file are so closely related, Exchange can easily determine whether each logical page is in the correct physical location in the file.

The only pages in the database for which a checksum is not calculated are "uninitialized pages." These are blocks of pages that are created when the database size is extended to make room for more data. An uninitialized page is one that has a zero checksum and a zero page number. Typically, every byte of an uninitialized page is filled with character0x00, but this may not be true for databases that have been upgraded from Exchange Server 4.0 or Exchange Server 5.0.

After an uninitialized page is used for the first time, it does not return to the uninitialized state, even if it is emptied. Instead, a flag is set on the emptied page to mark it available for re-use. The page still carries a page number and checksum, even when it is empty.

Exchange Server 2003 Service Pack 1 (SP1) changed the checksum algorithm and the page format that are used. Also, Exchange Server 2003 SP1 introduced an error correcting code (ECC) algorithm to detect and to automatically correct single-bit errors.For more information about this new functionality, click the following article number to view the article in the Microsoft Knowledge Base:
867626New error correcting code is included in Exchange Server 2003 Service Pack 1

What Causes a -1018 Error

Exchange reports a -1018 error when an initialized page in the database file is found with either of the following conditions:
  • The checksum that is stored on the page does not match the result of the checksum recalculation that is performed as the page is read.
  • The page number that is stored on the page does not match the page number that should be on the page, given the page's physical location in the database file.
Exchange might be responsible for self-generating a -1018 error if Exchange does one of the following:
  • Constructs a page that has the wrong checksum.
  • Constructs a page correctly, but tells the operating system to write the page in the wrong location.
After a system administrator encounters a -1018 error, if the administrator runs diagnostic hardware tests against the server and these tests report no issues, the administrator might conclude that Exchange must be responsible for the issue because the hardware passed the initial analysis.

However, in case after case, further investigation by Microsoft or hardware vendors uncovered subtle issues in hardware, firmware, or device drivers that are actually responsible for damaging the database file.

Ordinary diagnostic tests might not detect all of the transient faults for several reasons. Issues in firmware or driver software might fall outside the capabilities of diagnostic programs. Diagnostic tests might be unable to adequately simulate long run times or complex loads. Also, the addition of diagnostic monitoring or debug logging might change the system enough to prevent the issue from appearing again.

The simplicity and stability of the Exchange mechanisms that generate checksums and write pages to the database file is another reason that the probability that the root cause for a -1018 error is an Exchange issue is low. The checksum and incorrect page detection mechanisms are simple, reliable and have remained fundamentally the same since the first Exchange release, except for minor changes to adapt to database page format changes between database versions.

Για να εξηγήσετε περαιτέρω, δημιουργείται ένα άθροισμα ελέγχου για μια σελίδα που πρόκειται να εγγραφούν στο δίσκο αφού όλα τα δεδομένα έχει εγγραφεί στη σελίδα, συμπεριλαμβανομένης της σελίδας αριθμό τον εαυτό. Αφού Exchange προσθέτει το άθροισμα ελέγχου στη σελίδα, το Exchange καθοδηγεί το λειτουργικό σύστημα των Microsoft Windows για να γράψετε τη σελίδα στο δίσκο χρησιμοποιώντας το τυπικό, δημοσιευμένο Windows διασυνδέσεις προγραμματισμού εφαρμογών (API).

Το άθροισμα ελέγχου ενδέχεται να δημιουργηθούν σωστά για μια σελίδα, αλλά στη συνέχεια στη σελίδα μπορεί να εγγραφεί στη λάθος θέση στον σκληρό δίσκο. Αυτό μπορεί να οφείλεται σε σφάλμα μνήμης παροδικά, όπως "αναστροφή bit". Για παράδειγμα, ας υποθέσουμε ότι Exchange δημιουργεί μια νέα έκδοση της σελίδας 70. Η ίδια η σελίδα δεν παρουσιαστεί σφάλμα, αλλά τυχαία θα αλλάξει το αντίγραφο του αριθμού σελίδας που χρησιμοποιείται από τον ελεγκτή δίσκου ή από το λειτουργικό σύστημα. Αυτό το ζήτημα ενδέχεται να προκύψει εάν 70 (δυαδική 100110) έχει αλλάξει σε 6 (δυαδική 000110) από ένα κελί αστάθεια μνήμης. Άθροισμα ελέγχου στη σελίδα εξακολουθεί να είναι σωστή, αλλά τώρα είναι λάθος στη θέση της σελίδας στη βάση δεδομένων. Exchange αναφέρει ένα σφάλμα-1018 για τη σελίδα όταν εντοπίσουν ότι ο αριθμός λογική σελίδα δεν ταιριάζει με τη φυσική θέση της σελίδας. Ένα άλλο είδος σελίδων σφαλμάτων (οφείλεται σε Exchange) μπορεί να προκύψει, εάν Exchange εγγράφει τον αριθμό σελίδας λάθος στην ίδια σελίδα. Ωστόσο, αυτό προκαλεί άλλα σφάλματα, δεν το σφάλμα-1018. Εάν γράφει 71 στη σελίδα 70 Exchange και, στη συνέχεια, κάνει σωστά το άθροισμα ελέγχου στη σελίδα, η σελίδα είναι γραμμένο σε θέση 71 και περνά τόσο τη σελίδα αριθμό και το άθροισμα ελέγχου δοκιμές.

Συχνά, ένα μεμονωμένο σφάλμα-1018 που αναφέρεται στη βάση δεδομένων του Exchange δεν προκαλεί τη βάση δεδομένων για να διακόψετε ή να έχει ως αποτέλεσμα ένα σύμπτωμα εκτός από την παρουσία του σφάλματος-1018 τον εαυτό. Στη σελίδα μπορεί να βρίσκεται σε ένα φάκελο που είναι προσπελάσιμα σπάνια (για παράδειγμα, τα απεσταλμένα ή Διαγραμμένα φακέλους), ή σε ένα συνημμένο που σπάνια είναι ανοικτό ή ακόμα και το κενό.

Παρόλο που ένα μεμονωμένο σφάλμα-1018 είναι πιθανό να προκαλέσει απώλεια δεδομένων εκτενείς,-1018 σφάλματα είναι ακόμη αιτία για σας ενδιαφέρει επειδή ένα σφάλμα-1018 απόδειξης ότι το σύστημα αποθήκευσης απέτυχε αξιόπιστα να αποθηκεύσετε ή να ανακτήσετε δεδομένα τουλάχιστον μία φορά. Παρόλο που το σφάλμα-1018 μπορεί να είναι μια μεταβατική ζήτημα που ποτέ δεν θα παρουσιαστεί ξανά, είναι πιο πιθανό ότι αυτό το σφάλμα είναι μια πρώτη προειδοποίηση ένα θέμα το οποίο θα γίνει προοδευτικά worse. Ακόμη και αν είναι το σφάλμα-1018 πρώτα σε μια κενή σελίδα στη βάση δεδομένων, δεν είναι δυνατό να γνωρίζετε ποια σελίδα μπορεί να έχει καταστραφεί στη συνέχεια. Εάν μια κρίσιμη καθολικό πίνακα είναι κατεστραμμένο, η βάση δεδομένων μπορεί να γίνει unstartable και Επισκευή βάσης δεδομένων ενδέχεται να αποτύχει ή μόνο μερικώς επιτυχής.

Αφού καταγράφεται ένα σφάλμα-1018, πρέπει να λάβετε υπόψη σας και Σχεδιασμός για την πιθανότητα αποτυχίας επίκειται ή περαιτέρω τυχαία καταστροφή της βάσης δεδομένων, μέχρι να βρείτε και να εξαλειφθεί η αρχική αιτία.

Ανάκτηση από σφάλματα-1018

Exchange χειρίζεται μια σελίδα η οποία αποτυγχάνει με σφάλμα-1018 ως τελείως δυσανάγνωστα για να αποτρέψετε την ενέργεια σε τυχαία δεδομένα προκαλεί περαιτέρω προβλήματα στη βάση δεδομένων.

Δεν είναι δυνατό να επιδιορθωθεί ή να salvaged μια σελίδα η οποία αποτυγχάνει με σφάλμα-1018. Πρέπει να είναι expunged από τη βάση δεδομένων. Υπάρχουν τρεις μέθοδοι που μπορείτε να χρησιμοποιήσετε για να expunge τη σελίδα από τη βάση δεδομένων:
  • Επαναφέρετε τη βάση δεδομένων από ένα ηλεκτρονικό αντίγραφο ασφαλείας.
  • Χρησιμοποιήστε το Eseutil.exe/Dο διακόπτης για να εκτελέσετε ανασυγκρότηση εκτός σύνδεσης της βάσης δεδομένων.
  • Χρησιμοποιήστε το Eseutil.exe/Pο διακόπτης για να επιδιορθώσετε τη βάση δεδομένων.

Για να επαναφέρετε τη βάση δεδομένων από μια ηλεκτρονική δημιουργία αντιγράφων ασφαλείας

If a -1018 error is found during online backup, the backup stops. This ensures that the damaged page does not exist in the last successful backup. If circular logging is disabled, you can restore the most recent available full backup, and then roll the database forward from the succeeding transaction logs.

Use the Eseutil.exe "/D" Switch to Do an Offline Defragmentation of the Database

This method is effective if the -1018 error is reported on an empty page. If the -1018 error occurs only during online backup or nightly online maintenance, this indicates that the page is seldom accessed or that it may even be empty. Offline defragmentation discards all empty pages and secondary indexes in a database.

Use the Eseutil.exe "/P" Switch to Repair the Database

A bad page is not repaired if you use this method, but the bad page is discarded. If the page that is involved is a "leaf page," some data loss occurs. A leaf page in the database is a page that carries actual data. Interior pages carry only structural and logical information. In most cases, Eseutil can completely reconstruct a table if an interior page is lost. However, the majority of pages in a database are leaf pages.

Eseutil's repair functionality works well, and in most cases can restore a database to operation with minimal data loss. However, if many pages are damaged, or critical system tables are lost, the data loss may be catastrophic or the database may be unrepairable.

Repairing a database is usually an inferior strategy compared to restoring from a backup and rolling the database forward because repair usually takes longer than restoration and is riskier. Choose repair only if:
  • You do not have a backup.
  • You cannot roll forward completely from your backup.
Before you repair or restore a database, always make a backup copy of the current database files. If restoration does not work, you can repair the existing database. If repair does not work, but the previous copy of the database is still startable, you might be able to salvage data that would otherwise be lost.

ΣημαντικόAfter you repair a database, you must check the repair count in the database header. If the count is greater than zero, you must perform an off-line defragmentation by using Eseutil, and then you must repair the database at the information store level with the Isinteg utility. If you do not do so, users may encounter issues, such as an inability to open messages or attachments, or references in their mailboxes to items that no longer exist.

To check the repair count, examine the screen output that is generated when you run the following command:
ESEUTIL /MH [database_file_name]
To perform an offline defragmentation of the repaired database, run the following command:
ESEUTIL /D [database_file_name]
To do a comprehensive Isinteg fix after a repair in Exchange 2000, the Information Store service must be running, but the database that you want to repair must be dismounted. Run the following command for the database fix:
ISINTEG -S [Όνομα_Διακομιστή] -FIX -TEST ALLTESTS
To do a comprehensive Isinteg fix after a repair in Exchange Server 5.5, the Information Store service must be stopped. Run the following command, using the appropriate switch (-PRIή-PUB), depending on whether you are running repair against a private or public database:
ISINTEG -PRI|PUB -FIX -TEST ALLTESTS
ΣΗΜΕΙΩΣΗYou can run Eseutil and Esefile against raw database files regardless of their file system locations. The database files do not even need to be on an Exchange server. But you must run Isinteg while the database is in place on a fully configured Exchange server because Isinteg operates at the information store level and uses the Information Store service to access the database.

Για περισσότερες πληροφορίες, κάντε κλικ στον αριθμό του άρθρου παρακάτω, για να προβάλετε το άρθρο της Γνωσιακής Βάσης της Microsoft (Knowledge Base):
244525Τρόπος εκτέλεσης του Eseutil σε έναν υπολογιστή χωρίς Exchange Server

Recovering from a -1019 Error

A -1019 error (JET_errPageNotInitialized) is reported when a page that is expected to be in use is uninitialized or empty. If the page number field on a page in use is 0x00000000, a -1019 error is reported instead of a -1018 error, even though the page might also fail its checksum test.

The methods to correct a -1019 error are the same as those to correct a -1018 error. Note that a -1019 issue may go undetected longer than a -1018 issue because -1019 issues are not detected by online backup.

Although the root cause of a -1018 error is very likely to be outside of Exchange, a -1019 error might be caused by Exchange if logical pointers or links between pages are invalid.

However, it is more common that a -1019 error is caused because the file system was corrupted or mapped pages into the database file that do not belong in the file.

Recovering from a -1022 Error

If Exchange asks the operating system for a page in the database, and an error occurs instead of the page data being returned, a -1022 error (JET_errDiskIO) results. The -1022 error is a generic error that appears whenever a disk input/output (I/O) problem prevents Exchange from gaining access to a requested page in the database.

The most common reason for a -1022 error is a database file that was severely damaged or truncated. If this issue occurs, Exchange requests a page number that is larger than the number of pages in the database file, and a -1022 error results. This issue can occur because of issues in the file system or because of improper transaction log replay.

Exchange 2000 περιέχει εκτεταμένες δυνατότητες ασφαλείας για να αποτρέψετε την επανάληψη καταγραφής συναλλαγών που μπορεί να βλάψει τη βάση δεδομένων, αλλά στον Exchange Server 5.5 ήταν δυνατό να αναπαραγάγετε μια ατελής σύνολο των αρχείων καταγραφής και την καταστροφή της βάσης δεδομένων. Για παράδειγμα, αυτό το ζήτημα μπορεί να προκύψει, εάν επανάληψης θα πρέπει να ξεκινήσει από το αρχείο καταγραφής 9, αλλά αντίθετα επανάληψης αναγκάζεται να ξεκινήσετε από το αρχείο καταγραφής 10. Επανάληψης μπορεί να είναι υποχρεωτική εάν ο διαχειριστής διαγράφει το αρχείο σημείου ελέγχου και καταγραφής 9. Εάν μια συναλλαγή στο αρχείο καταγραφής 9 επεκτείνει το μέγεθος της βάσης δεδομένων, αλλά καταγραφής 9 δεν αναπαράγεται στη βάση δεδομένων, μια αναφορά στο αρχείο καταγραφής 10 για τις νέες σελίδες που προστίθενται στις βάσεις δεδομένων προκαλεί σφάλμα-1022. Sudden διακόπτεται, οι διακοπές (κλείσιμο), και οι παραβιάσεις πρόσβασης είναι επίσης κοινά συμπτώματα replaying μια ατελής συναλλαγή συνόλου καταγραφής σε μια βάση δεδομένων.

Κατανόηση και αντιμετώπιση προβλημάτων με την αρχική αιτία ενός σφάλματος-1022 είναι πιο περίπλοκη από την αντιμετώπιση προβλημάτων για ένα σφάλμα-1018 ή-1019. Εάν το σφάλμα προκαλείται από καταστροφή της βάσης δεδομένων του συστήματος αρχείων, πρέπει να επαληθεύσετε ή επιδιόρθωση του συστήματος αρχείων και, στη συνέχεια, επαναφέρετε το Exchange από ένα αντίγραφο ασφαλείας. Παρόλο που η επιδιόρθωση της βάσης δεδομένων εξακολουθεί να είναι διαθέσιμη, επιδιόρθωσης είναι λιγότερο πιθανό να είναι επιτυχής από με τα σφάλματα, επειδή ένα σφάλμα-1022 σήματα συχνά εκτεταμένες βλάβες.

Με μεγάλη διαφορά το συνηθέστερη αιτία για ένα σφάλμα-1022 με βάση μη κατεστραμμένο κάποια άλλη εφαρμογή έχει ανοικτά αρχεία και εμποδίζει την αποθήκευση πληροφοριών υπηρεσίας από την πρόσβαση σε αυτά. Σε τέτοιες περιπτώσεις, μπορεί επίσης να δείτε σφάλματα-1032 (JET_errFileAccessDenied). Επανεκκίνηση όλων των υπηρεσιών Exchange ή να επανεκκινήσετε το διακομιστή μπορεί να καταργήσει το κλείδωμα.

Προγράμματα άλλων κατασκευαστών, όπως ιών, ενδέχεται να αποκλείει την πρόσβαση του Exchange σε δεδομένα του Exchange. Πάντα ρύθμισης παραμέτρων σε επίπεδο αρχείου ιών για να εξαιρέσετε αρχεία δεδομένων του Exchange από το αρχείο ανίχνευσης της λειτουργίας. Υπάρχουν αρκετές ιών που εκμεταλλεύονται το Exchange ιών διασύνδεση προγραμματισμού εφαρμογών (API) για να ανιχνεύει μηνύματα και συνημμένα στο χώρο αποθήκευσης πληροφοριών.

Ανάλυση-1018 και-1019 σφάλματα

Οι πληροφορίες σε αυτήν την ενότητα προορίζεται κυρίως για τεχνική υποστήριξη και ανάλυσης έχει ως αποτέλεσμα το προσωπικό του προμηθευτή που είναι που εμπλέκονται στη ρίζα.

Αφού ο διαχειριστής εντοπίσει ένα σφάλμα-1018 ή-1019, ο διαχειριστής πρέπει να γνωρίζει τουλάχιστον τρία πράγματα:
  • Τι έγινε στην κατεστραμμένη σελίδα
  • Τι είναι η πιθανότητα επιτυχούς επιδιόρθωσης
  • Τι προκάλεσε την καταστροφή αρχικά
-1018 και-1019 σφάλματα ενδέχεται να εμφανίζονται στη γραμμή εντολών, κατά την εκκίνηση της υπηρεσίας, στο αρχείο καταγραφής συμβάντων εφαρμογής ή στην έξοδο του Exchange βοηθητικά προγράμματα όπως το Eseutil. Δεν μπορεί να αναφέρεται ένα σφάλμα-1018 στο αρχείο καταγραφής συμβάντων εφαρμογών όταν εκτελείται ο έλεγχος ακεραιότητας μιας βάσης δεδομένων με τηνΤο Eseutil /GΕντολή. Σε αυτήν την περίπτωση, είναι πιθανό ότι η εσφαλμένη σελίδα είναι κενή.

Στις περισσότερες περιπτώσεις, αναφέρονται τα σφάλματα σε μια φόρμα που επιτρέπει την αναγνώριση της σελίδας που αναφέρει το ζήτημα. Επίσης, μπορείτε να σαρώσετε ολόκληρη τη βάση δεδομένων με Esefile για τον εντοπισμό κατεστραμμένων σελίδες.Για περισσότερες πληροφορίες σχετικά με την Esefile, κάντε κλικ στον αριθμό του άρθρου παρακάτω για να προβάλετε το άρθρο της Γνωσιακής Βάσης της Microsoft:
248406Βοηθητικό πρόγραμμα υποστήριξης Esefile για τον Exchange Server 5.5 και Exchange 2000
Τα παρακάτω παραδείγματα είναι το τυπικό σφάλμα-1018 περιγραφές από το αρχείο καταγραφής συμβάντων εφαρμογής για διάφορες εκδόσεις του Exchange, καθώς και των λεπτομερειών σε κάθε σφάλμα ανάλυσης.
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.
					
In the preceding example, you can interpret the numbers in parentheses as follows:
  • (1:3106 1:3106) represents the page in the database that was requested (page 3106), and the page number that was actually found written on the page (page 3106). The 1: indicates that this is database 1, which is Priv.edb for Exchange Server 5.5. Database 2 is Pub.edb.
  • (0-310013) represents thedbtimevalue that is currently written on the page. Για ναdbtimevalue is a 64-bit value that is written on each page that roughly correlates with how long it has been since the page was altered.
  • (0-312215) represents the currentdbtimevalue for the database as a whole: likely thedbtimevalue that would be written on this page if the page was altered now. Για ναdbtimevalue already on the page should always be smaller than the currentdbtimeΤιμή.
Given that the page number was read correctly from the page, and thedbtimevalues are reasonable (with the firstdbtimevalue lower than the second), this page was not entirely replaced with a page from outside the database or a different page.

You can use Esefile to output the page itself with a command similar to the following:
Esefile /d database.edb 3106 > 3106.txt
Because this page appears to be substantially intact with regard to structure, you might also be able to use Eseutil to view more logical information about the page. You can use the Exchange 2000 version of Eseutil to view page structure information from both Exchange 2000 and Exchange Server 5.5 databases.

ΠΡΟΣΟΧΗDo not use the Exchange 2000 version of Eseutil against an Exchange Server 5.5 database in any mode that writes to the database. To be safe, use only the/Mswitches, and never use the/P,/G, ή/R. Also, do not copy Exchange 2000 versions of Eseutil.exe and Ese.dll to an Exchange Server 5.5 computer. Instead, copy these files to a remote server and provide an explicit command line Universal Naming Convention (UNC) path to the database that you are examining.

A command similar to the following command outputs logical information for a page to a text file:
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
From this output, you can see that the page is a leaf page, which means that it has actual data on it. If you repair this database, the repair will result in the loss of at least this data.For more information about how to find out which table or mailbox the page belongs to, click the following article number to view the article in the Microsoft Knowledge Base:
262196How to determine which mailbox owns a particular page in a database
If the Eseutil output does not list Leaf page for the page, chances that repair will work completely are high. Most interior or structural pages can be completely reconstructed by the repair process.

The output might also show this as an "Empty Page." In this case, an offline defragmentation will discard the bad page from the database.

Remember that if a page has been completely replaced by a block of data that does not belong in the database file, the Eseutil output may be meaningless.

The following error is another example:
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 this example, the page number that is actually read from the page (3688618971) does not match the page that was requested, which means that the page header area where the page number is stored is damaged. It is probable that the page number does not even exist in the database. To determine whether this is the case, multiply the page number by 4,096, and then compare that number to the byte size of the database file. In this case, the page number is unlikely to be one that Exchange originally wrote, unless the database is 15 terabytes in size (3,688,618,971 x 4,096 = 15,108,583,305,216).

Also notice that the firstdbtimevalue repeats the page number pattern exactly. If you convert 3688618971 to hexadecimal (use Calc.exe in its Scientific mode), it becomes 0xDBDBDBDB. In Exchange 2000 and Exchange Server 5.5, the 8-bytedbtimevalue is stored immediately after the 4-byte page number value. Because of this, you know that at least twelve contiguous bytes for two different fields were overwritten with a specific pattern. If you use Esefile to look at this page directly, you will probably discover that the entire page was overwritten with the pattern 0xDB. Another frequently seen invalid byte pattern is 0xFF. If this was the case for the error above, thedbtimevalue would be 4294967295.

The following error provides page information as a byte offset into the file, not as a page number:
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.
					
You can convert the first offset to the page number by removing the three trailing zeroes, subtracting 1 and converting the result to decimal. In this example, 0x00000000000db - 1 = 0xda = 218 decimal. You can use this decimal page number with Esefile or Eseutil.

ΣΗΜΕΙΩΣΗYou subtract only 1, instead of 2, to account for the two header pages in the database because offsets begin counting at 0x0 instead of 0x1. If you want to check the header pages with Esefile or Eseutil, reference page -1 and page 0.

An Exchange database header actually requires only a single page. The second page is a "shadow" copy of the header. The checksums that are reported when you use theEsefile /Dpage dump function should always be the same for pages -1 and 0 after the database is shut down cleanly. If the header is rewritten during a crash, Exchange uses the header copy with a clean checksum when Exchange restarts.

Συνεχίζοντας με το προηγούμενο παράδειγμα, τα αθροίσματα ελέγχου του είναι πραγματικά πολύ κοντά μεταξύ τους, διαφορετικό μόνο δύο χαρακτήρες. When checksums are close, this indicates that the changes on the page were minimal: perhaps only a single bit error. It is very likely that this page still contains enough of its logical structure to make it worth analyzing withEseutil /M /P.

The expected checksum in the error message is the checksum that is actually read from the page as it exists now in the database. The actual checksum in the error message is the checksum that Exchange dynamically re-calculates as it reads the page.

If the actual checksum on a page is 0x89abcdef, the page contains all 0x00 characters. If the actual checksum is 0x76543210, the page contains all 0xFF characters.

The following example is a -1019 error:
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.
					
During typical operation, if a page can report either a -1019 error or a -1018 error, the -1019 error takes precedence and is reported. Remember that a -1019 error occurs whenever the page number that is written on a page is 0x00000000, but Exchange expects the page to be in use. It can be difficult to prove whether a -1019 error is caused because the file system mapped a block of zeroes into the database file, or because Exchange made a mistake and referenced an unused page as "in use."

You cannot tell from the preceding error whether the page is uninitialized or in some other state. You must use Esefile and Eseutil to further examine the page. In this example, the page number is 408 decimal (derived from 0x199).

You can use Eseutil to further examine the page. Για ναpgnoThisvalue should match the page number that is queried, and theulChecksumParityvalue reports an additional** computed checksumvalue if the checksum on the page is wrong. You can use the Esefile/Dswitch to look at the raw page to determine whether it is uninitialized (all 0x00 characters).

False -1018 Errors

A "false" -1018 error occurs when the page on disk is correct, but the I/O system retrieves the data incorrectly. Such errors are usually transient and difficult to isolate. But even a "false" -1018 error deserves serious attention. The reliability of the storage system is still compromised, and the system might be in danger of additional issues or failure.

If you suspect transient read errors in your system, use the Esefile/Dswitch orEseutil /M /Pto verify the individual pages that are involved. If you use either utility to scan the entire database, you put strain on the I/O system that might result in more false positives.

Exchange Server 5.5 Service Pack 2 (SP2) added functionality to help identify transient read errors. Exchange re-reads a page 16 times after a read verification failure. If the page read eventually succeeds after several tries, it indicates that there is a system issue in reading reliably from the disk. Even if all 16 reads fail, it does not conclusively prove that the page is bad. Perform a secondary test with Esefile or Eseutil.

Database Zeroing

Database zeroing is intended to obscure deleted information in an Exchange database so that it cannot be recovered or read by direct examination of the database file.For more information about database zeroing, click the following article number to view the article in the Microsoft Knowledge Base:
223161Information on ESE zeroing
If database zeroing is enabled, sections of empty or partially empty pages might be overwritten with specific character patterns, but the page is still not returned to the uninitialized state.

Ιδιότητες

Αναγν. άρθρου: 314917 - Τελευταία αναθεώρηση: Τρίτη, 21 Δεκεμβρίου 2010 - Αναθεώρηση: 2.0
Οι πληροφορίες σε αυτό το άρθρο ισχύουν για:
  • 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
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 4.0 Standard Edition
Λέξεις-κλειδιά: 
kbinfo kbmt KB314917 KbMtel
Μηχανικά μεταφρασμένο
ΣΗΜΑΝΤΙΚΟ: Αυτό το άρθρο είναι προϊόν λογισμικού μηχανικής μετάφρασης της Microsoft και όχι ανθρώπινης μετάφρασης. Η Microsoft σάς προσφέρει άρθρα που είναι προϊόντα ανθρώπινης αλλά και μηχανικής μετάφρασης έτσι ώστε να έχετε πρόσβαση σε όλα τα άρθρα της Γνωσιακής Βάσης μας στη δική σας γλώσσα. Ωστόσο, ένα άρθρο που έχει προκύψει από μηχανική μετάφραση δεν είναι πάντα άριστης ποιότητας. Ενδέχεται να περιέχει λεξιλογικά, συντακτικά ή γραμματικά λάθη, όπως ακριβώς τα λάθη που θα έκανε ένας μη φυσικός ομιλητής επιχειρώντας να μιλήσει τη γλώσσα σας. Η Microsoft δεν φέρει καμία ευθύνη για τυχόν ανακρίβειες, σφάλματα ή ζημίες που προκύψουν λόγω τυχόν παρερμηνειών στη μετάφραση του περιεχομένου ή χρήσης του από τους πελάτες της. Επίσης, η Microsoft πραγματοποιεί συχνά ενημερώσεις στο λογισμικό μηχανικής μετάφρασης.
Η αγγλική έκδοση αυτού του άρθρου είναι η ακόλουθη:314917

Αποστολή σχολίων

 

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