Vergessen Sie nicht die Wartung der Exchange 2010-Datenbank

Exchange Server 2010 befindet sich noch in der erweiterten Supportphase des Produktlebenszyklus, ist jedoch noch weit verbreitet …

eingesetzt; also muss es gepflegt werden.
Unabhängig davon, ob Sie planen, in den nächsten ein oder zwei Jahren von Exchange 2010 zu migrieren oder nicht, bis zum Ende des erweiterten Supports im Jahr 2020, erfordern die in Ihrem Unternehmen weiterhin vorhandenen Exchange 2010-Server eine Datenbankwartung, die über das hinausgeht, was Exchange Server automatisch tut .
Administratoren, die an Exchange 2010 oder höher arbeiten, sollten die Datenbankwartung aus mehreren Gründen im Auge behalten. Innerhalb einer Exchange-Datenbank Online-Wartungsaufgaben:

  • Bereinigen Sie gelöschte Postfächer und Elemente und löschen Sie die Postfächer und Elemente, die die Aufbewahrungsfrist überschritten haben.
  • Durchsuchen Sie Online-Datenbanken nach beschädigten Datenbankseiten.
  • Defragmentierung für Datenkontiguität, bei der verwandte Datenbankseiten nahe beieinander platziert werden, wo sie durch sequentielle E / A und nicht durch zufällige E / A gelesen werden können.

Die Online-Wartung der Datenbank wird als kontinuierlicher Hintergrundprozess und als Datenbanktransaktionen ausgeführt. Der Exchange 2010-Server führt kontinuierlich Wartungsarbeiten an seinen eigenen Datenbanken durch. Dies bedeutet jedoch nicht, dass Exchange-Administratoren nichts anderes zu tun haben. Es gibt noch einige Exchange 2010-Datenbankwartungsaufgaben, die der Administrator ausführen sollte.

Überwachen Sie Datenbanksicherungen

Die wahrscheinlich naheliegendste Aufgabe für einen Administrator besteht darin, sicherzustellen, dass Exchange 2010-Datenbanksicherungen erfolgreich ausgeführt werden. Backups sind für die Notfallwiederherstellung von entscheidender Bedeutung, aber auch für die Datenbankwartung. Ein Administrator kann die Exchange 2010-Datenbank mit Aufbewahrungseinstellungen für gelöschte Elemente und für gelöschte Postfächer konfigurieren. Administratoren müssen außerdem angeben, ob gelöschte Elemente beibehalten werden sollen, bis mindestens eine Sicherung durchgeführt wurde (Listing 1).
Listing 1. Diese Ausgabe zeigt die Aufbewahrungszeiten in einer Exchange 2010-Datenbank für gelöschte Postfächer und Elemente.
[PS] C: > Get-MailboxDatabase -Identity DB2010 | Wählen Sie MailboxRetention, DeletedItemRetention, Retain *
MailboxRetention: 30.00: 00: 00
DeletedItemRetention: 14.00: 00: 00
RetainDeletedItemsUntilBackup: True
In der in Listing 1 gezeigten Ausgabe speichert die Datenbank gelöschte Postfächer 30 Tage lang und gelöschte Elemente 14 Tage lang. Sowohl Postfächer als auch Elemente bleiben erhalten, bis eine Sicherung ausgeführt wurde. Wenn Sicherungen fehlschlagen, kann der Hintergrundwartungsprozess der Exchange 2010-Datenbank keine Elemente oder Postfächer löschen. Diese Situation führt dazu, dass die Datenbank größer wird als für die Organisation erforderlich.
Sie können überprüfen, ob Sicherungen für eine Datenbank erfolgreich abgeschlossen wurden, indem Sie das ausführen Get-MailboxDatabase Cmdlet (Listing 2).
Listing 2. Die Get-MailboxDatabase Das Cmdlet zeigt an, ob die Sicherungen für die Exchange-Datenbankwartung funktionieren.
[PS] C: > Get-MailboxDatabase -Identity DB2010 -Status | Wählen Sie Name, Letzte * Sicherung
Name: DB2010
LastFullBackup: 12.02.2016 21:00:51 Uhr
LastIncrementalBackup:
LastDifferentialBackup:
LastCopyBackup:

Überwachen Sie Datenbankkopien

In einem Datenbankverfügbarkeitsgruppe (DAG)Jedes Mitglied kann Kopien derselben Datenbank für Hochverfügbarkeitszwecke hosten. Der Administrator sollte die Replikation von Datenbankkopien zwischen DAG-Mitgliedern überwachen, um sicherzustellen, dass jede Datenbankkopie fehlerfrei bleibt. Überwachen Sie den Zustand der Kopierwarteschlange, der Wiedergabewarteschlange und des Inhaltsindex – auch als Katalog bezeichnet.
Führen Sie die aus Get-MailboxDatabaseCopyStatus Cmdlet, um den Zustand der Datenbankkopien in der DAG anzuzeigen (Listing 3).
Listing 3. Die Get-MailboxDatabaseCopyStatus Das Cmdlet zeigt an, dass mehrere Datenbankkopien angehalten wurden.

[PS] C: > Get-MailboxDatabaseCopyStatus * | Wählen Sie Name, Status, * QueueLength, ContentIndexState
Name: DB05 EX2010SRV1
Status: FailedAndSuspended
CopyQueueLength: 5721
ReplayQueueLength: 0
ContentIndexState: Angehalten

