Übersicht über Exchange Server-Datenbankarchitektur und Datenbank-Engine

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 271987 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Dieser Artikel enthält eine allgemeine Übersicht über die Datenbankarchitektur und Datenbank-Engine für Microsoft Exchange Server. Die Diskussion enthält Informationen zu den Datenbankkomponenten, Wartung der Konsistenz der Datenbank, möglichen Typen von Datenbankfehler und Datenbank-Dienstprogramme.

Weitere Informationen

Exchange Server verwendet fehlertolerante, transaktionsbasierte Datenbanken, um Nachrichten und Verzeichnisinformationen zu speichern, bevor Sie auf die Datenbank angewendet wird. Für Exchange Server 5.5 Standard Edition kann jeder Datenbank auf ein Maximum von 16 Gigabyte (GB) zunehmen. Für Exchange Server 5.5 Enterprise Edition ist die Größe nur durch Hardware begrenzt.

Wenn ein Stromausfall oder anderen ungewöhnlichen Systemfehler auftritt, nutzt Exchange Server Transaktionsprotokolldateien, um Daten zu rekonstruieren, die bereits vom Server akzeptiert, jedoch noch nicht in die Datenbank geschrieben.

Datenbankkomponenten

Der Entwurf von Exchange Server basiert auf den standard-Datenbanktechnologie. Das System stützt sich auf ein eingebettetes Datenbankmodul, das die Struktur von der Festplatte für Exchange Server angelegt und verwaltet Speicher. Die Datenbank-Engine-Technologie wird auch von anderen Windows-Anwendungen, z. B. WINS (Windows Internet Name Service) und DHCP-hinter den Kulissen verwendet.

Informationsspeicher

Der Informationsspeicher, die wichtige Komponente für die Datenbankverwaltung in Exchange Server ist ist eigentlich zwei separate Datenbanken. Die private Informationsspeicher-Datenbank "Priv.edb", verwaltet die Daten in Benutzerpostfächern. Der öffentlichen Informationsspeicher pub.EDB, verwaltet die Daten in Öffentlichen Ordnern.

Der Informationsspeicher arbeitet mit MAPI (Messaging Application Programming Interface) und die Datenbank-Engine, um sicherzustellen, dass alle Benutzeraktionen auf der Festplatte des Servers erfasst werden. Z. B. Wenn ein Benutzer eine Nachricht in Microsoft Outlook speichert, ruft MAPI zuerst den Informationsspeicher, der dann die Datenbank-Engine aufruft, die dann die Änderungen auf den Datenträger schreibt.

JET-Datenbankmodul

Exchange Server-Datenbanken basieren auf das JET-Format, die verwendet-Protokolldateien zum Verfolgen und Verwalten von Informationen. Microsoft JET ist eine erweiterte 32-Bit-Multithread Datenbankmodul, die Geschwindigkeit und Leistung mit anderen erweiterten Features zur Verbesserung der transaktionsbasierte Verarbeitungsfunktionen kombiniert.

Das Datenbankmodul führt eine Zwischenspeicherung den Datenträger im Speicher durch Vertauschen von 4 KB (KB)-Seiten von Daten in der Speicher. Es aktualisiert die Seiten im Speicher und schreibt neue oder aktualisierte Seiten zurück auf den Datenträger. Dies macht das System effizienter, da bei Anforderungen stammen, die Datenbank-Engine Puffer Daten im Arbeitsspeicher statt ständig auf dem Datenträger.

In Versionen ist vor Exchange Server 5.5 der Puffercache eine feste Größe. Wenn mehr Arbeitsspeicher benötigt wird, muss der Administrator die Größe des Puffers manuell ändern.

Exchange ermöglicht Server 5.5, dynamische Pufferreservierung den Puffercache vergrößert oder verkleinert, je nachdem, wie viel Speicher verfügbar ist und welche Ressourcen von anderen Diensten verwendet werden, die auf dem Microsoft Windows NT Server-Computer ausgeführt werden. Wenn andere Dienste Speicher nicht verwenden, nimmt das Exchange Server-Datenbankmodul so viel Arbeitsspeicher wie benötigt. Wenn andere Dienste Speicher benötigen, können das Datenbankmodul einige Speicherplatz von Seiten auf der Festplatte übertragen und Verkleinern der Größe des Puffers.

