Was ist eine Sicherung mit geringem Spritzwasser?
Auf einer Backup- und DR-Sicherungs-/Wiederherstellungs-Appliance führt Backup und DR unter normalen Umständen eine zeitaufwendige erste vollständige Sicherung einer Datenbank durch. Alle nachfolgenden Sicherungen sind dann viel schnellere inkrementelle Sicherungen. Bei einer inkrementellen Sicherung werden Bitmaps des aktuellen Snapshots und des vorherigen Snapshots verglichen und nur die inkrementellen Änderungen angewendet.
Eine Low-Splash-Sicherung ist eine spezielle Art von Sicherungsjob, die auftritt, wenn ein Systemfehler im vorherigen Sicherungsjob zu einem unzuverlässigen Bitmap-Image oder einer Unfähigkeit zum Lesen der Bitmap führt. Der Dienst, der die Bitmap liest, ist cbt_server in einer Linux-Umgebung und AAMService in einer Windows-Umgebung.
Sicherungen mit geringer Änderungsrate sind zeitaufwendiger als Sicherungen unter normalen Bedingungen, da eine vollständige Aufnahme erforderlich ist, um eine zuverlässige Bitmap neu zu erstellen. Anschließend können die inkrementellen Änderungen angewendet werden, ohne dass die Vollsicherung ersetzt werden muss.
Dinge, die keine Backups mit geringem Splash verursachen
- Connector-Upgrades
- Ordnungsgemäße Systemneustarts
- Ordnungsgemäße Neustarts von cbt_server oder AAMService, vorausgesetzt, der Dienst wird zum Zeitpunkt der Sicherung noch ausgeführt
Failover, bei denen die Fehler, die zu unzuverlässigen Bitmaps führen, nicht aufgetreten sind.
Ursachen für unzuverlässige Bitmaps
Eine unzuverlässige Bitmap tritt auf, wenn der Sicherungsjob unterbrochen wird, z. B. durch Folgendes:
- Ein unsauberes Herunterfahren des Hosts:
- Ein nicht ordnungsgemäßes Herunterfahren führt aufgrund der Unzuverlässigkeit von Bitmaps zu einem Low-Splash. Dazu gehören das Trennen der Stromversorgung eines physischen Computers oder jede andere Methode zum Ausschalten von Windows ohne ordnungsgemäßes Herunterfahren oder ein Bluescreen-Fehler. Das gilt auch, wenn ein Computer in einem Cluster einen Bluescreen-Fehler hat, der ein Failover auslöst, da die Bitmap des ausgefallenen Computers unzuverlässig ist.
- Wenn alle Windows-Server in einem Cluster, auf denen die Datenbank seit der vorherigen Sicherung gehostet wurde, nicht verfügbar sind und den Backup und DR-Agent ausführen. Wir rufen Bitmaps von jedem Clusterhost ab, auf dem die Datenbank seit der vorherigen Sicherung gehostet wurde, um Änderungen zu finden. Ohne alle Bitmaps müssen wir Low-Splash ausführen, um die Datenintegrität zu wahren. Wenn ein Clusterhost, auf dem eine Datenbank gehostet wurde, einen Bluescreen (BSOD) hat, ist die Bitmap möglicherweise bei der Sicherung verfügbar, aber dennoch unzuverlässig. Daher ist eine Low-Splash-Wiederherstellung erforderlich.
- Ein fehlgeschlagenes Kernelmodul-Update
- Ein Absturz oder Neustart im Daemon des Nutzermodus
- Ein Fingerabdruckfehler beim Ausführen einer Sicherung. (Backup und DR führt für jeden Sicherungsjob eine „Fingerabdruckprüfung“ durch, um nach Fehlern zu suchen.)
- Fehler beim Vaulting, 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 kann. Das ist normalerweise der Fall, wenn das Betriebssystem eine nicht unterstützte Version ist.
- Wenn cbt_server oder AAMService während der Sicherung beendet 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 befindet sich im Low-Splash-Modus. Wie lange dies dauert, hängt davon ab, wie viele Laufwerk-E/A-Vorgänge in der Datenbank ausgeführt werden. Dies erfordert in der Regel mehrere Tage Ausfallzeit des AAMService.
- Ein nicht ordnungsgemäßes Herunterfahren des cbt_server oder AAMService kann dazu führen, dass Bitmaps für alle derzeit geladenen Bitmaps unzuverlässig werden. Bitmaps werden geladen, wenn die verfolgte Datei in den letzten 15 Minuten beschrieben wurde. Bei einer stark ausgelasteten Datenbank führt dies im Allgemeinen zu geringen Auswirkungen.
- Wenn ein Volume, das eine verfolgte Datei enthält (z. B. eine SQL Server-MDF-Datei), auf dem Host deaktiviert und dann wieder aktiviert wird, sind die Bitmaps unzuverlässig, da nicht bekannt ist, was in die Datei geschrieben wurde, während sie deaktiviert war.