Grundlegendes zur Datenbankwartung

Gilt für: Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Änderungen der Architektur am Datenbankmodul in Microsoft Exchange Server 2010 verbessern die Leistung und die Zuverlässigkeit entscheidend. Diese Änderungen der Architektur ändern jedoch auch das Verhalten der Datenbankwartungstasks aus früheren Exchange Server-Versionen. In diesem Thema werden die Datenbankwartungstasks beschrieben, die in Exchange Server 2010-Datenbanken routinemäßig ausgeführt werden.

Alle Tasks, die in diesem Thema beschrieben werden, werden als Hintergrundwartung für Datenbanken bezeichnet.

Datenbankkomprimierung

Die Datenbankkomprimierung muss abgeschlossen werden, um ungenutzten Speicherplatz in der Datenbankdatei freizugeben. Die Datenbankkomprimierung gibt diesen ungenutzten Speicherplatz nicht für das Dateisystem frei. Stattdessen werden Seiten in der Datenbank freigegeben, indem Datensätze mit der geringstmöglichen Anzahl von Seiten zusammengefasst werden. Außerdem werden E/A-Vorgänge reduziert, die für den Zugriff auf die Seiten erforderlich sind. Dazu nutzt das ESE-Datenbankmodul die Datenbankmetadaten, also die Informationen, die Tabellen in der Datenbank beschreiben. Für jede Tabelle überprüft das ESE-Datenbankmodul jede Seite in der Tabelle und versucht, die Datensätze in logisch angeordnete Seiten zu verschieben.

Die Datenbankkomprimierung ist wichtig, weil sie die zur Sicherung der Datenbankdatei erforderliche Zeit reduziert und eine vorhersehbare Datenbankdateigröße sicherstellt. Dies ist wichtig, um die Größe von Server und Speicher genau zu bestimmen.

Die Datenbankkomprimierung wurde für Exchange Server 2010 überarbeitet. Der Vorgang stellt jetzt die Datenkontiguität vor der Komprimierungsgröße an erste Stelle. In früheren Versionen von Exchange Server lag der Fokus auf der Komprimierung des Speicherplatzes. Daher waren Seiten immer in zufälliger Reihenfolge angeordnet, nachdem die Datensätze während des Vorgangs neu an freiem Speicherplatz auf den Seiten angeordnet wurden. In Kombination mit der Speicherschemaarchitektur führte diese zufällige Neuanordnung bei jeder Abfrage eines Datensatzes (z. B. beim Herunterladen von Elementen in einem Ordner) immer zu einem zufälligen E/A-Vorgang. In Exchange Server 2010 werden zufällige E/A-Vorgänge reduziert, da Datensätze auf den Seiten in logischer Reihenfolge angeordnet werden.

In früheren Versionen von Exchange Server wurden Vorgänge zur Datenbankkomprimierung während des Onlinewartungsfensters ausgeführt. In Exchange 2010 ist die Datenbankkomprimierung jetzt ein Hintergrundprozess, der fortlaufend ausgeführt wird.

Datenbankdefragmentierung

Die Datenbankdefragmentierung (auch als OLD v2 und B+ Tree-Defragmentierung bezeichnet) ist ein neuer Wartungstask in Exchange Server 2010. Die Datenbankdefragmentierung ist wichtig für die langfristig effiziente Nutzung der Datenträgerressource (z. B. sequenzielle statt zufällige E/A-Vorgänge) und für eine Beibehaltung der Kompaktheit von Tabellen, die als sequenziell markiert sind.

Die Datenbankdefragmentierung ist ein Hintergrundprozess, bei dem die Datenbank fortlaufend analysiert wird, während Vorgänge ausgeführt werden. Bei Bedarf wird eine asynchrone Arbeit ausgelöst. Im Prozess werden alle Tabellen auf freie Seiten überwacht. Wenn eine Tabelle einen Schwellenwert erreicht, ab dem ein hoher Prozentsatz der B+ Tree-Gesamtseitenzahl freigegeben wird, werden die freigegebenen Seiten zum Stamm zurückgegeben. Durch diesen Vorgang wird auch die Kontiguität in einem Tabellensatz mit sequenziellen Speicherplatzhinweisen beibehalten (eine Tabelle, die mit einem bekannten sequenziellen Nutzungsmuster erstellt wurde). Wenn eine Datenbankdefragmentierung ein Scan/Preread in einer sequenziellen Tabelle erkennt und die Datensätze nicht in sequenziellen Seiten innerhalb der Tabelle gespeichert sind, wird während des Vorgangs dieser Bereich der Tabelle defragmentiert, indem alle betroffenen Seiten in neuem Umfang in B+ Tree verschoben werden. Sie können mit Leistungsindikatoren das niedrige Niveau der Aktivität durch die Datenbankdefragmentierung bei Erreichen eines stabilen Zustands anzeigen.