Nimmt ein Benutzer eine Anforderung, das Datenbankmodul lädt die Anforderung in den Arbeitsspeicher und markiert die Seiten als "fehlerhaft" (eine "geändert"-Seite ist eine Seite, die mit Daten geschrieben wurde und ist immer noch im Speicher gehalten wird). Dieser modifizierten Seiten werden später in die Informationsspeicher-Datenbanken auf dem Datenträger geschrieben.

Verwalten der Datenbankkonsistenz

Obwohl die effizienteste Methode zum Verarbeiten Daten im Arbeitsspeicher Zwischenspeichern ist, ist ein Effekt, dass Informationen auf der Festplatte nie vollständig auf dem neuesten Stand ist. Modifizierte Seiten im Speicher führen die Datenbanken als inkonsistent gekennzeichnet werden, obwohl Exchange Server normal ausgeführt wird. Datenbanken sind tatsächlich in einen konsistenten Zustand nur wenn alle modifizierten Seiten erfolgreich übertragen, auf dem Datenträger während der ein Herunterfahren, in denen keine Fehler auftreten.

Was geschieht, wenn Sie den Inhalt des Arbeitsspeichers verlieren? Beispielsweise, bleiben Was geschieht, wenn der Server abstürzt, bevor die Daten auf Datenträger und Sie geschrieben werden mit einer inkonsistenten Datenbank? Exchange verwendet Transaktionsprotokolldateien zum Wiederherstellen von in dieser Situation.

Transaktion-Protokolldateien

Transaktionsprotokolldateien behalten Sie eine sichere Kopie des flüchtigen Daten, die im Speicher. Wenn das System abstürzt, ermöglichen vorausgesetzt, die Datenbank unbeschädigt ist, ist die Protokolldateien Daten bis auf die letzte zugesicherten Transaktion vor dem Absturz wiederherzustellen. (Beachten Sie, dass es empfohlen wird, die Protokolldateien auf einer dedizierten Festplatte zu speichern, damit die Protokolle nicht von mögliche Datenträgerfehler betroffen sind, die die Datenbank beschädigen kann.)

Exchange ist ein "transaktionsbasierte" messaging System, und der Informationsspeicher ist eine Transaktionsdatenbank. Eine Transaktion ist ein Satz von Änderungen an einer Datenbank, wie z. B. Einfügungen, Löschungen und Aktualisierungen, in denen das System vier "ACID" invarianten folgt:
  • Atomar: Entweder alle Operationen auftreten oder keines der diese auftreten.
  • Konsistent: Die Datenbank wird von einem richtigen Zustand in einen anderen transformiert.
  • Isolierte: Änderungen werden erst sichtbar Sie übernommen werden.
  • Permanente: Zugesicherte Transaktionen werden in der Datenbank beibehalten, selbst wenn das System stürzt ab.
Diese invarianten folgenden bedeutet, dass das Datenbankmodul eine Transaktion, übermittelt nur, wenn Sie garantieren kann, dass die Daten dauerhaften oder persistent, von Systemausfällen oder anderen Fehlern geschützt ist. Das Datenbankmodul übernimmt Daten nur, wenn die Daten aus dem Speicher in die Transaktionsprotokolldatei auf der Festplatte übertragen wurde.

Um eine Nachricht aus dem Posteingang in Hoch Ordner zu verschieben, führt Exchange Server z. B. drei Vorgänge:
  1. Löscht die Nachricht aus dem Posteingang
  2. Fügt die Nachricht in den Ordner wichtig
  3. Aktualisiert die Informationen zu jedem Ordner entsprechend die Anzahl der Elemente und ungelesene Elemente
Diese Vorgänge werden in einer Transaktion ausgeführt. Die Reihenfolge der Operationen spielt keine Rolle. Exchange Server können problemlos die Nachricht aus dem Posteingang löschen, da der Löschvorgang ein Commit ausgeführt wurde, nur, wenn die Nachricht in den Ordner wichtig sicher eingefügt wird. Selbst wenn das System abstürzt, wird Exchange Server verliert nie eine Nachricht beim Verschieben von es und endet nie mit zwei Kopien der Nachricht.