Name: DB05 EX2010SRV2
Status: montiert
CopyQueueLength: 0
ReplayQueueLength: 0
ContentIndexState: Gesund

Name: DB06 EX2010SRV1
Status: FailedAndSuspended
CopyQueueLength: 5547
ReplayQueueLength: 0
ContentIndexState: Angehalten

Name: DB06 EX2010SRV2
Status: montiert
CopyQueueLength: 0
ReplayQueueLength: 0
ContentIndexState: Gesund
In diesem Beispiel sind zwei der Datenbankkopien fehlerhaft. Dies würde ohne aktive Überwachung durch das Exchange-Administratorteam unbemerkt bleiben, da in jeder Datenbank noch mindestens eine weitere fehlerfreie Kopie vorhanden ist, die bereitgestellt wird und Clients bedienen kann. Wenn der Server, auf dem sich die fehlerfreien Datenbankkopien befinden, fehlschlägt oder zur Wartung neu gestartet wird, kann der Server, auf dem fehlerhafte Kopien gehostet werden, die Datenbanken nicht bereitstellen. Das Vergessen dieser Exchange-Datenbankwartungsaufgabe würde einen Ausfall für Ihre Endbenutzer verursachen.
Dieses Szenario ist ein gutes Beispiel dafür, warum die Implementierung einer DAG keine kugelsichere Hochverfügbarkeitstaktik ist. Exchange-Administratoren müssen die Datenbankkopien in der DAG weiterhin überwachen und verwalten, um die Verfügbarkeit sicherzustellen.

Speicherplatz zurückfordern

Wenn Daten zu einer Postfachdatenbank hinzugefügt werden, wird die Datenbankdatei größer. Wenn Daten aus der Datenbank gelöscht werden, werden beim Online-Exchange-Wartungsprozess nicht verwendete Datenbankseiten zurückgefordert, ohne den Betrieb zu stören. Leere Seiten können für andere Daten wiederverwendet werden. Der Online-Wartungsprozess verringert jedoch niemals die Größe der Datenbankdatei selbst.
Bei älteren Exchange-Bereitstellungen wie Exchange 2010, die über einen langen Zeitraum im Unternehmen vorhanden waren, wächst eine Postfachdatenbank häufig weit über die Größe der darin enthaltenen Daten hinaus. Dies wird häufig als Datenbank-Leerraum bezeichnet, wird jedoch genauer als verfügbarer neuer Postfachbereich bezeichnet.
Der verfügbare neue Postfachspeicher wird auf zwei Arten erstellt: beim Löschen von Postfachelementen oder beim Löschen von Postfächern. Dies gilt natürlich auch für Postfachmigrationen. Nachdem die gelöschten oder migrierten Daten die Aufbewahrungsfrist überschritten haben, werden sie aus der Datenbank gelöscht und die leeren Seiten für neue Daten vorbereitet.
Sie können den verfügbaren neuen Postfachspeicher anzeigen, indem Sie die Option ausführen Get-MailboxDatabase Cmdlet (Listing 4).
Listing 4. In diesem Beispiel wird die Get-MailboxDatabase Das Cmdlet ruft Informationen zum verfügbaren neuen Postfachbereich ab.
[PS] C: > Get-MailboxDatabase -Status | Wählen Sie Name, Verfügbar *
Name: DB01
AvailableNewMailboxSpace: 850,7 MB (892.043.264 Byte)
In einigen Fällen ist in einer Datenbank eine erhebliche Menge an verfügbarem neuen Postfachspeicher vorhanden. Die Organisation könnte am Ende größere Speichervolumes für die Datenbank als erforderlich verwalten, einfach weil die Datenbankdatei nicht auf die tatsächlich erforderliche Größe verkleinert werden kann. Dieses aufgeblähte Speicherszenario wirkt sich ähnlich auf die Datenmenge aus, die Sie sichern müssen.
Die einzige Möglichkeit, eine Datenbankdatei zu verkleinern, besteht darin, eine Offline-Defragmentierung durchzuführen. Wie der Name schon sagt, müssen Sie bei der Offline-Defragmentierung die Bereitstellung der Datenbank aufheben und sie für Endbenutzer nicht verfügbar machen. Ihre Exchange-Bereitstellung hat einen Ausfall, während der defragmentieren Sie den Betrieb läuft. Je größer die Datenbank, desto länger der Ausfall.
Ein besserer Ansatz, den Microsoft empfiehlt, besteht darin, eine neue Datenbank zu erstellen und Postfächer in diese zu verschieben. Die neue Datenbankdatei wird nur auf die Größe vergrößert, die zum Hosten der Postfächer erforderlich ist, in die Sie sie verschieben. Nicht genutzter Speicherplatz in der alten Datenbank wird nicht migriert. Angenommen, in der alten Datenbank war neuer Postfachspeicher verfügbar, erhalten Sie eine neue Datenbank, die kleiner als die alte ist. Wenn die Migration abgeschlossen ist, entfernen Sie einfach die alte Datenbank, um den Speicherplatz und die Anforderungen an die Sicherungskapazität zu verringern.
Da eine Offline-Defragmentierung riskanter ist, mehr freien Speicherplatz benötigt als die neue Datenbank und einen Ausfall verursacht, verwenden Sie die Postfachmigrationsmethode, um Ihre Datenbanken zu verkleinern.

Similar Posts

Leave a Reply