Freigeben über

Neue wichtige Funktionen des Exchange-Informationsspeichers

  • Artikel

 

Gilt für: Exchange Server 2010 SP2

Letztes Änderungsdatum des Themas: 2016-11-28

In Microsoft Exchange Server 2010 wurden eine Vielzahl von Verbesserungen im Hinblick auf die Exchange-Datenbankarchitektur implementiert.

  • Die Berichterstellung für Öffentliche Ordner wurde verbessert.

  • Datenbanken sind nicht länger Speichergruppen zugeordnet. Speichergruppen wurden entfernt.

  • Durch Investitionen in das Informationsspeicherschema und ESE-Optimierungen (Extensible Storage Engine) konnten E/A-Vorgänge pro Sekunde (IOPS) um 70 Prozent reduziert werden.

In den folgenden Abschnitten werden diese Verbesserungen genauer erläutert.

Inhalt

Verbesserte Berichterstellung für Öffentliche Ordner

Datenbankverwaltung

Änderungen am Informationsspeicher

Neue ESE-Funktionalität

Verbesserte Berichterstellung für Öffentliche Ordner

Die Berichterstellung für Öffentliche Ordner wurde erweitert, sodass nun auch von Benutzern initiierte Änderungen an Elementen im Öffentlichen Ordner angezeigt werden können. Diese Informationen können über das Cmdlet Get-PublicFolderStatistics in der Exchange-Verwaltungsshell angezeigt werden. Weitere Informationen finden Sie unter Verwenden von PowerShell mit Exchange 2010 (Exchange-Verwaltungsshell).

Datenbankverwaltung

Datenbanken sind nicht länger Speichergruppen zugeordnet. In Exchange 2010 wurde die Speichergruppenfunktionalität in die Datenbank verschoben.

In Exchange 2010 können Postfach- und Öffentliche Ordner-Datenbanken im Knoten Organisationskonfiguration der Exchange-Verwaltungskonsole verwaltet werden. (In Exchange Server 2007 wurden Datenbanken im Knoten Serverkonfiguration verwaltet.)

Wenngleich die Verwaltung von Öffentliche Ordner-Datenbanken vom Knoten Serverkonfiguration in den Knoten Organisationskonfiguration mit den Postfachdatenbanken verschoben wurde, wurde die Funktionalität von Öffentliche Ordner-Datenbanken in Exchange 2010 nicht geändert. Wie in Exchange 2007 können keine Datenbankkopien von Öffentliche Ordner-Datenbanken erstellt werden, und Öffentliche Ordner-Datenbanken können nicht zu einer Database Availability Group (DAG) hinzugefügt werden. Öffentliche Ordner-Datenbanken können jedoch auf Postfachservern gehostet werden, die Teil einer DAG sind. Der Protokollversand oder andere Funktionen von DAGs können jedoch nicht für Öffentliche Ordner-Datenbanken verwendet werden.

Änderungen an Datenbank-Cmdlets

Mit dem Entfernen von Speichergruppen in Exchange 2010 wurden auch die in Exchange 2007 verwendeten Speichergruppen-Cmdlets gelöscht. Die entsprechenden Funktionen werden nun über die Datenbank-Cmdlets in Exchange 2010 bereitgestellt, wie in den folgenden Tabellen gezeigt.

Datenbank-Cmdlets in Exchange 2010, die Speichergruppen-Cmdlets in Exchange 2007 ersetzen

Exchange 2007-Cmdlet Beschreibung der Funktionsänderung in Exchange 2010

New-StorageGroup

Dieses Cmdlet wurde gelöscht, und die Konfigurationsparameter werden nun in den Cmdlets New-MailboxDatabase und New-PublicFolderDatabase verwendet.

Remove-StorageGroup

Dieses Cmdlet wurde gelöscht, und die Konfigurationsparameter werden nun in den Cmdlets Remove-MailboxDatabase und Remove-PublicFolderDatabase verwendet.

Set-StorageGroup

Dieses Cmdlet wurde gelöscht, und die Konfigurationsparameter werden nun in den Cmdlets Set-MailboxDatabase und Set-PublicFolderDatabase verwendet.