Logisch, Sie können die Daten wie das Verschieben aus dem Speicher in die Protokolldatei und dann in der Datenbank auf dem Datenträger vorstellen, was tatsächlich passiert ist jedoch, dass Daten aus dem Speicher in der Datenbank auf dem Datenträger verschoben. Die Protokolldateien sind optimiert für Hochgeschwindigkeitsverbindungen Schreibvorgänge damit während des normalen Betriebs das Datenbankmodul die Protokolldateien nie liest. Sie liest aus den Protokolldateien nur, wenn der Informationsspeicher-Dienst nicht ordnungsgemäß reagiert oder stürzt ab, und das Datenbankmodul durch die Wiedergabe der Protokolldateien wiederherstellen muss.

der Prüfpunkt-Datei

Das Datenbankmodul verwaltet eine Prüfpunkt-Datei mit Namen EDB.chk für jedes Protokoll Datei Sequenz in, um die Daten nachzuverfolgen, die noch nicht in die Datenbankdatei auf Festplatte geschrieben wurden. Die Datei Prüfpunkt ist ein Zeiger in der Protokoll-Sequenz, die angibt, in denen im Protokoll Datei des Informationsspeichers muss die Wiederherstellung bei einem Ausfall des beginnen. Die Datei Prüfpunkt ist entscheidend für effiziente Wiederherstellung. Ohne Sie würde den Informationsspeicher starten am Anfang der ältesten Protokolldatei auf dem Datenträger und überprüfen Sie jede Seite in jeder Protokolldatei bestimmen, ob es bereits in der Datenbank--ein zeitaufwändiger Prozess geschrieben wurde hatte, besonders wenn alle möchten Sie tun, ist die Datenbank konsistent sind.

Die Datei Prüfpunkt befindet sich auf dem Systemdatenträger. Wenn Sie die Systemfestplatte wiederherstellen, diese Datei fehlt möglicherweise oder in nur eine ungültige Version. Aber in den meisten Fällen die Datei Prüfpunkt kümmert sich selbst.

Standard-Protokollierung

Die folgenden Schritte veranschaulichen den Prozess der "normalen Protokollierung", in denen Daten in Transaktionsprotokolldateien geschrieben werden:
  1. Der Benutzer sendet eine Nachricht.
  2. MAPI-Aufrufen den Informationsspeicher, um es anzuweisen, dass der Benutzer die Nachricht sendet.
  3. Der Informationsspeicher startet eine Transaktion in der Datenbankengine und entsprechenden Änderungen an den Daten vornimmt.
  4. Das Datenbankmodul zeichnet die Transaktionen im Speicher durch dirtying eine neue Seite im Arbeitsspeicher.
  5. Gleichzeitig wird das Datenbankmodul sichert die Transaktion in die Transaktionsprotokolldatei und erstellt einen Protokolldatensatz. Wenn die Datenbank-Engine das Ende einer Transaktionsprotokolldatei erreicht, wird es über setzt und erstellt eine neue Protokolldatei in Folge.
  6. Das Datenbankmodul modifizierte Seite in der Datenbankdatei auf die Festplatte geschrieben.
  7. Die Datei Prüfpunkt wird aktualisiert.
Umlaufprotokollierung

Exchange Server unterstützt eine Funktion namens Umlaufprotokollierung, wenn Administratoren mehr Speicherplatz als Server, über die Datenwiederherstellung besorgt wurden, zu einem Zeitpunkt implementiert wurde.

Die Umlaufprotokollierung funktioniert in viele der gleichen Weise wie normale Protokollierung außer dass die Datei Prüfpunkt ist entscheidend für das Verfolgen von Informationen, die übertragen wird auf der Festplatte. Alte Dateien werden während zirkuläre Protokollierung als die Prüfpunkt Datei Fortschritte in die nächste Protokolldatei wiederverwendet. Wenn dies geschieht, können nicht Sie die Protokolldateien auf dem Datenträger in Verbindung mit Ihrem Sicherungsmedium verwenden, um der zuletzt übergebenen Transaktion wieder.

