Exchange – Ausführen eines Stubs und Datenbank-Speicherplatzfreigabe
Veröffentlichung des Originalartikels: 28.08.2012
Exchange 2010 SP2 RU1 enthielt einen Fix für ein Problem in Bezug auf die Datenbank-Speicherplatzfreigabe. Es gab einige Verwirrung in Bezug auf dieses Problem, daher möchte ich das Problem erörtern, darlegen wie der Fix aussieht und Erwartungen erläutern, wenn bei der Verwendung von Drittanbieterprodukten ein Stubbing mit Elementen in der Datenbank erfolgt (das Ausführen eines Stubs ist der Vorgang, in der eine Nachricht durch ein Zeigerobjekt ersetzt und die Originalversion in einem externen Repository gespeichert wird).
Der Fehler und der Fix
In Exchange 2010 haben wir festgestellt, dass der Datenbankspeicherplatz in mehreren Szenarien nicht freigegeben wurde, wenn Elemente hart gelöscht wurden (wenn das Element aus dem Speicher gelöscht wurde). Dazu zählen auch Archivszenarien, in denen Elemente einer Massenlöschung unterzogen wurden, und zwar auf Grundlage von Daten, Stubbing-Szenarien, in denen Anlagen gelöscht wurden, und anderer Szenarien, beispielsweise Journalpostfächer und öffentliche Ordnerreplikation. Dieses Problem betraf sehr viele Kunden, und das Problem bestand in der Funktionsweise der Elementlöschung.
Von Exchange 2010 wird für gewöhnlich versucht, innerhalb einiger Minuten, während das Element hart gelöscht wird, die Zeile für ein gelöschtes Element zu bereinigen. Die Bereinigung ist jedoch fehlerhaft, wenn mit dem Element weiterhin offene Referenzen bestehen. Beispielsweise treten bei folgenden Bereinigungsszenarien Fehler auf: Inhaltsindizierung indiziert eine Nachricht, ein separater Client liest die Nachricht usw. Wenn eine offene Referenz vorliegt, tritt bei der Bereinigung ein Fehler auf. Vor diesem Fix war der bei der zu diesem Zeitpunkt fehlerhaften Bereinigung betroffene Speicherplatz im Prinzip verloren und konnte nicht wiederhergestellt werden, ohne das Postfach zu verschieben.
Es stellte sich heraus, dass ausstehende Referenzen für gelöschte Nachrichten ziemlich häufig bei Journalpostfächern auftreten. Bei verwendeter Drittanbieter-Archivsoftware brachte die große Mehrheit der betroffenen Kunden diesen Fehler mit einem dieser beiden Szenarien in Verbindung. Technisch gesehen kann ein Client jedoch eine offene Referenz halten und ein Element davor bewahren, bereinigt zu werden.
Der in SP2 RU1 enthaltene Fix behebt dieses Problem durch das Hinzufügen eines Bereinigungswiederholungsmechanismus. Bei einem fehlerhaften Bereinigungsvorgang aufgrund einer offenen Referenz wird der Speicher es periodisch versuchen, bis der Vorgang erfolgreich ausgeführt wird.
Führt dieser Fix einen Stub aus?
Das Ausführen eines Stubs bezieht sich auf einen Vorgang, in dem ein Drittanbieter-Archivprodukt eine große Nachricht übernimmt und sie in ein kleines Element oder einen Stub umwandelt. Dies geschieht in der Regel durch Löschen der Anlagen und Ändern der Nachricht, um die Elemente zu verkleinern.
Da durch das Ausführen eines Stubs Anlagen gelöscht werden, könnte es von diesem Fehler betroffen sein, zumal diese gelöschten Anlagen bei der Bereinigung aufgrund offener Referenzen einen Fehler verursachen könnten. Ansonsten ging es bei diesem Fehler nie wirklich um das Ausführen eines Stubs.
Was geschieht, wenn das Ausführen eines Stubs nicht den erwarteten Speicherplatz freigibt?
Der Exchange-Informationsspeicher hat sich in den letzten Jahren oftmals verändert, doch selbst in Exchange 2003 bzw. 2007 würde das Ausführen eines Stubs Datenbanken zur Folge haben, die erheblich größer sind, als Sie möglicherweise vermuten, wenn Sie Postfachgrößen hinzufügen. Dies lag meistens an zwei Formen des Ausschusses.
Der erste Ausschusstyp besteht in den Eigenschaften, die einfach nicht die Größe der Nachricht berechnen. Wenn Sie die Größe einer Nachricht in Outlook betrachten, entspricht die angezeigte Größe nicht der Gesamtgröße aller Daten, die von Exchange für diese Nachricht gespeichert werden. Wir speichern bestimmte Eigenschaften, die nicht für den Benutzer gezählt werden und sich nicht in der Nachrichtengröße widerspiegeln. Dazu zählen möglicherweise öffentlich dokumentierte Eigenschaften wie PR_URL_NAME oder andere interne Eigenschaften, auf die Clients nicht zugreifen können.
Der zweite Ausschusstyp besteht in der Seitenfragmentierung. Die Datenbankseitengröße hat sich mit den Jahren verändert. Waren es in Exchange 2003 noch 4 KB, so veränderte sich dieser Wert in Exchange 2007 auf 8 KB und erreichte in Exchange 2010 schließlich 32 KB. Jeder Datensatz in der Datenbank muss auf diesen Seiten angeordnet werden, und in Abhängigkeit davon, wie effektiv wir dies vornehmen können, bleibt auf der Seite etwas Speicher über. Dies ist die Seitenfragmentierung, die leeren Speicher zur Folge hat, der durch die Datenbankwartung nicht freigegeben werden kann. Die größeren Seitengrößen der neueren Exchange-Versionen vereinfachen die Anordnung mehrerer kleiner Elemente auf einer einzelnen Seite, was eine geringere Fragmentierung zur Folge hat. Es gibt jedoch immer eine bestimmte fragmentierte Menge, die sich dort befindet.
Die Ausschussmenge ändert sich im Allgemeinen nicht wesentlich zwischen Nachrichten. Eine kleine Nachricht verursacht einen ebenso großen Ausschuss wie eine große Nachricht. Wenn Sie eine Datenbank mit kleinen Elementen füllen, wird der Ausschuss aus diesem Grund deutlich sichtbarer.
Stellen Sie sich beispielsweise vor, Sie hätten eine Datenbank mit Elementen gefüllt, die jeweils 1 MB groß sind, und alle diese Elemente würden einen Ausschuss von 1 KB verursachen. Das würde bedeuten, Ihre Datenbank hätte in etwa einen Ausschuss von 0,09 %. Wenn Sie beispielsweise für alle Elemente in der Datenbank einen Stub ausführen würden und sie dadurch jeweils auf etwa 4 KB verkleinern könnten, wäre dieser Ausschuss von 1 KB plötzlich viel spürbarer, da er nun 25 % der Datenbank betreffen würde. Vor einiger Zeit habe ich persönlich eine Exchange 2003-Datenbank erstellt mit 70 % Ausschuss, indem ich sie mit kleinen Elementen gefüllt und einen Stub für alle Elemente ausgeführt habe.
Was gilt für Exchange 2010?
In Exchange 2010 gibt es einen zusätzlichen Faktor, der sich möglicherweise auf die Speicherplatzfreigabe durch das Stubbing auswirkt, und dies ist die Änderung im Entwurf der Datenbank.
In Exchange 2010 gab es große Fortschritte in Bezug auf die Reduzierung von Datenbank-IOPS. Ein großer Bestandteil lag in der Beseitigung des alten Onlinedefragmentierungsprozesses, der die Datenbank nächtlich aggressiv durchgerüttelt und Elemente verschoben hat, um den Speicherplatz zu optimieren. In Exchange 2010 konzentrieren wir uns stärker darauf, Postfachinhalte auf zusammenhängenden Seiten zu speichern, um die Eingabe/Ausgabe zu reduzieren, auch wenn dies hier und da ungenutzten Speicher mit sich bringt. Exchange 2010 war im Prinzip nicht dafür geschaffen, Speicherplatz aggressiv freizugeben, wenn eine Nachricht plötzlich geschrumpft wird. Dies ist ein Szenario, das wir in der Architektur minimiert haben, um die Eingabe/Ausgabe zu verbessern. Weitere Informationen zu den Wartungsänderungen finden Sie unter Database Maintenance in Exchange 2010.
Bedeutet dies, Sie würden durch das Ausführen eines Stubs keinen Speicherplatz sparen? Nicht unbedingt. Bei Stubbing-Produkten werden für gewöhnlich Anlagen gelöscht, daher würden wir diesen Speicherplatz als frei erachten. Und obwohl Exchange 2010 nicht explizit dafür entwickelt wurde, haben wir festgestellt, dass anlagenfreie Elemente beim Ausführen eines Stubs einigen Speicherplatz freigeben.
Da dies jedoch kein Bestandteil der Entwicklung von Exchange 2010 ist, können wir Ihnen nicht sagen, wie viel freigegebener Speicherplatz bei Verwendung eines Stub-Archivs zu erwarten ist. Sämtliche Erwartungen hierzu sollten Sie in einem eigenen Test überprüfen bzw. mithilfe von Daten, die Sie von Ihrem Archivsoftwareanbieter erhalten.
Wir können demnach keine Behauptung über die Freigabe von Speicherplatz hinsichtlich eines für kleinere Eigenschaften geänderten Elements aufstellen. Es kann jedoch aufgrund des Designs in Exchange 2010 angenommen werden, dass das Verkleinern eines Elements keinen Speicherplatz freigibt. Wie gewohnt verweisen wir Sie während des Supports von Datenbankspeicherproblemen bei der Verwendung von Drittanbieterprodukten für Support an den bestimmten Drittanbieter, wenn Exchange ansonsten fehlerfrei funktioniert.
Schlussbemerkung
In Exchange 2010 SP2 RU1 ist ein Fix enthalten, der Kunden dabei hilft, jede Art von Archivierung, Stubbing oder dergleichen vorzunehmen, da er die Bereinigung hart gelöschter Elemente zuverlässig umsetzt. Sämtliche durch das Ausführen eines Stubs erwarteten Datenträger-Speicherplatzeinsparungen sollten von Ihnen und Ihrem Archivsoftwareanbieter geprüft werden. Bei der Bereitstellung von Speicher empfehlen wir Ihnen, dass Sie unsere veröffentlichte Anleitung (dazu zählt die Nutzung großer Postfächer, damit Sie sich nicht nur auf Drittanbieter-Archivlösungen verlassen müssen) und die Tools befolgen, um sicherzustellen, dass Sie über entsprechenden Speicherplatz für Ihre Exchange-Daten verfügen.
Bill Long
Dies ist ein übersetzter Blogbeitrag. Sie finden den Originalartikel unter Exchange, Stubbing, and Database Space Reclamation