Grundlegendes zum Exchange 2010-Informationsspeicher

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Der Exchange-Informationsspeicher ist eine Speicherplattform, die ein einziges Repository zum Verwalten mehrerer Typen von Informationen in einer Infrastruktur zur Verfügung stellt. Der Exchange-Informationsspeicher (store.exe) ist das zentrale Datenspeicherungsrepository für MicrosoftExchange Server 2010.

Inhalt

Datenbanken in Exchange 2010-Editionen

Logische Komponenten des Exchange-Informationsspeichers

Dateistruktur des Exchange-Informationsspeichers

Grundlegendes zur Transaktionsprotokollierung

Extensible Storage Engine

Status des Informationsspeichers

Wenig Speicherplatz in Datenbankprotokollen oder auf Datenbanklaufwerken

Grenzwerte für den Exchange-Informationsspeicher

Datenbanken in Exchange 2010-Editionen

Exchange 2010 ist in zwei Servereditionen verfügbar: Standard Edition und Enterprise Edition. Exchange 2010 Standard Edition ist auf die Anforderungen in Bezug auf Messaging und Zusammenarbeit von kleinen und mittelständischen Unternehmen ausgerichtet und kann auch für bestimmte Serverrollen oder Zweigstellen die richtige Wahl sein. Exchange 2010 Enterprise Edition ist für große Unternehmen konzipiert.

Exchange 2010 Standard Edition bietet Unterstützung für bis zu fünf Datenbanken. Exchange 2010 Enterprise Edition bietet Unterstützung für bis zu 100 Datenbanken.

Logische Komponenten des Exchange-Informationsspeichers

Postfachdatenbanken und Öffentliche Ordner-Datenbanken stellen die Hauptkomponenten des Exchange-Informationsspeichers dar. Diese Komponenten können sich entweder auf einem einzelnen Server befinden oder auf mehrere Server verteilt sein.

Postfachdatenbanken enthalten die Daten, Datendefinitionen, Indizes, Prüfsummen, Flags sowie andere Informationen, aus denen Postfächer in Exchange 2010 bestehen. Postfachdatenbanken enthalten private Daten einzelner Benutzer sowie Postfachordner, die beim Erstellen eines Postfachs für den betreffenden Benutzer generiert werden. Eine Postfachdatenbank wird als Exchange-Datenbankdatei (EDB-Datei) gespeichert.

Öffentliche Ordner-Datenbanken enthalten die Daten, Datendefinitionen, Indizes, Prüfsummen, Flags sowie andere Informationen, aus denen Öffentliche Ordner in der Exchange-Organisation bestehen.

In Exchange 2010 werden Öffentliche Ordner mithilfe der Exchange-Verwaltungsshell verwaltet. (Sie können auch eine begrenzte Anzahl von Verwaltungsaufgaben für Öffentliche Ordner-Datenbanken in der Exchange-Verwaltungskonsole ausführen.) Weitere Informationen zum Verwalten von Öffentlichen Ordnern finden Sie unter Verwalten von Öffentlichen Ordnern und Grundlegendes zu Öffentlichen Ordnern.

Datenbanken in Exchange 2010-Editionen

Dateistruktur des Exchange-Informationsspeichers

Sie verwalten den Exchange-Informationsspeicher, indem Sie mit dessen logischen Komponenten (z. B. Datenbanken) arbeiten. In Exchange 2010 werden Daten jedoch in speziellen Datendateien wie Exchange-Datenbankdateien (EDB-Dateien), Transaktionsprotokolldateien (LOG-Dateien) und Prüfpunktdateien (CHK-Dateien) gespeichert. Sofern Sie Daten nicht sichern oder wiederherstellen, werden Sie selten mit diesen Dateien direkt arbeiten. In der folgenden Tabelle werden die einzelnen Dateien ausführlicher beschrieben.

Dateistruktur des Exchange-Informationsspeichers

Datenbanken in Exchange 2010-Editionen

Grundlegendes zur Transaktionsprotokollierung