Standardmäßig ist die Umlaufprotokollierung in Exchange aktiviert Server 5.5 verwaltet eine feste Größe für Protokolldateien und verhindern Anhäufung. Wenn eine Protokolldatei die 5 MB erreicht, wird das Datenbankmodul gelöscht und erstellt eine neue Protokolldatei in der Sequenz. Als Ergebnis hält Exchange Server nur genügend Daten auf der Festplatte zu die Datenbank konsistent, wenn ein Absturz auftritt.

Es wird empfohlen, dass Sie die Umlaufprotokollierung auf dem Exchange Server-Computer deaktivieren. Zirkuläre Protokollierung verringert sich möglicherweise die Notwendigkeit der Speicherplatz, aber es entfällt auch die Möglichkeit, bis auf die letzte zugesicherten Transaktion vor einem möglichen Ausfall wiederherzustellen. Sie Protokolldateien können nicht wiedergegeben und können nur Daten bis zur letzten vollständigen Sicherung wiederherstellen. Selbst wenn nur eine Protokolldatei überschrieben wird, besteht keine Möglichkeit, die andere 99 Prozent der die Protokolldaten wiederherzustellen.

Im Endeffekt negiert Umlaufprotokollierung die Vorteile eines Systems transaktionsbasierte. Sinnvoll Umlaufprotokollierung eingeschaltet lassen spielt werden, nur wenn Sie nicht die Daten müssen oder ob anderweitig Datenwiederherstellung Ihnen. Wenn Sie Protokolldateien verbraucht die Datenträgerressourcen besorgt sind, ist es besser Sie bereinigen, indem reguläre Onlinesicherungen durchführen. Sicherung entfernt Transaktionsprotokolldateien automatisch, wenn Sie nicht mehr benötigt werden.

Datenschutz

Es scheint, betrachten, dass die Datenbankdateien der wichtigste Aspekt der Datenwiederherstellung sind logische. In Exchange Server, Transaktionsprotokolldateien sind jedoch wichtiger da diese Informationen enthalten, die nicht in die Datenbankdateien enthalten ist. (Dies ist warum Sie diese auf einem stabilen Server gefunden und auf dedizierten, hochleistungsfähigen Datenträger platzieren sollten selbst wenn bedeutet, dass die Datenbankdateien auf langsamer Datenträger platzieren.)

Transaktionsprotokolldateien speichern Sie eine sichere Kopie auf dem Datenträger von flüchtigen Daten, die im Arbeitsspeicher ist, so dass das System im Falle von einem Ausfall wiederherstellen kann. Wenn das System stürzt ab, aber die Datenbank unbeschädigten, solange Sie die Protokolldateien haben, können Sie bis zu der zuletzt übergebenen Transaktion vor dem Fehler Daten wiederherstellen.

Transaktionsprotokolldateien können Sie auch Schreiben von Daten effizienter, da er schneller, Seiten nacheinander in einer Protokolldatei als Seiten in der Datenbank einfügen zu aktualisieren ist. Wenn eine Änderung in der Datenbank auftritt, aktualisiert das Datenbankmodul die Daten im Speicher. Synchron schreibt er einen Datensatz für die Transaktion in der Protokolldatei es mitteilen, wie die Transaktion schlägt das System wiederherstellen. Das Datenbankmodul schreibt die Daten dann an die Datenbank auf dem Datenträger. Um Datenträgereingabe/-Ausgabe zu minimieren, überträgt das Datenbankmodul Seiten, die Datenträger in Batches.

Jede Protokolldatei in einer Sequenz kann bis zu 5 MB der Daten enthalten. Wenn eine Protokolldatei voll ist, wird Sie als vorherige Protokolldatei umbenannt und eine neue mit dem Dateinamen EDB.log erstellt wird. Exchange Server ordnet jeder Protokolldatei eine hexadezimale Generationszahl. Da Protokolldateien den gleichen Namen der Datenbank-Engine Zeitstempel die Kopfzeile in jeder Datei in der Sequenz mit einer eindeutigen Signatur aufweisen können so, dass es zwischen verschiedenen Generationen von Protokolldateien unterscheiden kann.