Die Datenbankdefragmentierung verfügt über die folgenden Steuermöglichkeiten, um die Ausführung von Tasks zu regulieren:

• Maximale Anzahl von nicht erledigten Tasks   Damit wird vermieden, dass die Datenbankdefragmentierung während des ersten Durchgangs eine zu hohe Aktivität aufweist, wenn eine umfassende Änderung an der Datenbank vorgenommen wurde.

  Einschränkung der Latenzzeit um 100 ms   Wenn das System überlastet ist, verzögert die Datenbankdefragmentierung die Defragmentierung. Die verzögerte Verarbeitung wird abgeschlossen, wenn die Datenbank das nächste Mal das gleiche Vorgangsmuster ausführt und das System über ausreichend Ressourcen verfügt.

Onlineüberprüfung von Datenbanken (Datenbankprüfsumme)

Bei der Onlineüberprüfung von Datenbanken (auch als Datenbankprüfsumme bezeichnet) wird die Datenbank in großen Abschnitten gelesen, und jede Seite wird auf physische Beschädigungen überprüft. Der Hauptzweck der Erstellung einer Datenbankprüfsumme ist die Erkennung physischer Beschädigungen und verlorener Leerungen, die durch transaktionale Vorgänge nicht erkannt werden (veraltete Seiten).

In Exchange 2010 wird bei der Onlinedatenbanküberprüfung eine Prüfsumme für die Datenbank gebildet, und es werden Vorgänge nach einem Absturz des Exchange 2010-Informationsspeichers ausgeführt. Durch Abstürze kann es zu einem Verlust an Speicherplatz kommen. Bei der Onlinedatenbanküberprüfung wird der verlorene Speicherplatz erkannt und wiederhergestellt. Für das System in Exchange 2010 wird davon ausgegangen, dass sämtliche Datenbanken alle sieben Tage vollständig überprüft werden. Wenn eine Datenbank innerhalb dieses Zeitraums nicht vollständig überprüft wurde, wird ein Warnereignis ausgelöst. In Exchange 2010 sind nun zwei Modi zum Ausführen von Onlinedatenbanküberprüfungen für aktive Datenbankkopien verfügbar:

• Ausführung als letzter Task im geplanten Prozess zur Postfachdatenbankwartung: Sie können die Ausführungsdauer konfigurieren, indem Sie den Zeitplan für die Postfachdatenbankwartung ändern. Sie können diese Option für kleinere Datenbanken mit weniger als 1 Terabyte (TB) nutzen, die innerhalb eines kleineren Zeitraums vollständig überprüft werden können.

• Ausführung als Standardverhalten 24 Stunden am Tag, sieben Tage die Woche im Hintergrund: Diese Möglichkeit ist ideal für alle Datenbankgrößen geeignet, sie wird jedoch für größere Datenbanken (1-2 TB) empfohlen. Exchange überprüft die Datenbank nicht mehr als einmal pro Tag. Dieser E/A-Lesevorgang wird vollständig sequenziell ausgeführt, sodass die Arbeitslast für den Datenträger gering ist. Auf den meisten Systemen wird eine Leserate von ca. 5 MB/s erreicht.

Seitenpatching

Beim Seitenpatching werden beschädigte Seiten durch fehlerfreie Kopien ersetzt. Die Erkennung beschädigter Seiten ist eine Funktion bei der Erstellung von Datenbankprüfsummen. Außerdem werden beschädigte Seiten während der Laufzeit erkannt, wenn die Seite im Datenbankcache gespeichert wird. Das Seitenpatching funktioniert auch bei Datenbankkopien mit hoher Verfügbarkeit. Wie eine beschädigte Seite repariert wird, hängt davon ab, ob die Datenbankkopien mit hoher Verfügbarkeit aktiv oder passiv sind.