Get-StorageGroup

Dieses Cmdlet wurde gelöscht, und die Konfigurationsparameter werden nun in den Cmdlets Get-MailboxDatabase und Get-PublicFolderDatabase verwendet.

Move-StorageGroupPath

Dieses Cmdlet wurde gelöscht, und die Konfigurationsparameter werden nun im Cmdlet Move-DatabasePath verwendet.

Datenbank-Cmdlets in Exchange 2010 mit erweiterter Funktionalität im Vergleich zu Cmdlets in Exchange 2007

Exchange 2010-Cmdlet Beschreibung der erweiterten Funktionalität in Exchange 2010

New-MailboxDatabase

New-PublicFolderDatabase

Diese Cmdlets wurden um die Parameter und Funktionen des Cmdlets New-StorageGroup erweitert. Über diese Cmdlets wird das Serverobjekt zudem mit einem Link zur neuen Datenbank und zum Datenbankobjekt mit dem Namen des hostenden Servers aktualisiert.

Remove-MailboxDatabase

Remove-PublicFolderDatabase

Diese Cmdlets wurden um die Parameter und Funktionen des Cmdlets Remove-StorageGroup erweitert. Über diese Cmdlets wird das Serverobjekt nun zusätzlich mit dem Link zur neuen Datenbank und zum Datenbankobjekt mit dem Namen des hostenden Servers aktualisiert.

Set-MailboxDatabase

Set-PublicFolderDatabase

Diese Cmdlets wurden um die Parameter und Funktionen des Cmdlets Set-StorageGroup erweitert. Beim Ändern der Hostserver wird das Serverobjekt über diese Cmdlets nun zusätzlich mit dem Link zur neuen Datenbank und zum Datenbankobjekt mit dem Namen des hostenden Servers aktualisiert.

Get-MailboxDatabase

Get-PublicFolderDatabase

Diese Cmdlets wurden um die Parameter und Funktionen des Cmdlets Get-StorageGroup erweitert. Der Parameter Status wurde erweitert und gibt nun auch die Statusinformationen zurück, die gegenwärtig über das Cmdlet Get-StorageGroupCopyStatus zurückgegeben werden.

Move-DatabasePath

Dieses Cmdlet wurde um die Parameter und Funktionen des Cmdlets Move-StorageGroupPath erweitert.

Zusätzlich zu den oben genannten Cmdlet-Änderungen wurden die StorageGroupCopy-Cmdlets gelöscht. Weitere Informationen finden Sie unter Verwalten von Postfachdatenbankkopien.

Änderungen am Informationsspeicher

Das Informationsspeicherschema wurde in Exchange 2010 geändert, um die Abhängigkeit von Postfachdatenbanken auf dem Serverobjekt zu entfernen. Zum Reduzieren der Datenbank-E/A-Vorgänge pro Sekunde (IOPS) wurde das neue Schema zusätzlich verbessert, indem die zum Speichern von Informationen verwendeten Tabellen umgestaltet wurden. Die Umgestaltung der Tabellen verbessert die logische Gruppierung zusammenhängender Daten und unterstützt das Lokalitätsprinzips. Durch diese Änderungen ist der Informationsspeicher weniger von den über ESE verwalteten sekundären Indizes abhängig. Folglich wirken sich Leistungsprobleme im Zusammenhang mit sekundären Indizes nicht länger auf den Informationsspeicher aus.

Die Ausfallsicherheit und Integrität des Informationsspeichers wurde ebenfalls verbessert, indem verschiedene Funktionen zur Ermittlung und Behandlung von Fehlern sowie zur Bereitstellung von Warnungen hinzugefügt wurden. Im Folgenden sind einige dieser Funktionen aufgeführt:

  • Postfachquarantäne für nicht autorisierte Postfächer

  • Abbruch von Transportvorgängen, wenn der verfügbare Datenbankspeicher weniger als 1 GB beträgt

  • Threadtimeout-Ermittlung und -Berichterstellung

