Was ist eine Sicherung mit geringem Stromverbrauch?
Normalerweise führt der Sicherungs- und Notfallwiederherstellungsdienst eine zeitaufwendige anfängliche Vollsicherung einer Datenbank durch. Alle nachfolgenden Sicherungen sind dann viel schnellere inkrementelle Sicherungen. Bei einer inkrementellen Sicherung werden die Bitmaps des aktuellen Snapshots mit dem vorherigen Snapshot verglichen und nur die inkrementellen Änderungen angewendet.
Eine Low-Splash-Sicherung ist eine spezielle Art von Sicherungsjob, die ausgeführt wird, wenn ein Systemfehler im vorherigen Sicherungsjob zu einem unzuverlässigen Bitmapbild oder zur Unmöglichkeit führt, das Bitmap zu lesen. Der Dienst, der die Bitmap liest, ist in einer Linux-Umgebung „cbt_server“ und in einer Windows-Umgebung „AAMService“.
Sicherungen mit geringem Splash sind zeitaufwendiger als Sicherungen unter normalen Bedingungen, da eine vollständige Datenaufnahme noch einmal durchgeführt werden muss, um eine zuverlässige Bitmap zu erstellen. Die inkrementellen Änderungen können dann angewendet werden, ohne das vollständige Bild ersetzen zu müssen.
Dinge, die keine Sicherungen mit geringem Splash-Effekt verursachen
- Connector-Upgrades
- Ordentliche Systemneustarts
- Störungsfreier Neustart von cbt_server oder AAMService, vorausgesetzt, der Dienst wird zum Zeitpunkt der Sicherung noch ausgeführt
- Failover, bei denen keine Fehler aufgetreten sind, die zu unzuverlässigen Bitmaps führen.
Ursachen für unzuverlässige Bitmaps
Eine unzuverlässige Bitmap tritt auf, wenn der Sicherungsjob unterbrochen wird. Das kann z. B. folgende Ursachen haben:
- Unsauberes Herunterfahren des Hosts
- Ein nicht ordnungsgemäßes Herunterfahren führt aufgrund der Unzuverlässigkeit von Bitmaps zu einem schwachen Splash-Bildschirm. Dazu gehört auch das Abschalten des Stroms auf einem physischen Computer oder jede andere Methode, Windows ohne einen ordnungsgemäßen Herunterfahrvorgang oder einen Bluescreen-Fehler auszuschalten. Das gilt auch, wenn auf einem Computer in einem Cluster ein Bluescreen-Fehler auftritt, der den Failover auslöst, da die Bitmap des ausgefallenen Computers nicht zuverlässig ist.
- Wenn alle Windows-Server in einem Cluster, auf denen die Datenbank seit der vorherigen Sicherung gehostet wurde, nicht verfügbar sind und keine Actifio-Dienste ausführen. Wir ziehen Bitmaps von jedem Clusterhost ab, auf dem die Datenbank seit der letzten Sicherung gehostet wurde, um Änderungen zu finden. Ohne alle Bitmaps müssen wir Low-Splash ausführen, um die Datenintegrität aufrechtzuerhalten. Hinweis: Wenn auf einem Clusterhost, auf dem eine Datenbank gehostet wird, ein BSOD auftritt, ist die Bitmap bei der Sicherung möglicherweise verfügbar, aber dennoch unzuverlässig.
- Ein fehlgeschlagenes Kernelmodul-Update
- Ein Absturz oder Neustart des User-Mode-Daemons
- Ein Fingerabdruckfehler beim Ausführen einer Sicherung. (Der Sicherungs- und Notfallwiederherstellungsdienst führt für jeden Sicherungsjob eine „Fingerabdruckprüfung“ durch, um auf Fehler zu prüfen.)
- Fehler beim Speichern im Vault, wenn das Speicherlaufwerk während des Herunterfahrens des Betriebssystems voll ist und das System nicht alle Daten in den Vault schreiben kann.
- SAP HANA-Knoten-Failover, wodurch die Sicherung an einen anderen Knoten weitergeleitet wird.
- Die Sicherung wird im eingeschränkten Modus ausgeführt, da das Kernelmodul nicht geladen werden konnte. Das tritt in der Regel auf, wenn das Betriebssystem eine nicht unterstützte Version ist.
- Wenn cbt_server oder AAMService während der Sicherung angehalten wird, können keine Bitmaps abgerufen werden und der Sicherungsjob wird im Low-Splash-Modus ausgeführt.
Wenn der AAMService nicht sehr lange ausgefallen ist, sind nach dem Starten des AAMService Bitmaps für eine normale Sicherung verfügbar.
- Wenn cbt_server oder AAMService so lange angehalten wird, dass einige Gigabyte an Ereignissen vom Treiber in die Warteschlange gestellt werden, können die Bitmaps nicht neu erstellt werden und die Sicherung wird im Low-Splash-Modus ausgeführt. Wie lange das dauert, hängt davon ab, wie viel Laufwerk-E/A für die Datenbank ausgeführt wird. Das führt in der Regel zu einer mehrtägigen AAMService-Ausfallzeit.
- Wenn der cbt_server oder AAMService nicht ordnungsgemäß heruntergefahren wird, können derzeit geladene Bitmaps unzuverlässig werden. Bitmaps werden geladen, wenn in den letzten 15 Minuten in die erfasste Datei geschrieben wurde. Bei einer aktiven Datenbank führt dies in der Regel zu einem kurzen Splash-Screen.
- Wenn ein Volume mit einer erfassten Datei (z. B. einer SQL-Server-MDF-Datei) auf dem Host getrennt und dann wieder bereitgestellt wird, sind die Bitmaps nicht zuverlässig, da nicht bekannt ist, was in die Datei geschrieben wurde, während sie getrennt war.