Seitenpatching bei aktiven Datenbankkopien

• Mindestens eine beschädigte Seite wird erkannt.

• In die aktive Protokolldatei wird ein Marker geschrieben. Dieser Marker weist auf die beschädigte Seitenzahl hin. Er weist auch darauf hin, dass die Seite ersetzt werden muss.

• Zur Anfragenliste für das Seitenpatching wird ein Eintrag hinzugefügt.

• Die aktive Protokolldatei wird geschlossen.

• Der Replikationsdienst sendet die Protokolldatei an die passiven Datenbankkopien.

• Der Replikationsdienst auf einem Zielpostfachserver empfängt die gesendete Protokolldatei und prüft sie.

• Der Informationsspeicher auf dem Zielserver gibt die Protokolldatei bis zum Marker wieder, ruft die fehlerfreie Version der Seite ab, ruft den Rückruf für den Wiedergabedienst auf und verschiebt dann die Seite auf den Quellpostfachserver.

• Der Quellpostfachserver erhält die fehlerfreie Version der Seite, bestätigt das Vorhandensein des Eintrags in der Anfragenliste für das Seitenpatching und schreibt die Seite dann in den Protokollpuffer. Dementsprechend wird die Seite in den Datenbankcache eingefügt.

• Der entsprechende Eintrag in der Anfragenliste für das Seitenpatching wird entfernt.

• Ab diesem Zeitpunkt gilt die Datenbank als gepacht. (Zu einem späteren Zeitpunkt schreitet der Prüfpunkt voran, der Datenbankcache wird geleert und die beschädigte Seite wird auf dem Laufwerk überschrieben.)

• Alle anderen Kopien dieser Seite (die von einer anderen passiven Kopie empfangen wurden) werden automatisch gelöscht. Dies geschieht, weil kein entsprechender Eintrag in der Anfragenliste für das Seitenpatching vorhanden ist.

Seitenpatching bei passiven Datenbankkopien

• Auf dem Postfachserver, auf dem die beschädigten Seiten erkannt wurden, wird die Protokollwiedergabe für die betroffene Datenbankkopie angehalten.

• Der Replikationsdienst wird mit dem Postfachserver, auf dem die aktive Datenbankkopie gehostet wird, koordiniert, und er empfängt die beschädigten Seiten und den erforderlichen Protokollbereich vom Datenbankheader der aktiven Kopie.

• Der Postfachserver aktualisiert den Datenbankheader der betroffenen Datenbankkopie und fügt dann den neuen erforderlichen Protokollbereich ein.

• Der Postfachserver benachrichtigt den Postfachserver, auf dem die aktive Datenbankkopie gehostet wird, darüber, welche Protokolldateien erforderlich sind.

• Der Postfachserver empfängt die erforderlichen Protokolldateien und prüft sie.

• Der Postfachserver fügt die fehlerfreien Versionen der Datenbankseiten, die er von der aktiven Datenbankkopie erhalten hat, hinzu. Die Seiten werden in den Protokollpuffer geschrieben. Dementsprechend wird die Seite in den Datenbankcache eingefügt.

• Der Postfachserver setzt die Protokollwiedergabe fort.

Unwiderrufliches Löschen

Das unwiderrufliche Löschen von Datenbankseiten ist eine Sicherheitsmaßnahme, bei der gelöschte Seiten in der Datenbank mit einem Muster überschrieben (unwiderruflich gelöscht) werden. Dadurch wird eine Ermittlung der Daten erheblich erschwert.

In Exchange Server 2007 und früheren Versionen wurde das unwiderrufliche Löschen während der Streamingsicherung durchgeführt. Weil das unwiderrufliche Löschen während der Streamingsicherung erfolgt, werden keine Protokolldateien generiert. Dadurch entsteht ein Problem bei replizierten Datenbanken, weil bei passiven Kopien die Seiten nie unwiderruflich gelöscht werden. Die Seiten aktiver Kopien werden nach Abschluss der Streamingsicherung unwiderruflich gelöscht. In Exchange Server 2007 SP1 wurde ein neuer optionaler Wartungstask eingeführt, um das Problem zu beheben: Unwiderrufliches Löschen von Datenbankseiten während der Prüfsummenerstellung. Wenn das unwiderrufliche Löschen von Datenbankseiten während der Prüfsummenerstellung aktiviert wurde, werden die Seiten während der Onlinewartung unwiderruflich gelöscht und die Änderungen protokolliert. Die Änderungen werden dann auf die passiven Kopien repliziert.