Beschädigung der Datenbank

Exchange kann eine fehlschlägt, z. B. ein Hardwarefehler auftreten, die das System versucht, einen konsistenten Status erhalten benötigt. Da es verschiedene Arten von Beschädigungen der Datenbank durch unterschiedliche Symptome, sind verschiedene Tools und Techniken erforderlich, um Probleme diagnostizieren und beheben.

Es gibt zwei Arten von Beschädigungen:
  • Physikalische Beschädigung
    Auf der niedrigsten Ebene können Daten physisch auf dem Datenträger beschädigt werden. Dies ist normalerweise ein Hardware-bezogenes Problem, bei der immer Sie aus einer Sicherung wiederherstellen muss.
  • Logische Beschädigung
    Typische logische Beschädigung tritt am der Datenbankebene. Datenbank-Engine Fehler kann z. B. Indexeinträge auf fehlende Werte verursachen. Logische Beschädigung kann auch auf der Anwendungsebene in Postfächer, Nachrichten, Ordnern und Anlagen auftreten. Z. B. Anwendungsebene Beschädigung möglicherweise falsche Verweiszähler falschen Zugriff Steuerelement Ebenen einer Nachrichtenkopfzeile ohne einen Nachrichtentext verursachen usw..

Physische Beschädigung

Physikalische Beschädigung ist ernsthafte, da es Daten zerstört kann und der einzige, was Sie tun können ist Exchange aus Sicherung wiederherstellen. Es ist wichtig, dass Sie physikalische Beschädigung frühzeitig erkennen und der Probleme schnell beheben.

physische Beschädigung erkennen

Physikalische Beschädigung im Informationsspeicher wird im Anwendungsprotokoll der Ereignisanzeige die folgenden Fehler generiert:
  • -1018 (JET_errReadVerifyFailure) die Daten vom Datenträger gelesen entspricht nicht der Daten, die geschrieben wurde auf dem Datenträger.
  • -1022 (JET_errDiskIO), ist die Hardware, Treiber oder Betriebssystem Fehler zurückgeben.
  • -510 Jet_errLogWriteFail die Protokolldateien sind nicht genügend freier Speicher auf der Festplatte oder es liegt ein Hardwarefehler mit dem Protokoll Datei Datenträger.
Obwohl Exchange in der Regel eine Fehlermeldung-1018 oder-1022, anzeigt wenn physikalische Beschädigung vorliegt, können Sie physische Beschädigung erkennen, indem Onlinesicherungen, Microsofts empfohlene Methode zum Sichern von Daten sind. Onlinesicherung ist auch die beste Möglichkeit zum Erkennen von Beschädigungen in einer Datenbankdatei, da Sie der einzige Prozess ist, der jede einzelne Seite in der Datenbank systematisch überprüft.

Beim Ausführen einer Onlinesicherung wird die Windows NT Backup Software liest jede 4 KB-Seite in der Datenbankdatei, übergibt es an die Datenbank-Engine und dann auf Band schreibt. Überprüft die Datenbank-Engine, ob die Prüfsumme auf jeder Seite korrekt ist. Wenn die Prüfsumme auf der Seite die Prüfsumme nicht, die das Datenbankmodul berechnet überein stimmt, ist physische Datenbankbeschädigung auf der Festplatte und NT Backup Protokolle ein-1018-Fehler.

physische Beschädigung zu verhindern

Die beste Methode um eine physische Beschädigung zu vermeiden ist Rüsten den Server mit Hardwarekomponenten Qualität und das System ordnungsgemäß konfigurieren. Stellen Sie sicher, dass Sie nicht auf Dateiebene Dienstprogramme, wie z. B. antivirus-Software für Datenbank- und Protokolldateien Dateien auf dem Computer ausgeführt werden, auf dem Exchange Server ausgeführt wird.

Wenn Sie zuverlässige Hardware verfügen, sehen Sie möglicherweise nie Anzeichen für physische Beschädigung. Wenn Sie ständig in-1018-Fehler ausführen, müssen Sie möglicherweise ein Hardwareproblem, möglicherweise ein fehlerhafter Datenträger oder Datenträgercontroller.