Die Exchange-Transaktionsprotokollierung ist ein robuster Wiederherstellungsmechanismus von ESE, durch den eine Exchange-Datenbank nach einer abrupten Beendigung der Datenbank zuverlässig in einem konsistenten Zustand wiederhergestellt werden kann. Der Protokollierungsmechanismus wird auch beim Wiederherstellen von Onlinesicherungen verwendet. In diesem Abschnitt werden die Einzelheiten der Exchange 2010-Transaktionsprotokollierung beschrieben. Darüber hinaus ist darin auch eine kurze Beschreibung der Umlaufprotokollierung enthalten.

Exchange-Transaktionsprotokollierung

Bevor Änderungen an einer Exchange-Datenbankdatei vorgenommen werden, schreibt Exchange die Änderungen in eine Transaktionsprotokolldatei. Nachdem eine Änderung sicher protokolliert wurde, kann sie in die Datenbankdatei geschrieben werden. Im Allgemeinen werden diese Änderungen für Endbenutzer unmittelbar nach dem Sichern im Transaktionsprotokoll, jedoch bevor sie in die Datenbankdatei geschrieben wurden, verfügbar.

In Exchange wird ein ausgefeiltes internes Speicherverwaltungssystem verwendet, das für hohe Leistung optimiert ist und die Zwischenspeicherung Dutzender GB von Datenbankseiten verwaltet. Das physische Schreiben von Änderungen in die Datenbankdatei ist während des normalen Betriebs eine Aufgabe mit niedriger Priorität.

Wenn eine Datenbank unerwartet beendet wird, gehen die zwischengespeicherten Änderungen nicht einfach verloren, nur weil der Speichercache zerstört wurde. Wenn die Datenbank neu gestartet wird, durchsucht Exchange die Protokolldateien und rekonstruiert und übernimmt alle Änderungen, die noch nicht in die Datenbankdatei geschrieben wurden. Dieser Vorgang wird als Wiedergabe der Protokolldateien bezeichnet. Die Datenbank ist so strukturiert, dass von Exchange ermittelt werden kann, ob ein beliebiger Vorgang in einer beliebigen Protokolldatei bereits in die Datenbank übernommen wurde, in die Datenbank übernommen werden muss oder nicht zur Datenbank gehört.

Statt alle Protokollinformationen in eine einzige große Datei zu schreiben, verwendet Exchange eine Reihe von Protokolldateien, von denen jede genau ein MB (1.024 KB) groß ist. Wenn eine Protokolldatei voll ist, schließt Exchange diese und benennt sie unter Zuweisung einer Sequenznummer um. Der Name des ersten gefüllten Protokolls endet auf "Enn00000001.log". Die Angabe nn bezieht sich auf eine zweistellige Zahl, die als Basisname oder Protokollpräfix bezeichnet wird.

Die Protokolldateien für die einzelnen Datenbanken werden durch Dateinamen mit nummerierten Präfixen (z. B. E00, E01, E02 oder E03) unterschieden. Die für eine Datenbank aktuell geöffnete Protokolldatei weist den Namen "Enn.log" auf. Eine Sequenznummer wird erst zugewiesen, nachdem die Datei mit Daten gefüllt und geschlossen wurde.

Die Prüfpunktdatei ("Enn.chk") protokolliert, wie weit Exchange mit dem Schreiben der protokollierten Informationen in die Datenbankdateien fortgeschritten ist. Den einzelnen Protokolldatenströmen ist jeweils eine Prüfpunktdatei zugeordnet, und zu jeder Datenbank gehört ein separater Protokolldatenstrom.

Protokolldateien werden hexadezimal nummeriert. Die Protokolldatei nach der Datei "E0000000009.log" heißt daher "E000000000A.log" und nicht "E0000000010.log". Sie können die Sequenznummern der Protokolldateien in dezimale Werte umwandeln, indem Sie die Anwendung Windows-Rechner ("Calc.exe") im Modus Wissenschaftlich verwenden. Führen Sie hierzu "Calc.exe" aus, und klicken Sie dann im Menü Ansicht auf Wissenschaftlich.