Weitere Informationen zu Ausfallsicherheit und Integrität des Informationsspeichers finden Sie unter Grundlegendes zum Exchange 2010-Informationsspeicher.

Die wichtigsten Informationsspeicherfunktionen wurden umfassend geändert, um die Funktionen für hohe Verfügbarkeit zu verbessern. Hohe Verfügbarkeit wurde in die grundlegende Architektur von Exchange 2010 integriert, damit Organisationen aller Größenordnungen und Branchen kostengünstig einen Messagingkontinuitätsdienst bereitstellen können. Weitere Informationen zu den Änderungen im Hinblick auf hohe Verfügbarkeit in Exchange 2010 finden Sie unter Grundlegendes zu hoher Verfügbarkeit und Ausfallsicherheit von Standorten.

Neue ESE-Funktionalität

Die ESE-Funktionalität (Extensible Storage Engine) wurde in Exchange 2010 verbessert, um die folgenden Ziele zu erreichen:

  • Höhere und sequenzielle E/A zum Reduzieren der E/A-Vorgänge pro Sekunde (IOPS)

  • Optimierung für Standardspeicher

  • Reduzierte Datenbankverwaltung

  • Onlinedefragmentierung

  • Onlinedatenbanküberprüfung

Höhere und sequenzielle E/A

Durch eine Steigerung der E/A und weniger oft durchgeführte Lese-/Schreibvorgänge in Exchange 2010 kann die Leistung mit ESE verbessert werden. Darüber hinaus kann ESE die Leistung durch eine verstärkte sequenzielle Anordnung von Daten in der Datenbank steigern. Dies erhöht die Wahrscheinlichkeit, dass sich verknüpfte Daten innerhalb der B-Struktur in unmittelbarer Nähe zueinander befinden.

In Exchange werden sämtliche Daten in der Datenbank in B-Strukturen gespeichert, die wiederum in Seiten gegliedert sind. In Exchange 2007 und früher werden die Daten in den B-Strukturen nicht zusammenhängend gespeichert. Stattdessen werden in früheren Versionen von Exchange zufällige Lese-/Schreibvorgänge in der Datenbank ausgeführt. Das bedeutet, dass sich verknüpfte Daten auf der Festplatte möglicherweise nicht in unmittelbarer Nähe zueinander befinden. Bei nicht zusammenhängenden Daten sind zum Ausführen von Lese- und Schreibvorgängen auf der Festplatte mehr Durchläufe erforderlich.

B-Struktur-Defragmentierung

Zum Reduzieren von E/A-Vorgängen wurde die Defragmentierung der B-Struktur verbessert, indem in der B-Struktur nun zusammenhängende Daten verwaltet werden.

Anstatt eine neue B-Struktur zu erstellen und die Indizes und Tabellen umzubenennen, erfolgt die Defragmentierung der B-Struktur über drei neue Vorgänge direkt innerhalb der Struktur:

  • Seitenverschiebung   Bei diesem Vorgang werden sämtliche Daten aus einer Seite in eine neu zugewiesene Seite verschoben.

  • Teilzusammenführung links   Bei diesem Vorgang handelt es sich praktisch um denselben Vorgang wie bei einer Rechtszusammenführung in Exchange 2007 oder früher. Der einzige Unterschied besteht darin, dass die Daten von der linken Seite in die rechte Seite verschoben werden.

  • Vollständige Zusammenführung links   Dieser Vorgang ist mit der vollständigen Rechtsverschiebung in Exchange 2007 oder früher identisch.

Zur Optimierung der Leistung werden anstelle von Rechtszusammenführungen bei der Defragmentierung nun Linkszusammenführungen ausgeführt. Daten werden von rechts nach links von der Festplatte gelesen bzw. auf diese geschrieben. Wenn die Defragmentierung der Datenbank in dieselbe Richtung ausgeführt wird wie Lese-/Schreibvorgänge, treten Konflikte mit diesen Vorgängen auf. Ferner kann bei der Speicherzuordnung die nächste Seite in einem Bereich zugewiesen werden, die vorherige jedoch nicht. Da bei einer Seitenverschiebung eine neue Seite zugewiesen werden muss, ist die Defragmentierung der Datenbank von links nach rechts deutlich effizienter.