Ein Wort zum Zwischenspeichern von Write-Back: einige Write-Back Zwischenspeichern Array Controller zurückgeben erfolgreich Commits falsch auf Transaktionen, bevor die Daten tatsächlich gesichert wurden auf dem Datenträger. Die sicherste besteht darin, Write-Back Zwischenspeicherung, wenn der Prozess Batterie hat deaktiviert zu Sicherung aktivieren. Wenn Sie Write-Back-caching, vermeiden Sie eine beschädigte Datenbank, indem sichergestellt wird, dass Daten vollständig geschützt sind und Sie haben Verfahren, um sicherzustellen, dass zwischengespeicherte Daten auf den rechten Festplatten nach einem Absturz wiedergegeben werden.

physische Beschädigung wiederherstellen

Die einzige Möglichkeit physische Datenbank eine Beschädigung von besteht darin, aus der letzten guten Sicherung wiederherstellen (Wenn eine Sicherung ohne Fehler ausgeführt wurde, es ist gut) und die Protokolldateien Vorwärts um das System in einen konsistenten und unbeschädigten Zustand zu bringen. Wiederholte Fehler weist auf wahrscheinlich ein Problem mit dem Datenträger, auf dem sich die Datenbank befindet.

Tatsächlich besteht keine sichere Möglichkeit, physikalische Beschädigung der Datenbank zu reparieren. Sie können die Eseutil.exe ausführen Dienstprogramm im Reparaturmodus aus, um die Datenbank wieder funktionsfähig zu erhalten, aber dies wird abgeraten, da Eseutil einfach fehlerhafte Seiten gelöscht.

Hinweis: Wenn es überhaupt möglich ist, verwenden Eseutil im Reparaturmodus (Eseutil/p). "Eseutil", die mit Exchange-Server stammt ist letzter Ausweg zum Datenbankschaden reparieren, wenn alle anderen fehlschlägt. Im Reparaturmodus wird eine fehlerhafte Datenbank, die erneut durch Löschen von einfach die beschädigte Seiten ausgeführt. Eseutil sollte niemals zum Wiederherstellen von Daten verwendet werden. Wenn Sie den Befehl Eseutil/p ausführen, müssen Sie auch eine offline-Defragmentierung ( Eseutil/d ) ausführen, und Sie müssen führen den Befehl Isinteg - Test Alltests - Update , um die Datenbank auf einem konsistenten Zustand wiederherstellen.

Logische Beschädigung

Logische Beschädigung ist viel schwieriger zu diagnostizieren und beheben als physikalische Beschädigung, weil logische Beschädigung unvorhersehbar ist und wird i. d. r. durch Softwarefehler verursacht. Normalerweise muss ein Problem, durch die Beschädigung der logischen gewarnt. (Logische Beschädigung ist äußerst selten in Exchange Server 5.5.)

logische Beschädigung zu verhindern

Da logische Beschädigung so unvorhersehbar ist, ist keine absolute Sicherheit Möglichkeit, dies zu verhindern. Es gibt jedoch Möglichkeiten, um das Risiko zu verringern:
  • Installieren Sie das neueste Servicepack für Microsoft Exchange Server Version 5.5 so bald wie möglich. Service Packs werden eine Anzahl bekannter Probleme in Exchange Server 5.5 behoben.

    Weitere Informationen zu Servicepacks und deren Bezugsquellen finden Sie folgenden Artikel der Microsoft Knowledge Base:
    241740Übersicht behobenen in Exchange Server 5.5 Service Pack 3
    254682XADM: Exchange Server 5.5 behebt Post-SP3-Datenbankmodul
    191014Wie Sie das neueste Service Pack für Exchange 5.5 Server erhalten
  • Stellen Sie sicher, dass Ihr Exchange Server-Computer sicher ist und, dass die Konfiguration nicht geändert werden.
Wenn Sie ein Problem feststellen und weiterhin, auftritt nachdem Sie auf diese Vorsichtsmaßnahmen durch, haben Sie möglicherweise einen neuen Fehler gefunden. Wenn dies der Fall ist, benachrichtigen Sie Microsoft so bald wie möglich.
logische Beschädigung reparieren