Zum Anzeigen der dezimalen Sequenznummer einer bestimmten Protokolldatei können Sie deren Kopfzeile mithilfe des Tools "Eseutil.exe" (Exchange Server Database Utilities) untersuchen. Die erste 4-KB-Seite jeder Protokolldatei enthält Kopfzeileninformationen, die die Protokolldatei und die Datenbanken, zu denen sie gehört, beschreiben und identifizieren. Der Befehl Eseutil /ml [log file name] zeigt die Kopfzeileninformationen an.

Wenn Sie die falsche Option zum Anzeigen einer Kopfzeile verwenden (z. B. /ml für eine Datenbankkopfzeile anstelle von /mh), wird ein Fehler ausgegeben, oder die angezeigten Kopfzeileninformationen sind unvollständig bzw. falsch.

Während eine Datenbank eingebunden wird, können Sie die Kopfzeile der Datenbank nicht anzeigen. Sie können auch nicht die Kopfzeile der aktuellen Protokolldatei ("Enn.log") anzeigen, während eine Datenbank eingebunden wird. In Exchange bleibt die aktuelle Protokolldatei geöffnet, solange sie von einer Datenbank verwendet wird. Sie können jedoch die Kopfzeile der Prüfpunktdatei anzeigen, während Datenbanken eingebunden werden. Exchange aktualisiert die Prüfpunktdatei alle 30 Sekunden, und ihre Kopfzeile kann nur in dem Moment nicht angezeigt werden, in dem eine Aktualisierung auftritt.

Als Exchange-Administrator sollten Sie Exchange-Dateikopfzeilen verstehen. Wenn Sie die Dateikopfzeilen verstehen, können Sie ermitteln, welche Datenbank und Protokolldateien zusammengehören und welche Dateien für eine erfolgreiche Wiederherstellung erforderlich sind.

Beachten Sie im folgenden Beispiel für eine Protokolldatei-Kopfzeile die ersten vier Zeilen.

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

Aus diesen Kopfzeilen der Protokolldatei geht hervor, dass diese Protokolldatei die aktuelle Protokolldatei ist, weil der Protokolldateiname keine Sequenznummer aufweist. Aus der Zeile lGeneration geht hervor, dass nach dem Füllen und Schließen der Protokolldatei die zugehörige Sequenznummer B (entsprechend dem dezimalen Wert 11) lautet. Der Basisname ist e00, daher lautet der endgültige Protokolldateiname "E000000000B.log".

Der Wert Checkpoint im vorherigen Kopfzeilenbeispiel wird zwar nicht aus der Kopfzeile der Protokolldatei gelesen, jedoch hier so angezeigt, als wäre dies der Fall. "Eseutil.exe" liest den Wert Checkpoint direkt aus "Enn.chk". Sie müssen daher keinen separaten Befehl eingeben, um zu erfahren, wo sich die Prüfpunktdatei befindet. Wenn die Prüfpunktdatei zerstört wurde, wird für den Wert Checkpoint die Angabe NOT AVAILABLE angezeigt. In diesem Fall befindet sich der Prüfpunkt in der aktuellen Protokolldatei (0xB), und die Angaben 7DC und 6F zeigen an, an welcher Position der Protokolldatei sich der Prüfpunkt befindet. Diese Informationen sind nur selten von praktischem Nutzen.

Wenn die Prüfpunktdatei zerstört wird, kann Exchange Protokolldateien trotzdem ordnungsgemäß wiederherstellen und wiedergeben. Zu diesem Zweck beginnt Exchange jedoch, Protokolldateien zu durchsuchen (beginnend mit der ältesten verfügbaren Datei), anstatt beim Prüfpunktprotokoll zu beginnen. Exchange überspringt Daten, die bereits in die Datenbank übernommen wurden, und arbeitet die Protokolle sequenziell ab, bis Daten gefunden werden, die übernommen werden müssen.