Der Defragmentierungs-Manager ist eine neue Funktion in ESE und überwacht, welche B-Strukturen defragmentiert werden müssen und welche B-Strukturen bereits defragmentiert wurden. Der Defragmentierungs-Manager erstellt eine Liste der B-Strukturen in allen eingebundenen Datenbanken, die defragmentiert werden sollten. Bei der Ermittlung fragmentierter B-Strukturen werden diese für den Defragmentierungs-Manager registriert und von diesem Manager verarbeitet.

Erhöhung der Seitengröße auf 32 KB

Sämtliche Daten in der Datenbank werden in B-Strukturen gespeichert, die wiederum in Seiten gegliedert sind. Die Seitengröße gibt die Mindestgröße für Lese- und Schreibvorgänge in der Datenbank an und wird gleichzeitig als Einheit für die Datenbankzwischenspeicherung verwendet. Bei Lesevorgängen von der Festplatte wird eine geringere Leistung erreicht als bei Vorgängen im Arbeitsspeicher. Durch die Erhöhung der Seitengröße auf 32 KB und Speicherung der größeren Seiten im Arbeitsspeicher kann ESE daher IOPS reduzieren und die Leistung verbessern.

Optimierung für Standardspeicher

Ein weiteres Ziel von ESE in Exchange 2010 ist die Reduzierung der Kapital- und Betriebskosten bei der Bereitstellung von Exchange. Dieses Ziel kann durch reduzierte Speicherkosten und eine Optimierung für Standardspeicher unter Verwendung von JBOD- und SATA-Festplatten erreicht werden.

Datenträgersubsysteme arbeiten effizienter, wenn sie eine geringere Anzahl von E/A-Vorgängen verarbeiten, die jedoch mehr Daten umfassen. In Exchange 2010 oder früher entspricht die Seitengröße der Mindestgröße von Lese-/Schreibvorgängen und der Mindestgröße für die Datenbankzwischenspeicherung. Beim Zusammenführen von E/A-Vorgängen werden Datenbankseitenvorgänge in einem einzelnen E/A-Vorgang kombiniert, d. h. es werden weniger E/A-Vorgänge generiert, die jedoch mehr Daten umfassen.

Das Erhöhen der durchschnittlichen Größe von Datenbank-E/A-Vorgängen durch die Zusammenführung bietet die folgenden Vorteile:

  • Effizientere Datenträgernutzung   Datenträger arbeiten effizienter, wenn sie E/A-Vorgänge mit einer großen Datenmenge verarbeiten. Je effizienter ein Datenträger genutzt wird, desto mehr Postfächer können auf diesem Datenträger gehostet werden.

  • Verbesserter Vorabruf für den Zwischenspeicher   Mithilfe des Vorabrufs für den Zwischenspeicher können die Ausführungszeiten reduziert werden, indem die anfänglichen Abfragen, die beim letzten Starten der Datenbank ausgeführt wurden, vorab geladen werden. Nach dem Neustart, Failover oder Switchover eines Servers kann ESE durch eine höhere E/A den Vorabruf für den Zwischenspeicher beschleunigen.

Datenbankwartung

Ein Ziel von ESE in Exchange 2010 ist die Reduzierung der Wartungs- und Verwaltungskosten einer Datenbank. Die Datenbankwartung umfasst verschiedene Aufgaben, um die Integrität Ihrer Postfachdatenbank zu verwalten und aufrecht zu erhalten.

Die Datenbankwartung gliedert sich in die folgenden Bereiche:

  • Postfachspeicherwartung

  • ESE-Datenbankwartung

In Exchange 2007 mussten für die ESE-Datenbankwartung eine Vielzahl von Festplattenvorgängen ausgeführt werden. Um eine höhere Leistung zu erzielen, wurden diese Vorgänge in Exchange 2010 verbessert. In Exchange 2010 dauert der Task für die Postfachspeicherwartung auf Servern mit hohem oder sehr hohem Auslastungsprofil ungefähr 45 Minuten, während die ESE-Datenbankwartung bei großen Exchange 2007-Datenbanken (Kontingente von 2 GB) üblicherweise zwischen sechs und acht Stunden pro Nacht dauerte.