Logische Beschädigung kann auftreten, in dem Informationsspeicher oder in die Datenbank-Engine. Da logische Beschädigung schwerwiegende Schäden an Daten führen kann, ignorieren Sie Berichten von Fehlern an.

Sie können die Isinteg-Dienstprogramm, um Probleme in den Informationsspeicher oder das Dienstprogramm Eseutil zum Einchecken in Probleme in die Datenbank-Engine zu überprüfen. Hinweis, dass Sie diese Dienstprogramme nur als letzten Ausweg verwenden Nachdem Sie versucht haben, das System aus einer Sicherung wiederherzustellen.

Dienstprogramms "Isinteg"

Die Informationen speichern Integritätsprüfung (Isinteg) findet und behebt Fehler aus dem öffentlichen und privaten Informationsspeicher-Datenbanken. Dieser Fehler können verhindern, dass den Informationsspeicher gestartet oder verhindern, dass Benutzer anmelden und empfangen, öffnen oder Löschen von e-Mail.

Isinteg ist nicht für die Verwendung als Teil von normalen Informationen Speicherwartung vorgesehen; er wird bereitgestellt, um Disaster Recovery Situationen zu unterstützen. Beispielsweise können Sie Isinteg aus, um Informationen speichern Leistungsindikatoren im Speicher zu beheben, wenn Sie nach einem Systemabsturz nicht synchron abgerufen, ausführen.

Da des Dienstprogramms Isinteg auf der logischen Schemaebene funktioniert, können Sie Daten wiederherstellen, die Dienstprogramm "Eseutil" nicht wiederherstellen kann. Dies ist da Daten, die für das Dienstprogramm Eseutil Ebene der physischen Schema gültig ist auf der logischen Schemaebene semantisch ungültig werden können. Isinteg zeichnet Informationen im Anwendungsprotokoll in der Ereignisanzeige, Sie den Fortschritt der Wiederherstellung überwachen können.

Das Dienstprogramm Isinteg führt zwei Hauptaufgaben:
  • Diese patches des Informationsspeichers nach einer Wiederherstellung aus einer Offlinesicherung.
  • Sie testet und behebt optional Fehler im Informationsspeicher.
Zusätzliche Informationen zur Problembehandlung bei der Informationsspeicher und Dienstprogramm "Isinteg" finden Sie im Artikel der Microsoft Knowledge Base:
182081XADM: Beschreibung des Dienstprogramms ISINTEG

oder unter das Isinteg.rtf-Dokument auf der Exchange Server 5.5-CD im Verzeichnis Support\Utils.

des Dienstprogramms "Eseutil"

Das Dienstprogramm Eseutil untersucht die Struktur der Datenbanktabellen und Einträge und defragmentiert, repariert und überprüft die Integrität der Informationsspeicher und Verzeichnis. Da beschädigte Seiten Eseutil in Reparaturmodus ausgeführt einfach gelöscht werden, verwenden dieses Dienstprogramm erst, nachdem Sie versucht haben, aus einer Sicherung wiederherstellen.

Zusätzliche Informationen zum Dienstprogramm "Eseutil" finden Sie die Artikel der Microsoft Knowledge Base:
192185: XADM Defragmentieren mithilfe des "ESEUTIL" (Eseutil.exe)
oder das Dokument Eseutil.rtf auf die Exchange 5.5-CD im Verzeichnis Support\Utils.

Datensicherung

Da Exchange Server auf Transaktion basiert, vermeiden einer Sicherung auf Dateiebene oder offline der Datenbankdateien auf dem Datenträger. Am besten stellen Sie sicher, dass Sie alle Daten, im System beibehalten werden, einschließlich Transaktionen, die noch nicht wurden auf den Datenträger geleert, ist die Durchführung regelmäßige Sicherungen online.

Online Backup