Normalerweise dauert es nur ein oder zwei Sekunden, bis Exchange eine Protokolldatei durchsucht hat, die bereits in die Datenbank übernommen wurde. Wenn eine Protokolldatei Vorgänge enthält, die in die Datenbank geschrieben werden müssen, kann deren Übernahme zwischen 10 Sekunden und mehreren Minuten dauern. Die Inhalte einer Protokolldatei werden durchschnittlich in maximal 30 Sekunden in die Datenbank geschrieben.

Wenn eine Exchange-Datenbank normal heruntergefahren wird, werden alle ausstehenden Daten in die Datenbankdateien geschrieben. Nach dem normalen Herunterfahren wird der Datenbankdateisatz als konsistent betrachtet, und Exchange trennt die Datenbank von ihrem Protokolldatenstrom. Das bedeutet, dass die Datenbankdateien jetzt abgeschlossen (aktuell) sind. Die Transaktionsprotokolle sind zum Starten der Datenbankdateien nicht erforderlich.

Sie können feststellen, ob eine Datenbank ordnungsgemäß heruntergefahren wurde, indem Sie den Befehl Eseutil /mh ausführen und die Dateikopfzeilen untersuchen.

Wenn alle Datenbanken getrennt wurden und den Status "Clean Shutdown" aufweisen, können alle Protokolldateien ohne negative Auswirkungen auf die Datenbanken sicher gelöscht werden. Wenn Sie dann alle Protokolldateien löschen, würde von Exchange eine neue Sequenz von Protokollen beginnend mit "Enn00000001.log" generiert. Sie könnten die Datenbankdateien auf einen anderen Server mit vorhandenen Protokolldateien verschieben, und die Datenbanken würden an einen anderen Protokolldatenstrom angefügt.

Wenn sich eine Datenbank im Status "Dirty Shutdown" befindet, müssen alle vorhandenen Transaktionsprotokolle ab dem Prüfpunkt verfügbar sein, bevor Sie die Datenbank erneut einbinden können. Wenn diese Protokolle nicht verfügbar sind, müssen Sie die Datenbank reparieren, indem Sie den Befehl Eseutil /p ausführen, um einen konsistenten Zustand der Datenbank zu erzielen und ihre Startbereitschaft sicherzustellen.

Achtung:

Wenn Sie eine Datenbank reparieren müssen, gehen in der Regel einige Daten verloren. Die Datenverluste sind häufig nur sehr gering, können jedoch sehr schwerwiegend sein. Nach der Ausführung von Eseutil /p für eine Datenbank müssen Sie Eseutil/ d ausführen, um die Datenbank zu defragmentieren. Durch diesen Vorgang werden alle Datenbankindizes und Speicherstrukturen gelöscht und anschließend neu erstellt.

Die Transaktionsprotokollierung ermöglicht nicht nur die zuverlässige Wiederherstellung von Exchange nach einer unerwarteten Datenbankunterbrechung, sondern ist auch für das Erstellen und Wiederherstellen von Onlinesicherungen von großer Bedeutung. Weitere Informationen zum Erstellen und Wiederherstellen von Onlinesicherungen finden Sie unter Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung.

Datenbanken in Exchange 2010-Editionen

Umlaufprotokollierung

Sie können Exchange zum Einsparen von Speicherplatz konfigurieren, indem Sie die Umlaufprotokollierung aktivieren. Durch die Umlaufprotokollierung können in Exchange Transaktionsprotokolldateien nach Übergabe der in den Protokolldateien enthaltenen Daten an die Datenbank überschrieben werden. Bei Aktivierung der Umlaufprotokollierung können Daten jedoch nur bis zur letzten vollständigen Sicherung wiederhergestellt werden. Sie können die Umlaufprotokollierung beispielsweise aktivieren, wenn Sie den systemeigenen Exchange-Datenschutz verwenden, bei dem keine Sicherungskopien erstellt werden. Wenn Sie die Erstellung von Protokollen verhindern möchten, müssen Sie die Umlaufprotokollierung aktivieren.