In der Exchange Server 2007 SP1-Implementierung wird das unwiderrufliche Löschen jedoch in einem geplanten Wartungsfenster ausgeführt. Dadurch wird eine Verzögerung zwischen der Uhrzeit, zu der eine Seite gelöscht wird, und der Uhrzeit, zu der eine Seite unwiderruflich gelöscht wird, verursacht. Deshalb wird das unwiderrufliche Löschen von Seiten zu einem Laufzeitereignis, das in Exchange Server 2010 SP1 fortlaufend ausgeführt wird. Normalerweise werden dabei Seiten unwiderruflich zur Transaktionszeit gelöscht, wenn ein endgültiger Löschvorgang ausgeführt wird.

Darüber hinaus können Datenbankseiten während der Online-Prüfsummenerstellung entfernt werden. Zu den betroffenen Seiten zählen in diesem Fall folgende:

• Gelöschte Datensätze können aufgrund gelöschter Tasks (bei einem überlasteten System) oder eines Ausfalls des Speichers, bevor die Daten durch die Tasks entfernt wurden, nicht zur Laufzeit entfernt werden.

• Gelöschte Tabellen und sekundäre Indizes. Wenn diese gelöscht werden, wird der Inhalt nicht entfernt. Daher erkennt die Onlineprüfsumme, dass die Seiten nicht mehr zu einem gültigen Objekt gehören, und entfernt sie.

Weitere Informationen zum unwiderruflichen Löschen in Exchange 2010 finden Sie unter Grundlegendes zum unwiderruflichen Löschen von Datenbankseiten in Exchange 2010.

Verwenden von Leistungsindikatoren zum Nachverfolgen der Hintergrundwartungstasks

In Exchange Server 2010 werden Ereignisse nicht für Defragmentierungs- und Komprimierungswartungstasks erfasst. Sie können jedoch Leistungsindikatoren verwenden, um die Hintergrundwartungstasks zu verfolgen. In der folgenden Tabelle werden die Leistungsindikatoren erläutert, die im Objekt MSExchange-Datenbank ==> Instanzen verwendet werden können.

In der folgenden Tabelle werden die Indikatoren für das unwiderrufliche Löschen erläutert, die im Objekt MSExchange-Datenbank verwendet werden können:

Leere Seiten

In einer Datenbank können Tausende von Tabellen vorhanden sein. Es kann mindestens eine Tabelle für jeden Ordner im Postfach vorhanden sein. Tabellen für Meldungen, Ordner und Anlagen beanspruchen 90 Prozent des Speicherplatzes in Datenbanken. Diese Tabellen verfügen über den größten Prozentsatz freien Speicherplatzes (auch als leere Seiten bezeichnet) in der Datenbank.

Gehen Sie wie folgt vor, um zu bestimmen, wie viele leere Seiten in der Datenbank vorhanden sind, und um sie wieder zu nutzen:

1. Heben Sie die Einbindung der Datenbank auf.

2. Erstellen Sie mithilfe des Eseutil-Tools (Exchange Server Database Utilities) mit der Option /MS ein Speicherabbild. Weitere Informationen dazu finden Sie unter Ausführen von "Eseutil /M" im Modus für das Erstellen einer Speicherabbilddatei.

   Am Ende der Dumpdatei wird eine Zeile ähnlich der folgenden angezeigt:

   -----------------------------------------------------------------------
   253

   This is a summation of the total number of pages that are available in all the tables. Multiply this value by 32K to determine the true amount of white space in the database.

Nachdem Sie bestimmt haben, wie viel leere Seiten tatsächlich in einer Datenbank vorhanden sind, können Sie sie freigeben.

Gehen Sie wie folgt vor, wenn Sie feststellen, dass in einer Datenbank viele leere Seiten vorhanden sind, und diese mit den üblichen Vorgängen nicht freigegeben werden können:

1. Erstellen Sie eine neue Datenbank und die zugeordneten Datenbankkopien.

2. Verschieben Sie alle Postfächer in die neue Datenbank.

3. Löschen Sie die ursprüngliche Datenbank und die zugeordneten Datenbankkopien.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.