Online-Sicherung können Sie Exchange Server-Datenbanken auf Ihrem Sicherungsmedium gesichert ohne Herunterfahren des Servers. Wenn Exchange Server eine Onlinesicherung aller Dienste, einschließlich den Informationsspeicher ausgeführt wird weiterhin normal ausgeführt. Seiten weiterhin im Arbeitsspeicher aktualisiert und die Datenbankdateien auf Datenträger übertragen werden, Transaktionen werden in den Protokolldateien aufgezeichnet und die Datei Prüfpunkt weiterhin zusammen verschieben.

Exchange verwendet eine (Patch) PAT-Datei, die protokolliert aktualisierte Seiten während die backup-Software ausgeführt wird, um sicherzustellen, dass Seiten, die während der Sicherung geändert werden ebenfalls gesichert werden. Es gibt zwei PAT-Dateien Priv.PAT für den privaten Informationsspeicher und Pub.pat für den öffentlichen Informationsspeicher.

Wenn Sie eine Onlinesicherung durchführen, überprüfen Sie regelmäßig das Anwendungsprotokoll in der Ereignisanzeige um sicherzustellen, dass Sicherungen erfolgreich abgeschlossen werden.

Prozess der Onlinesicherung

Ein Sicherungsprogramm, z. B. Windows NT Backup (Ntbackup.exe) führt folgende während einer vollständigen Sicherung oder eine Kopie-Sicherung:
  1. Erstellt eine Kopie der Datenbank und bis zu dem Band sichert.
  2. Hinzugefügt eine Teilmenge der Seiten die PAT-Datei, die Seiten, die nach auf Band kopierten ändern.
  3. Benennt die aktuelle EDB.log-Datei zu EDB X .log, wobei x die Protokollerzeugungsnummer der Datei im hexadezimalen Format, und eine neue Protokollgenerierung erstellt.
  4. Bei einer vollständigen Sicherung sichert die PAT-Datei und alle Protokolldateien nach der Prüfpunkt (außer der neuen EDB.log) auf dem Band. In einer Kopiesicherung sichert alle Protokolldateien, vor und nach der Prüfpunkt.
  5. In einer vollständigen Sicherung löscht Transaktionsprotokolldateien, die älter als die Prüfpunkt sind. In einer Kopiesicherung wird keine Transaktionsprotokolldateien gelöscht.
Ein Sicherungsprogramm führt folgende während einer inkrementellen Sicherung oder eine differenzielle Sicherung:
  1. In einer inkrementellen Sicherung, macht, der eine Kopie des Protokolls Dateien und sichert Sie bis zu dem Band ist. In einer differenziellen Sicherung kopiert die Datenbank auf Band.
  2. Hinzugefügt eine Teilmenge der Seiten die PAT-Datei, die Seiten, die nach auf Band kopierten ändern.
  3. Benennt die aktuelle Datei Edb.log in EDB X .log, und eine neue Protokollgenerierung erstellt.
  4. Sichert die PAT-Datei und alle Protokolldateien vor und nach der Prüfpunkt, einschließlich der neuen EDB.log auf Band.
  5. In einer inkrementellen Sicherung löscht Transaktionsprotokolldateien, die älter als die Prüfpunkt. Bei einer differenziellen Sicherung löscht keine Protokolldateien.

Offlinesicherungs-

Versuchen Sie, vermeiden Sie Offlinesicherungen durchführen. In einer Onlinesicherung des Sicherungsprogramms Dateien für Sie verwaltet, aber Offlinesicherung ist eine manuelle, arbeitsintensiver Prozess, anfällig für menschliche Fehler. Darüber hinaus kann nicht in einer Offlinesicherung die Prüfsumme auf jeder Seite der Datenbank überprüft werden. Onlinesicherungen sind die einzigen wertvollsten Tool zum Erkennen von Beschädigungen und Datenwiederherstellung durchführen.

Weitere Informationen zu Sicherungen finden Sie in der Microsoft Knowledge Base:
191357XADM: Wiederherstellen einer einzelnen Datenbank aus vollständig Online Sicherungskopien
179308XADM: How To Exchange Online Sicherung überprüfen

Eigenschaften

Artikel-ID: 271987 - Geändert am: Samstag, 28. Oktober 2006 - Version: 5.1
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Keywords: 
kbmt kbinfo KB271987 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 271987
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

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