Grundlegendes zum Postfachdatenbankcache

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

Letztes Änderungsdatum des Themas: 2016-11-28

Das ESE-Modul (Extensible Storage Engine) verwendet den Datenbankcache, um die Anzahl von E/A-Vorgängen zu reduzieren. Im Allgemeinen wird umso weniger E/A auf einem Postfachserver von Microsoft Exchange Server 2010 generiert, je umfangreicher der verfügbare Datenbankcache ist. Die Reduzierung der Datenbank-E/A hängt vor allem von dem auf dem Server verfügbaren Datenbankcache und dem Benutzernachrichtenprofil ab.

Verbesserte Effektivität des Datenbankcache

Die Effektivität des Datenbankcache hat sich in Exchange 2010 aufgrund mehrerer technischer Änderungen verbessert. Eine der wichtigsten Änderungen ist die Erhöhung der idealen Protokollprüfpunkttiefe. Die Protokollprüfpunkttiefe stellt sicher, dass Änderungen am Protokoll-/Datenbankcache innerhalb eines angemessenen Zeitraums in die Datenbankdatei geschrieben werden. Die Prüfpunkttiefe wurde von 20 MB pro Datenbank auf 100 MB pro Datenbank erhöht, wenn eine Datenbank über mehr als eine Kopie verfügt (in einer Database Availability Group, DAG). Die folgende Tabelle enthält Standardwerte für ideale Protokollprüfpunkttiefen für Exchange 2010.

Standardkonfiguration für die ideale Protokollprüfpunkttiefe pro Postfachdatenbank

Aufgrund dieser Änderung können die E/A-Schreibvorgänge für eine aktive Datenbank mit mindestens zwei Kopien bis zu 40 % geringer sein als die E/A-Schreibvorgänge für eine eigenständige Datenbank. Wenn die Zielprüfpunkttiefe für die Datenbank höher ist, können Dateiänderungen für diese Datenbank länger im Arbeitsspeicher aufbewahrt werden. So können E/A-Vorgänge besser kombiniert (zusammengefügt) werden, und die Anzahl von wiederholten E/A-Vorgängen kann reduziert werden (d. h. E/A-Vorgänge können gespart werden, indem der Schreibvorgang so lange verzögert wird, dass mehrere Datenbankänderungen im Arbeitsspeicher durchgeführt werden, bevor die Änderung in die Datenbankdatei geschrieben wird).

Diese Änderung wurde ausschließlich für Lösungen für die Ausfallsicherheit von Postfächern vorgenommen, da eine höhere Zielprüfpunkttiefe die Wiederherstellungszeit einer ausgefallenen Datenbank mithilfe der aktiven Datenbank deutlich erhöhen kann. Dieses Problem wurde in Konfigurationen für die Ausfallsicherheit von Postfächern berücksichtigt, da bei einem Ausfall der aktiven Datenbank automatisch ein Failover zu einer anderen, fehlerfreien Kopie ausgelöst wird. Protokollwiedergabevorgänge werden fortgesetzt, nachdem die fehlerhafte Datenbank wiederhergestellt wurde.

Die Zielprüfpunkttiefe wurde daraufhin für passive Datenbankkopien gesenkt, um die Zeitdauer für einen Datenbankswitchover oder ein Datenbankfailover zu reduzieren. Eine passive Datenbankkopie, für die die Zielprüfpunkttiefe 5 MB beträgt, kann viel schneller aktiviert werden als eine Kopie mit einer höheren Zielprüfpunkttiefe (beim Übergang vom passiven zum aktiven Zustand müssen weniger Protokolle wiedergegeben werden). Eine passive Datenbankkopie weist keine transaktionelle E/A auf, sodass Kapazitäten verfügbar sind, um die zusätzlichen E/A-Schreibvorgänge mit der geringeren Zielprüfpunkttiefe zu verarbeiten.

Mindestanforderungen an den Datenbankcache

Damit die ESE-Datenbank sicher über genug Arbeitsspeicher für den effektiven Betrieb verfügt, ist ein bestimmtes Minimum an physikalischem Arbeitsspeicher pro Server abhängig von der Anzahl der Datenbanken erforderlich. Diese Anforderungen gelten für aktive und passive Datenbankkopien. In der folgenden Tabelle sind die Anforderungen aufgelistet.

Erforderlicher minimaler Arbeitsspeicher pro Postfachserver

Metriken für den Datenbankcache

In früheren Exchange-Versionen war eine der wichtigsten Kennzahlen für die Bestimmung der Speichergröße die Anzahl von E/A-Datenbankvorgängen pro Sekunde (IOPS) für jeden Benutzer. Die beiden wichtigsten Faktoren, die zum Vorhersagen der Exchange 2010-Postfach-IOPS verwendet werden können, sind die Größe des Datenbankcache pro Benutzer und die Anzahl von Nachrichten, die jeder Benutzer pro Tag sendet und empfängt.

In der folgenden Tabelle finden Sie Schätzwerte für die IOPS pro Postfach basierend auf Nachrichtenaktivität und Datenbankcache. Anhand der Informationen in der Tabelle können Sie Ihre Basisanforderungen an die E/A-Vorgänge für Exchange 2010-Postfächer vorhersagen.

Diese Schätzungen gelten nur für Datenbankcachegrößen zwischen 3 MB und 30 MB pro Postfach. Diese Schätzungen wurden für Benutzer mit den folgenden Merkmalen überprüft: Hoher Prozentsatz an Exchange-Clients im Cachemodus, entweder in Microsoft OfficeOutlook 2007 oder Outlook 2010; 2-GB-Postfächer und hohe prozentuale Exchange ActiveSync-Auslastung. Die für die Schätzungen verwendete durchschnittliche Nachrichtengröße beträgt 75 KB, wobei die Nachrichtengröße nicht den Hauptfaktor für IOPS darstellt. Andere Clienttypen und Verwendungsszenarien führen möglicherweise zu ungenauen Ergebnissen.

Geschätzte IOPS pro Postfach basierend auf Nachrichtaktivität und Postfachdatenbankcache

Nachdem Sie die Größenanforderungen für den Datenbankcache bestimmt haben, müssen Sie die Mindestanforderungen an den Arbeitsspeicher pro Server bestimmen, um sicherzustellen, dass die Größenanforderungen für den Datenbankcache eingehalten werden. Die Größe des Datenbankcache muss bei der Größenbestimmung berücksichtigt werden, um sicherzustellen, dass genug physikalischer Arbeitsspeicher pro Server vorhanden ist, um die Anforderungen der Postfachanzahl für ein bestimmtes Benutzerprofil zu erfüllen.

In der folgenden Tabelle sind die Standardgrößen für den Postfachdatenbankcache für Postfachserver mit einer einzelnen Rolle sowie Server mit mehreren Rollen aufgeführt.

Standardgrößen für den Postfachdatenbankcache

Informationen zum Bestimmen des erforderlichen Arbeitsspeichers für den Server finden Sie unter Entwurfsbeispiel für die Exchange 2010-Postfachserverrolle. Dort erfahren Sie, wie die Postfachserverrolle entworfen wird, um Speicher, Kapazität, E/A und CPU-Leistung zu bestimmen.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.