Bei der von Exchange 2010 verwendeten Standardtransaktionsprotokollierung wird jede Datenbanktransaktion in eine Protokolldatei und dann in die Datenbank geschrieben. Wenn eine Protokolldatei eine Größe von 1 MB erreicht, wird sie umbenannt, und es wird eine neue Protokolldatei erstellt. Im Lauf der Zeit führt diese Vorgehensweise zu einer Sammlung von Protokolldateien. Wenn Exchange unerwartet beendet wird, können Sie die Transaktionen wiederherstellen, indem Sie die Daten aus diesen Protokolldateien in der Datenbank wiedergeben. Bei der Umlaufprotokollierung wird die erste Protokolldatei überschrieben und wiederverwendet, nachdem die darin enthaltenen Daten in die Datenbank geschrieben wurden.

In Exchange 2010 ist die Umlaufprotokollierung standardmäßig deaktiviert. Durch Aktivieren der Umlaufprotokollierung verringern Sie die Anforderungen an den Speicherplatz auf den Laufwerken. Ohne den vollständigen Satz von Transaktionsprotokolldateien können jedoch Daten, die aktueller sind als die letzte vollständige Sicherung, nicht wiederhergestellt werden. In einer normalen Produktionsumgebung wird von der Verwendung der Umlaufprotokollierung abgeraten.

Weitere Informationen zum Aktivieren bzw. Deaktivieren der Umlaufprotokollierung finden Sie unter Konfigurieren der Eigenschaften einer Postfachdatenbank.

Datenbanken in Exchange 2010-Editionen

Extensible Storage Engine

Die ESE-Datenbank (Extensible Storage Engine) wird von Exchange-Postfachdatenbanken sowie von der Warteschlange auf Hub-Transport- und Edge-Transport-Servern verwendet. Bei ESE handelt es sich um eine ISAM-Tabellenverwaltung (Indexed Sequential Access Method) für mehrere gleichzeitig angemeldete Benutzer mit vollständigen Funktionen für DML (Data Manipulation Language) und DDL (Data Definition Language). Mit ESE können Datensätze von Anwendungen gespeichert sowie Indizes für verschiedenste Zugriffe auf diese Datensätze erstellt werden. Weitere Informationen zu ESE finden Sie unter Architektur von Extensible Storage Engine. Informationen zu Verbesserungen in Exchange 2010 ESE finden Sie unter Neue wichtige Funktionen des Exchange-Informationsspeichers.

Datenbanken in Exchange 2010-Editionen

Status des Informationsspeichers

Vom Exchange-Informationsspeicher können mehrere Szenarien erkannt und korrigiert werden, die zu einem fehlerhaften Status des Informationsspeichers führen. Vom Exchange-Informationsspeicher können beschädigte Postfächer und Threadtimeouts verarbeitet, Berichts- und Warnfunktionen zum Signalisieren eines fehlerhaften Status des Exchange-Informationsspeichers verwendet sowie Probleme in Postfachdatenbanken und Öffentlichen Ordner-Datenbanken erkannt und behoben werden.

Erkennung und Korrektur beschädigter Postfächer

In einigen Fällen kann ein einziges Postfach mit beschädigten Daten (logisch oder physisch) zu Fehlern im Exchange-Informationsspeicher führen, sodass der Dienst für alle vom Server gehosteten Postfächer verweigert wird. Ebenso kann ein beschädigtes Postfach auch wiederholte Fehler des Exchange-Informationsspeichers verursachen. In diesem Abschnitt werden die Aktionen beschrieben, die vom Exchange-Informationsspeicher zum Erkennen und Isolieren von beschädigten Postfächern ausgeführt werden.

Isolieren des beschädigten Postfachs

Es gibt verschiedene Typen von Ereignissen, bei denen ein Postfach vom Exchange-Informationsspeicher als potenzielle Bedrohung markiert wird:

• Wenn ein für dieses Postfach arbeitender Thread fehlerhaft ist

• Wenn das Postfach mehr als fünf Threads enthält, deren Status sich seit längerer Zeit nicht geändert hat