In Exchange 2010 wurden Verbesserungen implementiert, um sowohl große Postfächer als auch JBOD-Speicher und Speicher ohne RAID zu unterstützen.

Hinweis

Sämtliche Funktionen zur Onlinedatenbankwartung für den Exchange-Informationsspeicher (z. B. die Bereinigung von Wiederherstellungselementen) sind in Exchange 2010 und Exchange 2007 identisch. Nur die ESE-Funktionen, die Onlinedefragmentierung sowie die Datenbank-Prüfsummenbildung wurden geändert.

Datenbankdefragmentierung

Durch die Defragmentierung werden die internen Seiten einer Exchange-Datenbank angrenzend zusammengelegt. Die Defragmentierung kann entweder automatisch vom System durchgeführt werden, während die Datenbank online ist (Onlinedefragmentierung), oder manuell von einem Administrator gestartet werden, während die Datenbank offline ist (Offlinedefragmentierung).

Onlinedefragmentierung

Die Architektur für die Onlinedefragmentierung wurde in Exchange 2010 geändert. Die Onlinedefragmentierung ist nicht länger Teil der Postfachdatenbankwartung. Die Onlinedefragmentierung wird jetzt rund um die Uhr im Hintergrund ausgeführt. Weil die Onlinedefragmentierung ununterbrochen abläuft, stellt Exchange keine Ereignisse im Ereignisprotokoll bereit, welche die Menge des Leerraums in der Datenbank angeben. Während einer Datenbankwartung im Hintergrund werden die zum Entfernen aus der Datenbank markierten Objekte entfernt, wodurch Datenbankseiten freigegeben werden. Der Prozentsatz an Leerraum ändert sich ständig aufgrund des fortlaufenden Onlinedefragmentierungsprozesses.

Sie können die Menge an Leerraum in der Datenbank abschätzen, wenn Sie die Menge an E-Mails kennen, die Benutzer mit Postfächern in der Datenbank senden und empfangen. Wenn es z. B. 100 Postfächer mit 2 GB (insgesamt 200 GB) in einer Datenbank gibt, in der die Benutzer durchschnittlich 10 MB an E-Mails pro Tag empfangen, dann beträgt der Umfang des Leerraums ungefähr 1 GB (100 Postfächer × 10 MB pro Postfach). Die Menge an Leerraum kann diese Schätzung übersteigen, wenn die Datenbankwartung im Hintergrund nicht vollständig abgeschlossen werden kann.

Für diese Funktion müssen keine Einstellungen konfiguriert werden. Exchange überwacht die Datenbank online und nimmt im Laufe der Zeit kleine Änderungen vor, um einer Fragmentierung entgegenzuwirken und Daten logisch zu gruppieren. Wenn die Datenbank einen Seitenbereich analysiert und ermittelt, dass die Seiten nicht wie erwartet sequenziell angeordnet sind, wird ein asynchroner Thread zur Defragmentierung dieses Abschnitts der B-Struktur/Tabelle gestartet. Um eine Beeinträchtigung der Clientleistung zu verhindern, wird die Onlinedefragmentierung zudem gedrosselt.

Verwenden Sie die ESE-Leistungsindikatoren "MSExchange-Datenbank ==> Defragmentierungstasks", um die ausgeführten Tasks anzuzeigen. Weitere Informationen finden Sie unter Aktivieren der erweiterten ESE-Leistungsindikatoren.

Offlinedefragmentierung

