Datenbankwartung in Exchange 2010
Veröffentlichung des Originalartikels: 14.12.2011
In den letzten Monaten gab es eine Menge Diskussionen darüber, was Hintergrund-Datenbankwartung ist und warum sie für Exchange 2010-Datenbanken wichtig ist. Ich hoffe, diese Fragen werden im vorliegenden Artikel beantwortet.
Welche Wartungsaufgaben müssen für eine Datenbank ausgeführt werden?
Die folgenden Aufgaben müssen regelmäßig für Exchange-Datenbanken ausgeführt werden:
- Datenbankkomprimierung
- Datenbankdefragmentierung
- Datenbank-Prüfsummenbildung
- Patchen von Seiten
- Unwiderrufliches Löschen
Datenbankkomprimierung
Datenbankkomprimierung wird hauptsächlich ausgeführt, um ungenutzten Speicherplatz in der Datenbankdatei freizugeben (Beachten Sie jedoch, dass der ungenutzte Speicherplatz dadurch nicht an das Dateisystem zurückgegeben wird). Das Ziel ist es, Seiten in der Datenbank durch Komprimieren von Datensätzen auf möglichst wenige Seiten freizugeben und so die erforderliche E/A zu reduzieren. Das ESE-Datenbankmodul verwendet dazu die Datenbankmetadaten – die Informationen in der Datenbank, die Tabellen in der Datenbank beschreiben. Für jede Tabelle wird auf jede Seite der Tabelle zugegriffen und versucht, Datensätze auf logisch angeordnete Seiten zu verschieben.
Die Aufrechterhaltung eines niedrigen Speicherbedarfs für die Datenbankdatei ist unter anderem aus folgenden Gründen wichtig:
- Reduzieren des Zeitaufwands für die Sicherung der Datenbankdatei
- Beibehalten einer vorhersagbaren Größe der Datenbankdatei, was für die Bemessung der Server- und Speichergrößen wichtig ist.
Vor Exchange 2010 wurde die Datenbankkomprimierung innerhalb des Onlinewartungsfensters durchgeführt. Bei diesem Vorgang wurde wahlfreie E/A erzeugt, während die Datenbank durchlaufen und Datensätze auf Seiten neu angeordnet wurden. Dieser Vorgang war in früheren Versionen buchstäblich zu gut – durch die Freigabe von Datenbankseiten und die Umsortierung von Datensätzen befanden sich die Seiten immer in einer zufälligen Reihenfolge. Zusammen mit der Architektur des Speicherschemas bedeutete dies, dass jede Anforderung für einen Satz von Daten (wie beim Herunterladen von Elementen in einem Ordner) stets zu wahlfreier E/A führte.
In Exchange 2010 wurde die Datenbankkomprimierung neu gestaltet, sodass nun Kontiguität Vorrang vor der Speicherkomprimierung hat. Außerdem wurde die Datenbankkomprimierung aus dem Onlinewartungsfenster genommen und ist nun ein ständig ausgeführter Hintergrundprozess.
Datenbankdefragmentierung
Datenbankdefragmentierung ist neu in Exchange 2010 und wird auch als OLD v2 und B+-Struktur-Defragmentierung bezeichnet. Sie hat die Aufgabe, als sequenziell gekennzeichnete (oder mit entsprechenden Hinweisen versehene) Datenbanktabellen zu komprimieren und zu defragmentieren (sequenziell anzuordnen). Die Datenbankdefragmentierung ist wichtig, um eine effiziente Nutzung der Datenträgerressourcen über die Zeit hinweg sicherzustellen (die E/A sequenzieller zu machen statt wahlfrei) und um die Kompaktheit von als sequenziell gekennzeichneten Tabellen zu wahren.
Sie können sich die Datenbankdefragmentierung als Monitor vorstellen, der andere Vorgänge auf Datenbankseiten daraufhin überwacht, ob es etwas zu tun gibt. Er überwacht alle Tabellen auf freie Seiten, und wenn eine Tabelle einen Schwellenwert erreicht, bei dem ein ausreichend hoher Prozentsatz der B+-Struktur-Seiten frei ist, gibt er die freien Seiten zurück an den Stamm. Außerdem versucht er die Kontiguität in einer Tabelle mit Hinweisen auf sequenziellen Speicher (eine Tabelle, die mit einem bekannten sequenziellen Verwendungsmuster erstellt wurde) aufrechtzuerhalten. Wenn die Datenbankdefragmentierung einen Scan-/Preread-Vorgang in einer sequenziellen Tabelle erkennt und die Datensätze nicht auf sequenziellen Seiten in der Tabelle gespeichert sind, wird dieser Abschnitt der Tabelle defragmentiert, indem alle betroffenen Seiten in eine neue Erweiterung in der B+-Struktur verschoben werden. Anhand der Leistungsindikatoren (siehe Abschnitt zur Überwachung) können Sie verfolgen, wie wenig die Datenbankdefragmentierung leistet, sobald ein stabiler Zustand erreicht ist.
Die Datenbankdefragmentierung ist ein Hintergrundprozess, der die Datenbank während Vorgängen kontinuierlich analysiert und dann ggf. asynchrone Arbeit auslöst. Die Datenbankdefragmentierung ist in zwei Szenarien gedrosselt:
- Die maximale Anzahl ausstehender Tasks. Dies beschränkt den Aufwand der Datenbankdefragmentierung im ersten Durchlauf, wenn massive Änderungen an der Datenbank vorgenommen wurden.
- Eine Wartezeitdrosselung von 100ms. Wenn das System überlastet ist, beginnt die Datenbankdefragmentierung, Defragmentierungsarbeit zu verschieben. Die verschobene Arbeit wird ausgeführt, wenn die Datenbank zum nächsten Mal dasselbe Vorgangsmuster durchläuft. Es wird nicht vermerkt, welche Defragmentierungsarbeit verschoben wurde, und sie wird nicht ausgeführt, sobald das System wieder über mehr Ressourcen verfügt.
Datenbank-Prüfsummenbildung
Datenbank-Prüfsummenbildung (auch als Online-Datenbanküberprüfung bezeichnet) ist der Prozess, bei dem die Datenbank in großen Abschnitten gelesen wird und für jede Seite die Prüfsumme berechnet wird (Prüfung auf physikalische Seitenbeschädigung). Der Hauptzweck der Prüfsummenbildung besteht darin, physikalische Beschädigungen und verlorene Leerungen zu erkennen, die möglicherweise bei Transaktionsvorgängen nicht erkannt werden (veraltete Seiten).
In Exchange 2007 RTM und allen früheren Versionen fanden Prüfsummenvorgänge während der Sicherung statt. Dies stellte ein Problem für replizierte Datenbanken dar, da die einzige Kopie, für die eine Prüfsumme gebildet wurde, die gesicherte Kopie war. Für das Szenario, in dem die passive Kopie gesichert wurde, bedeutete dies, dass für die aktive Kopie keine Prüfsumme gebildet wurde. Daher haben wir in Exchange 2007 SP1 einen neuen optionalen Onlinewartungstask, die Prüfsummenbildung bei der Onlinewartung, eingeführt (weitere Informationen finden Sie unter Exchange 2007 SP1 ESE Changes – Part 2).
In Exchange 2010 wird bei der Datenbanküberprüfung die Prüfsumme der Datenbank gebildet, und es werden Vorgänge nach einem Speicherabsturz in Exchange 2010 ausgeführt. Durch Systemabstürze können Speicherlecks entstehen, und bei der Online-Datenbanküberprüfung wird verlorener Speicherplatz gefunden und wiederhergestellt. Die Datenbank-Prüfsummenbildung liest ca. 5 MB pro Sekunde für jede aktiv überprüfende Datenbank (sowohl aktive als auch passive Kopien), wobei 256KB-E/As verwendet werden. Die E/A-Vorgänge erfolgen zu 100 Prozent sequenziell. Das System in Exchange 2010 wurde mit der Erwartung entworfen, dass jede Datenbank alle sieben Tage vollständig überprüft wird.
Wenn die Überprüfung länger als sieben Tage dauert, wird ein Ereignis im Anwendungsprotokoll verzeichnet:
Ereignis-ID: 733
Ereignistyp: Information
Ereignisquelle: ESE
Beschreibung: Informationsspeicher (15964) MDB01: Der Hintergrundtask der Onlinewartung für Datenbank-Prüfsummenbildung wurde NICHT rechtzeitig für Datenbank 'd:\mdb\mdb01.edb' abgeschlossen. Der Durchlauf begann am 10.11.2011 und wurde bis jetzt 604800 Sekunden (mehr als 7 Tage) ausgeführt.
Wenn die Überprüfung der aktiven Datenbankkopie länger als sieben Tage dauert, wird nach Abschluss der Überprüfung der folgende Eintrag im Anwendungsprotokoll verzeichnet:
Ereignis-ID: 735
Ereignistyp: Information
Ereignisquelle: ESE
Beschreibung: Informationsspeicher (15964) MDB01: Die Datenbankwartung hat einen vollständigen Durchlauf für die Datenbank 'd:\mdb\mdb01.edb' abgeschlossen. Der Durchlauf wurde am 10.11.2011 gestartet und dauerte insgesamt 777600 Sekunden. Dieser Datenbankwartungstask überschritt die maximale Dauer von Wartungstasks von 7 Tagen. Eine oder mehrere der folgenden Aktionen sollten durchgeführt werden: Erhöhen der E/A-Leistung bzw. des Durchsatzes des Volumes, das die Datenbank hostet, Reduzieren der Datenbankgröße und/oder Reduzieren von nicht auf die Datenbankwartung bezogener E/A.
Zudem wird eine Warnung über einen im Gange befindlichen Vorgang im Anwendungsprotokoll verzeichnet, wenn die Dauer von sieben Tagen überschritten wird.
In Exchange 2010 gibt es nun zwei Modi der Datenbank-Prüfsummenbildung für aktive Datenbankkopien:
- Ausführung im Hintergrund rund um die Uhr: Dies ist das Standardverhalten. Es sollte für alle Datenbanken verwendet werden, besonders für solche, die größer sind als 1 Terabyte (TB). Exchange überprüft die Datenbank maximal einmal täglich. 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. Der Überprüfungsprozess wird in einem einzelnen Thread ausgeführt und durch die E/A-Wartezeit gedrosselt. Je länger die Wartezeit, desto langsamer wird die Datenbank-Prüfsummenbildung, da sie länger auf den Abschluss des letzten Batches warten muss, bevor sie eine weitere Batchüberprüfung von Seiten anstößt (es werden jeweils 8 Seiten gleichzeitig gelesen).
- Ausführung im geplanten Prozess zur Postfachdatenbankwartung: Bei dieser Option ist die Datenbank-Prüfsummenbildung der letzte Task. Sie können die Ausführungsdauer konfigurieren, indem Sie den Wartungszeitplan für die Postfachdatenbank ändern. Diese Option sollte nur für Datenbanken mit weniger als 1 TB verwendet werden, die innerhalb eines kleineren Zeitraums vollständig überprüft werden können.
Unabhängig von der Datenbankgröße sollten Sie das Standardverhalten nutzen und die Datenbank-Prüfsummenvorgänge für die aktive Datenbank nicht als geplanten Prozess konfigurieren (d. h., konfigurieren Sie sie nicht als Prozess innerhalb des Onlinewartungsfensters).
Für passive Datenbankkopien werden Datenbank-Prüfsummen während der Laufzeit kontinuierlich im Hintergrund gebildet.
Patchen von Seiten
Als Patchen von Seiten wird der Prozess bezeichnet, bei dem beschädigte Seiten durch fehlerfreie Kopien ersetzt werden. Wie erwähnt ist die Erkennung beschädigter Seiten eine Funktion der Datenbank-Prüfsummenbildung (zudem werden beschädigte Seiten zur Laufzeit entdeckt, wenn die Seite im Datenbankcache gespeichert wird). Das Patchen von Seiten erfolgt für hoch verfügbare Datenbankkopien. Wie eine beschädigte Seite repariert wird, hängt davon ab, ob die hoch verfügbare Datenbankkopie aktiv oder passiv ist.
Seitenpatchprozess
| Für aktive Datenbankkopien | Für passive Datenbankkopien |
|
|
Unwiderrufliches Löschen
Das unwiderrufliche Löschen von Datenbankseiten ist der Prozess, bei dem gelöschte Seiten in der Datenbank als Sicherheitsmaßnahme mit einem Muster überschrieben (auf Null gesetzt, genullt) werden, wodurch die Wiederherstellung der Daten wesentlich erschwert wird.
In Exchange 2007 RTM und allen früheren Versionen fanden unwiderrufliche Löschvorgänge während der Streamingsicherung statt. Daher wurden sie nicht protokolliert (d. h., das unwiderrufliche Löschen führte nicht zur Generierung von Protokolldateien). Dies stellte ein Problem für replizierte Datenbanken dar, da die Seiten der passiven Kopien nie auf Null gesetzt wurden und die Seiten der aktiven Kopien nur dann auf Null gesetzt wurden, wenn Sie eine Streamingsicherung durchgeführt haben. Daher haben wir in Exchange 2007 SP1 einen neuen optionalen Onlinewartungstask, die unwiderrufliche Löschung von Datenbankseiten bei der Prüfsummenbildung (Zero Database Pages during Checksum), eingeführt (weitere Informationen finden Sie unter Exchange 2007 SP1 ESE Changes – Part 2). Ist dieser Task aktiviert, werden Seiten im Onlinewartungsfenster genullt und die Änderungen protokolliert, die dann auf die passiven Kopien repliziert werden.
Bei der Implementierung von Exchange 2007 SP1 gibt es eine erhebliche Verzögerung zwischen der Löschung einer Seite und ihrer Nullung, da die Nullung in einem geplanten Wartungsfenster auftritt. In Exchange 2010 SP1 wird der Task der unwiderruflichen Löschung daher zu einem kontinuierlich ausgeführten Laufzeitereignis, bei dem Seiten in der Regel zur Transaktionszeit genullt werden, wenn eine endgültige Löschung auftritt.
Darüber hinaus können Datenbankseiten auch während der Onlineprüfsummenbildung unwiderruflich gelöscht werden. In diesem Fall sind folgende Seiten betroffen:
- Gelöschte Datensätze, die aufgrund gelöschter Tasks (wenn das System überlastet ist) nicht während der Laufzeit genullt werden konnten oder weil der Speicher abgestürzt ist, bevor die Tasks zur Nullung der Daten kamen.
- Gelöschte Tabellen und sekundäre Indizes. Wenn diese gelöscht werden, werden ihre Inhalte nicht aktiv genullt. Daher wird bei der Onlineprüfsummenbildung erkannt, dass diese Seiten zu keinem gültigen Objekt mehr gehören, und sie werden genullt.
Weitere Informationen zur unwiderruflichen Löschung in Exchange 2010 finden Sie unter Grundlegendes zum unwiderruflichen Löschen von Datenbankseiten in Exchange 2010.
Warum werden diese Tasks nicht einfach in einem geplanten Wartungsfenster ausgeführt?
Die Anforderung eines geplanten Wartungsfensters für das unwiderrufliche Löschen von Seiten, die Datenbankdefragmentierung, die Datenbankkomprimierung und die Onlineprüfsummenbildung zieht u. a. folgende Probleme nach sich:
- Geplante Wartungsvorgänge erschweren die Verwaltung von 24x7-Datencentern, die Postfächer aus verschiedenen Zeitzonen hosten und wenig oder gar keine Zeit für ein geplantes Wartungsfenster haben. Die Datenbankkomprimierung in früheren Versionen von Exchange wies keinen Drosselungsmechanismus auf und kann, da die E/A vorwiegend wahlfrei erfolgt, zu einer unbefriedigenden Benutzererfahrung führen.
- Auf Exchange 2010-Postfachdatenbanken, die auf Speicher niedriger Ebene (z. B. 7.2K SATA/SAS) bereitgestellt werden, steht eine reduzierte effektive E/A-Bandbreite zur Ausführung von Wartungsfenstertasks durch ESE verfügbar. Dies ist problematisch, da die E/A-Wartezeiten während des Wartungsfensters zunehmen und so den Abschluss der Wartungsaktivitäten im gewünschten Zeitraum verhindern.
- Die Verwendung von JBOD stellt bezüglich der Datenüberprüfung eine weitere Herausforderung für die Datenbank dar. Bei RAID-Speicher überprüft in der Regel ein Arraycontroller im Hintergrund eine bestimmte Datenträgergruppe, indem beschädigte Sektoren gesucht und erneut zugewiesen werden. Ein beschädigter Sektor ist ein Sektor oder Block auf einem Datenträger, der aufgrund einer dauerhaften Beschädigung (z. B. physikalische Beschädigung der Datenträgerpartikel) nicht verwendet werden kann. Arraycontroller lesen zudem gewöhnlich den alternativen gespiegelten Datenträger, wenn bei der ursprünglichen Leseanforderung ein beschädigter Sektor erkannt wurde. Anschließend markiert der Arraycontroller den beschädigten Sektor als "beschädigt" und schreibt die Daten in einen neuen Sektor. Das alles erfolgt ohne Wissen der Anwendung, vielleicht mit einer leicht verlängerten Wartezeit beim Lesen des Datenträgers. Ohne RAID oder einen Arraycontroller sind diese Methoden zur Erkennung und Behebung fehlerhafter Sektoren nicht verfügbar. Ohne RAID ist es die Aufgabe der Anwendung (ESE), fehlerhafte Sektoren zu erkennen und zu beheben (d. h. Datenbank-Prüfsummenbildung).
- Größere Datenbanken auf größeren Datenträgern erfordern längere Wartungsintervalle, um die sequenzielle Anordnung und Kompaktheit aufrechtzuerhalten.
Aufgrund der genannten Probleme war es in Exchange 2010 wichtig, dass die Datenbankwartungstasks aus einem geplanten Prozess herausgenommen und während der Laufzeit kontinuierlich im Hintergrund ausgeführt werden.
Haben diese Hintergrundtasks Auswirkungen für die Endbenutzer?
Wir haben diese Hintergrundtasks so entworfen, dass sie automatisch entsprechend der Aktivität auf der Datenbank gedrosselt werden. Zudem werden diese Wartungstasks in unseren Anleitungen zur Größenanpassung basierend auf Nachrichtenprofilen berücksichtigt. Sie müssen jedoch beim Entwurf der Speicherarchitektur sorgsam vorgehen. Wenn Sie mehrere Datenbanken auf derselben LUN oder demselben Volume speichern möchten, müssen Sie sicherstellen, dass die Gesamtgröße aller Datenbanken 2 TB nicht überschreitet. Der Grund ist, dass die Datenbankwartung durch die Serialisierung basierend auf der Anzahl der Datenbanken pro Volume gedrosselt ist und vorausgesetzt wird, dass die Gesamtgröße 2 TB nicht übersteigt.
Wie kann ich die Effektivität dieser Hintergrundwartungstasks überwachen?
In früheren Versionen von Exchange wurden die Ereignisse im Anwendungsprotokoll verwendet, um Dinge wie die Onlinedefragmentierung zu überwachen. In Exchange 2010 werden keine Ereignisse für die Defragmentierungs- und Komprimierungswartungstasks mehr verzeichnet. Sie können die Hintergrundwartungstasks jedoch mithilfe von Leistungsindikatoren unter dem Objekt MSExchange-Datenbank ==> Instanzen nachverfolgen:
| Leistungsindikator | Beschreibung |
| Datenbankwartung: Dauer seit letzter | Die Anzahl von Stunden seit Abschluss der letzten Wartung dieser Datenbank |
| Datenbankwartung: Seiten mit fehlerhaften Prüfsummen | Die Anzahl der in einem Datenbankwartungsdurchlauf gefundenen nicht korrigierbaren Seitenprüfsummen |
| Defragmentierungstasks | Die Anzahl der derzeit ausgeführten Hintergrundtasks der Datenbankdefragmentierung |
| Defragmentierungstasks Abgeschlossene/Sek. | Die Rate der abgeschlossenen Hintergrundtasks der Datenbankdefragmentierung |
Die folgenden Leistungsindikatoren zum unwiderruflichen Löschen von Seiten finden Sie unter dem Objekt MSExchange-Datenbank:
| Leistungsindikator | Beschreibung |
| Datenbankwartung: Gelöschte Seiten | Die Anzahl der Seiten, die vom Datenbankmodul seit dem Aufruf des Leistungsindikators unwiderruflich gelöscht wurden. |
| Datenbankwartung: Gelöschte Seiten/Sek. | Die Rate, mit der Seiten vom Datenbankmodul unwiderruflich gelöscht werden. |
Wie kann ich Leerraum in einer Datenbank bestimmen?
Sie können die Shell verwenden, um nach verfügbarem Leerraum in einer Datenbank zu suchen. Für Postfachdatenbanken verwenden Sie folgenden Befehl:
Get-MailboxDatabase MDB1 –Status | FL AvailableNewMailboxSpace
Für Öffentliche Ordner-Datenbanken verwenden Sie:
Get-PublicFolderDatabase PFDB1 –Status | FL AvailableNewMailboxSpace
Wie kann ich den Leerraum freigeben?
Nach dem Ermitteln des verfügbaren Leerraums in der Datenbank stellt sich natürlich immer die Frage: Wie kann ich den Leerraum freigeben?
Viele glauben, die Antwort wäre die Ausführung einer Offlinedefragmentierung der Datenbank mit ESEUTIL. Dies wird jedoch nicht empfohlen. Wenn Sie eine Offlinedefragmentierung ausführen, erstellen Sie eine völlig neue Datenbank, und die dabei ausgeführten Vorgänge werden nicht in Transaktionsprotokollen verzeichnet. Die neue Datenbank weist zudem eine neue Datenbanksignatur auf, was bedeutet, dass die zugehörigen Datenbankkopien ungültig werden.
Falls tatsächlich eine Datenbank erheblichen Leerraum aufweist und Sie nicht erwarten, dass dieser durch normale Vorgänge freigegeben wird, empfehlen wir Folgendes:
- Erstellen Sie eine neue Datenbank mit zugehörigen Datenbankkopien.
- Verschieben Sie alle Postfächer in die neue Datenbank.
- Löschen Sie die ursprüngliche Datenbank und die zugehörigen Datenbankkopien.
Terminologische Verwirrung
Der Begriff Hintergrund-Datenbankwartung stiftet Verwirrung. Alle erwähnten Tasks bilden gemeinsam die Hintergrund-Datenbankwartung. In der Shell, der Exchange-Verwaltungskonsole (EMC) und JetStress wird jedoch die Datenbank-Prüfsummenbildung als Hintergrund-Datenbankwartung (background database maintenance) bezeichnet, und diese konfigurieren Sie, wenn Sie sie mit diesen Tools aktivieren oder deaktivieren.
Abbildung 1: Aktivieren der Hintergrund-Datenbankwartung für eine Datenbank mit der Exchange-Verwaltungskonsole (EMC)
Aktivieren der Hintergrund-Datenbankwartung mit der Shell:
Set-MailboxDatabase –Identity MDB1 –BackgroundDatabaseMaintenance $true
Abbildung 2: Ausführen der Hintergrund-Datenbankwartung im Rahmen eines JetStress-Tests
Der Speicherhersteller empfiehlt, die Datenbank-Prüfsummenbildung als Hintergrundwartungstask zu deaktivieren. Was soll ich tun?
Die Datenbank-Prüfsummenbildung kann die E/A-Last erhöhen, wenn der Speicher nicht richtig bemessen ist (auch wenn er sequenziell ist). Es werden immerhin 256 K E/A-Lesevorgänge ausgeführt und ca. 5 MB/Sek. pro Datenbank generiert.
Im Rahmen unserer Anleitung zur Speicherkonfiguration empfehlen wir, die Speicherarray-Stripesetgröße (die Größe der auf jeden Datenträger in einem Array geschriebenen Stripesets; auch als Blockgröße bezeichnet) mit 256 KB oder mehr zu wählen.
Es ist wichtig, Speicher mit JetStress zu testen und sicherzustellen, dass der letzte Testdurchlauf die Datenbankprüfsummenbildung enthält.
Wenn eine JetStress-Ausführung aufgrund der Datenbankprüfsummenbildung fehlschlägt, haben Sie verschiedene Möglichkeiten:
Verwenden Sie keine Stripesets Verwenden Sie RAID-1-Paare oder JBOD (was Änderungen der Architektur bedingen kann), und ziehen Sie den größten Nutzen aus den in Exchange 2010 verfügbaren sequenziellen E/A-Mustern.
Verwenden Sie einen Zeitplan Konfigurieren Sie die Datenbank-Prüfsummenbildung nicht als Hintergrundprozess, sondern als geplanten Prozess. Bei der Implementierung der Datenbankprüfsumme als Hintergrundprozess haben wir damit gerechnet, dass einige Speicherarrays so für wahlfreien Zugriff optimiert sind (oder Bandbreitenbeschränkungen aufweisen), dass sie bei sequenziellen E/A-Lesevorgängen keine gute Leistung erzielen. Deshalb haben wir vorgesehen, dass sie deaktiviert werden kann (wodurch die Prüfsummenbildung in das Wartungsfenster verschoben wird).
In diesem Fall empfehlen wir kleinere Datenbankgrößen. Beachten Sie auch, dass die Datenbank-Prüfsummenbildung der passiven Kopien weiterhin als Hintergrundprozess ausgeführt wird. Sie müssen also diesen Durchsatz weiterhin in der Speicherarchitektur berücksichtigen. Weitere Informationen dazu finden Sie unter Jetstress 2010 and Background Database Maintenance.
Verwenden Sie anderen Speicher, oder verbessern Sie die Speicherkapazität Wählen Sie Speicher, der in der Lage ist, die bewährten Methoden für Exchange zu erfüllen (256 KB+ Stripesetgröße).
Schlussfolgerung
Durch die Architekturänderungen des Datenbankmoduls in Exchange Server 2010 wurden Leistung und Robustheit erheblich verbessert, aber auch das Verhalten der Datenbankwartungstasks gegenüber früheren Versionen verändert. Wir hoffen, dieser Artikel trägt zum besseren Verständnis der Hintergrund-Datenbankwartung in Exchange 2010 bei.
Ross Smith IV
Principal Program Manager
Exchange Customer Experience
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Database Maintenance in Exchange 2010.