Ein Postfach, das eine potenzielle Bedrohung darstellt, wird markiert, wobei auch die Anzahl der Markierungen angegeben wird. Diese Informationen werden in der Registrierung gespeichert. Im Exchange-Informationsspeicher werden auch Zeitstempelinformationen gespeichert, in denen angegeben ist, wann das Postfach als potenzielle Bedrohung identifiziert wurde.

Während des Einbindens einer Datenbank werden vom Exchange-Informationsspeicher die Zeiten gelesen, zu denen die Postfächer als potenzielle Bedrohungen identifiziert wurden. Wenn mehr als zwei Stunden verstrichen sind, wird der Registrierungsschlüssel für das Postfach gelöscht. Der Vorteil des Speicherns dieser Informationen in der Registrierung besteht darin, dass sie in einer Umgebung mit hoher Verfügbarkeit von der Clusterdatenbank repliziert werden. Diese Informationen stehen sogar bei einem Failover des Exchange-Informationsspeichers den anderen Computern zur Verfügung. Der zum Isolieren des beschädigten Postfachs verwendete Registrierungsunterschlüssel lautet HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Private-{db guid}\QuarantinedMailboxes\{mailbox guid}. Die Schlüssel für diesen Pfad lauten CrashCount und LastCrashTime.

Die Einstellungen für die Anzahl der Fehler, die zur Quarantäne eines Postfachs führen, sowie für die Quarantänedauer eines Postfachs sind in den Schlüsseln MailboxQuarantineCrashThreshold und MailboxQuarantineDurationInSeconds des Unterschlüssels HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Private-{db guid}\QuarantinedMailboxes gespeichert.

Als Standardwerte sind drei Fehler für den Schlüssel MailboxQuarantineCrashThreshold und 21.600 Sekunden (sechs Stunden) für den Schlüssel MailboxQuarantineDurationInSeconds festgelegt.

Anwenden von Aktionen auf das beschädigte Postfach

Wenn ein Postfach innerhalb von zwei Stunden dreimal als Ursache für einen Fehler oder Deadlock identifiziert wird, markiert der Exchange-Informationsspeicher das Postfach in der Registrierung standardmäßig als isoliert (in Quarantäne). Ein Zugriff auf das Postfach ist erst nach Übergabe des Flags "OPEN_AS_ADMIN" zulässig. Eine Anmeldung von Exchange-Vorgängen (wie Inhaltsindizierung oder Postfach-Assistenten) ist unzulässig. Über die Registrierungsschlüssel QuarantineState und QuarantineTime wird nachverfolgt, ob sich das Postfach in Quarantäne befindet. Wenn das Postfach in den letzten zwei Stunden keine Fehler verursacht hat und sich nicht in Quarantäne befindet, wird der Registrierungspfad für das Postfach vom Exchange-Informationsspeicher bereinigt. Wenn sich ein Postfach seit dem Wert LastCrashTime länger in Quarantäne befindet, als vom Wert MailboxQuarantineDurationInSeconds festgelegt ist, wird die Quarantäne für das Postfach automatisch aufgehoben.

Zurücksetzen des Postfachs in Quarantäne

Wenn die Ursache für das beschädigte Postfach identifiziert und behoben wurde, muss der Registrierungsschlüssel für das Postfach in Quarantäne durch Löschen manuell zurückgesetzt werden. Wenn Sie diesen manuellen Schritt jedoch vergessen haben, werden die Quarantänepostfächer sechs Stunden nach Festlegen des Quarantäneflags vom Exchange-Informationsspeicher automatisch zurückgesetzt. Wenn das Problem nicht innerhalb dieses Zeitraums behoben wird, kann dies zu weiteren Fehlern führen, bevor das Postfach oder die Nachricht erneut isoliert wird.

Der Zeitraum für das Zurücksetzen von Quarantänepostfächern kann über den Registrierungsschlüssel HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Private-{db guid}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds gesteuert werden.

Berichterstattung und Warnungen