Die Offlinedefragmentierung ist ein manueller Prozess, der von einem Administrator durchgeführt wird, während die Datenbank sich im nicht bereitgestellten Zustand (offline) befindet. Bei diesem Prozess wird das Tool ESEUTIL verwendet, um die Datenbankdatei zu lesen und eine neue Datenbankdatei zu schreiben, wobei der Inhalt angrenzend angeordnet wird. Beim Offlinedefragmentierungsprozess wird der Leerraum nicht aus der ursprünglichen Datenbank kopiert; daher ist die neu erstellte Datenbankdatei auf der Festplatte kleiner als die ursprüngliche Datenbankdatei (je nach der Menge des Leerraums in der Datenbank möglicherweise sogar viel kleiner). Ursprünglich gab es für die Durchführung der Offlinedefragmentierung einer Datenbank in der Regel folgende Gründe:

  • Verkleinern der Datenbankdatei auf der Festplatte

  • Freigeben von Leerraum in einer Datenbank

  • Vermeiden von Speicherplatzengpässen

  • Reparieren einer beschädigten Datenbank (nach ESEUTIL /p der zweite Schritt in der Reparatur)

Die Offlinedefragmentierung war nie Bestandteil der regelmäßigen Wartung von Exchange-Datenbanken, und Microsoft rät bereits seit einer Weile von einer regelmäßigen, proaktiven Offlinedefragmentierung von Datenbanken ab. Diese Empfehlung basiert auf einer Vielzahl von Gründen:

  • Sie führt zu Ausfallzeiten, da die Datenbank offline geschaltet werden muss.

  • In einer replizierten Postfachdatenbankumgebung muss für alle passiven Kopien einer aktiven Kopie, die offline defragmentiert wurde, ein neues Seeding ausgeführt werden. Außerdem muss für jede passive Kopie, die offline defragmentiert wurde, ein neues Seeding ausgeführt werden. (Daher sollten Sie niemals eine Offlinedefragmentierung einer passiven Datenbankkopie durchführen.)

  • Sie führt zur Erstellung einer neuen Datenbank mit einer neuen Datenbanksignatur. Dadurch entfällt die Möglichkeit, Protokolldateien aus einer Datenbanksicherung wiederherzustellen, die vor der Offlinedefragmentierung angefertigt wurde.

Als Alternative zur Offlinedefragmentierung empfiehlt es sich für Kunden, eine neue Datenbank zu erstellen und die Postfächer in die neu erstellte Datenbank zu verschieben. In einer Exchange 2010-Umgebung werden die Postfächer online und ohne Dienstunterbrechung für Endbenutzer verschoben. Wenn Sie alle Postfächer aus einer vorhandenen in eine neue Datenbank verschieben, ist das Endergebnis außerdem dasselbe: eine defragmentierte Datenbank mit angrenzend geschriebenen Seiten und ohne nennenswerten Leerraum in der Datenbankdatei. Nach Abschluss des Vorgangs löschen Sie einfach die alte (jetzt leere) Datenbank. Diese Anleitung bezieht sich nur auf die proaktive Offlinedefragmentierung zum Freigeben von Leerraum. Sie sollten die Defragmentierung dennoch durchführen, wenn Sie von den Microsoft Customer Support Services dazu aufgefordert werden.

Onlinedatenbanküberprüfung

Die Onlinedatenbanküberprüfung (auch als Datenbank-Prüfsummenbildung bezeichnet) wurde ebenfalls geändert. In Exchange 2007 Service Pack 1 (SP1) hatten Sie die Möglichkeit, die Hälfte der für die Onlinedefragmentierung reservierten Zeit für diesen Datenbanküberprüfungsvorgang zu verwenden (sodass sichergestellt wurde, dass Exchange innerhalb eines bestimmten Zeitraums sämtliche Seiten in der Datenbank liest, um gegebenenfalls Beschädigungen zu ermitteln).

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. Aufgrund von Abstürzen können Speicherlecks entstehen, und bei der Onlinedatenbanküberprüfung wird verlorener Speicherplatz ermittelt und erneut verfügbar gemacht. 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 im Hintergrund rund um die Uhr (Standardverhalten). Diese Option kann für Datenbanken aller Größenordnungen verwendet werden, sollte jedoch bei größeren Datenbanken (1-2 TB) genutzt werden. 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.

Weitere Informationen zum Konfigurieren der Datenbankwartung finden Sie unter Verwalten von Postfachdatenbanken.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.