Mit dem Cmdlet Get-MailboxStatistics können Sie den Quarantänestatus eines Postfachs melden. Der Exchange-Informationsspeicher verfügt über einen Leistungsindikator für die Anzahl von Quarantänepostfächern. Der Name des Indikators lautet "MSExchangeIS-Postfach\Anzahl der Postfächer in Quarantäne".

Im Exchange-Informationsspeicher wird auch bei jedem Isolieren eines Postfachs ein Ereignis mit Details zum Postfach und Angaben zur Uhrzeit protokolliert. Mit dem Ereignis "10018" wird ein Postfach in Quarantäne identifiziert.

Datenbanken in Exchange 2010-Editionen

Datenbankreparatur

In Exchange 2010 Service Pack 1 (SP1) können Sie das Cmdlet New-MailboxRepairRequest verwenden, um Postfachbeschädigungen zu erkennen und zu reparieren. Sie können dieses Cmdlet für ein bestimmtes Postfach oder für eine Postfachdatenbank ausführen. Während der Ausführung dieses Tasks kann auf das zu reparierende Postfach nicht zugegriffen werden. Wenn Sie dieses Cmdlet für eine Postfachdatenbank ausführen, kann nur nicht auf das zu reparierenden Postfach zugegriffen werden. Alle anderen Postfächer in der Datenbank sind weiterhin funktionsfähig. Weitere Informationen finden Sie unter Erstellen einer Anforderung zur Postfachreparatur.

Mit dem Cmdlet New-MailboxRepairRequest werden die folgenden Arten von Postfachbeschädigungen erkannt und repariert:

• Suchordnerbeschädigungen (mit dem Wert SearchFolder des Parameters CorruptionType)

• Anzahl aggregierter Ordner, die unrichtige Werte widerspiegeln (mit dem Wert AggregateCounts des Parameters CorruptionType)

• Anzeigevorgänge für Ordner, die nicht den richtigen Inhalt wiedergeben (mit dem Wert FolderView des Parameters CorruptionType)

• Bereitgestellte Ordner, die falsch auf nicht bereitgestellte übergeordnete Ordner zeigen (mit dem Wert ProvisionedFolder des Parameters CorruptionType)

Nach dem Ausführen des Cmdlets New-MailboxRepairRequest können Sie die Details der Anforderung in der Ereignisanzeige anzeigen. Weitere Informationen finden Sie unter Anzeigen von Anforderungen zur Postfachreparatur in der Ereignisanzeige.

Sie können auch das Cmdlet New-PublicFolderDatabaseRepairRequest verwenden, um Replikationsprobleme in der Öffentliche Ordner-Datenbank zu erkennen und zu beheben. Während die Anforderung ausgeführt wird, kann weiterhin auf Öffentliche Ordner in der Öffentliche Ordner-Datenbank zugegriffen werden. Auf den Öffentlichen Ordner, der aktuell repariert wird, kann jedoch nicht zugegriffen werden. Weitere Informationen finden Sie unter Erstellen einer Reparaturanforderung für Öffentliche Ordner-Datenbank.

Datenbanken in Exchange 2010-Editionen

Erkennen und Melden von Timeouts

Deadlocks von Threads oder Threads, deren Status sich nicht ändert, sind weitere Hinweise auf einen fehlerhaften Exchange-Informationsspeicher. Wenn mehr als fünf Threads für ein einzelnes Postfach, zehn Threads für eine einzelne Datenbank oder 20 Threads für einen einzelnen Server ermittelt werden, bei denen innerhalb einer Minute keine Statusänderung erfolgt ist, wird auf dem Server ein Timeout gemeldet. Der Leistungsindikator für erkannte Timeouts lautet "MSExchangeIS\RPC-Anforderungstimeout erkannt".

Vom Exchange-Informationsspeicher werden auch die folgenden Ereignisse auf dem Server protokolliert:

• "10025" (meldet ein Timeout auf dem Exchange-Server)

• "10026" (meldet ein Timeout in der Datenbank)

• "10027" (meldet ein Timeout für ein einzelnes Postfach)

Beim Erkennen eines Timeouts für ein einzelnes Postfach wird das Postfach als potenziell beschädigt eingestuft und wie ein Fehler behandelt, indem der Wert des Schlüssels CrashCount erhöht wird. Dies kann zu einer Isolierung des Postfachs führen.

Datenbanken in Exchange 2010-Editionen

Wenig Speicherplatz in Datenbankprotokollen oder auf Datenbanklaufwerken

Wenn vom Exchange-Informationsspeicher erkannt wird, dass der für ein Protokoll oder auf einem Datenbanklaufwerk verfügbare Speicherplatz unter 1 GB beträgt, werden alle Transportzustellungen an diese Datenbank abgebrochen. Dadurch wird sichergestellt, dass auf einem Datenträger immer genügend Speicherplatz zur Verfügung steht. Wenn auf einem Datenträger nicht mehr genügend Speicherplatz zur Verfügung steht, ist kein Einbinden oder Debuggen der Datenbank möglich. Außerdem kann der Speicherplatz der Datenbank nicht freigegeben werden. Das ist ein Selbstschutzmechanismus, der nur aktiviert wird, wenn Sie nicht auf die Speicherplatzwarnungen der Überwachungsinfrastruktur reagieren.

Wenn der Speicherplatz wieder mehr als 1,5 GB beträgt, werden Zustellungen vom Exchange-Informationsspeicher wieder zugelassen. Dieses Verhalten wird von den folgenden Leistungsindikatoren angegeben:

• MSExchangeIS-Postfach\Blockierte Zustellung: Nicht ausreichend Datenbankspeicher

• MSExchangeIS-Postfach\Blockierte Zustellung: Nicht ausreichend Protokollspeicher

Vom Exchange-Informationsspeicher werden auch die folgenden Ereignisse auf dem Server protokolliert:

• "10014" (gibt wenig Speicherplatz im Protokoll an)

• "10015" (gibt wenig Speicherplatz in der Datenbank an)

Wenn Speicherplatzprobleme auftreten, können Sie zum Beheben des Problems die folgenden Aktionen ausführen:

• Löschen Sie Inhalt aus Postfächern. Insbesondere können Sie Nachrichten aus den Ordnern "Gelöschte Elemente" und "Gesendete Elemente" löschen.

• Löschen Sie Elemente aus dem Ordner "Wiederherstellbare Elemente". Weitere Informationen finden Sie unter Bereinigen des Ordners "Wiederherstellbare Elemente".

• Führen Sie die Datenbankwartung aus. Weitere Informationen finden Sie unter Verwalten von Postfachdatenbanken.

• Löschen Sie Transaktionsprotokolle. Weitere Informationen finden Sie unter Grundlegendes zu hoher Verfügbarkeit.

• Aktivieren Sie die Umlaufprotokollierung. Weitere Informationen finden Sie unter Konfigurieren der Eigenschaften einer Postfachdatenbank.

• Ändern Sie den Datenbankpfad unter Angabe eines Festplattenlaufwerks, auf dem mehr Speicherplatz verfügbar ist. Weitere Informationen finden Sie unter Ändern des Pfads der Postfachdatenbank für eine Postfachdatenbankkopie.

Datenbanken in Exchange 2010-Editionen

Grenzwerte für den Exchange-Informationsspeicher

In Exchange 2010 wurden Verbindungs- und Verwendungslimits für den Exchange-Informationsspeicher festgelegt, um zu verhindern, dass alle verfügbaren Verbindungen mit dem Exchange-Informationsspeicher von einer einzigen Anwendung oder von einem einzigen Benutzer verwendet werden. Wenn alle Verbindungen von einem Benutzer oder einer Anwendung verwendet werden, können andere Benutzer oder Anwendungen nicht auf den Exchange-Informationsspeicher zugreifen. Dies kann zu Downtime führen.

Weitere Informationen finden Sie unter Grenzwerte für den Exchange-Informationsspeicher.

Datenbanken in Exchange 2010-Editionen

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.