Hot-Backup bedeutet, dass das System betriebsbereit ist und Updates wie gewohnt durchgeführt werden
Ich würde hier den Mechanismus erklären, der von Oracle verfolgt wird, wenn wir eine Hot-Sicherung durchführen
Manuelles Hotbackup
Manueller Hotbackup-Start mit dem folgenden Befehl für einen Tablespace
Tabellenbereich ändern BENUTZER beginnen Sicherung;
Wenige Dinge passieren zu dieser Zeit
1)DBWn checkpoints den Tablespace (schreibt alle schmutzigen Blöcke ab einem bestimmten SCN aus)
2)CKPT stoppt die Aktualisierung des Prüfpunkt-SCN-Felds in den Datendatei-Headern und beginnt stattdessen mit der Aktualisierung des Hot-Backup-Prüfpunkt-SCN-Felds
Die Datendatei-Header, die die SCN des letzten abgeschlossenen Prüfpunkts enthalten, werden nicht aktualisiert, während sich eine Datei im Hot-Backup-Modus befindet . Dadurch kann der Wiederherstellungsprozess nachvollziehen, welche Archiv-Redo-Log-Dateien möglicherweise benötigt werden, um diese Datei vollständig wiederherzustellen.
3) LGWR beginnt mit der Protokollierung vollständiger Images geänderter Blöcke, wenn ein Block zum ersten Mal geändert wird, nachdem er von DBWn geschrieben wurde Protokolldateien wiederholen, nicht nur die geänderten Bytes. Normalerweise werden nur die geänderten Bytes (ein Redo-Vektor) geschrieben. Im Hot-Backup-Modus wird beim ersten Mal der gesamte Block protokolliert. Dies liegt daran, dass Sie in eine Situation geraten können, in der der Prozess, der die Datendatei kopiert, und der DBWR gleichzeitig an demselben Block arbeiten.
Nehmen wir an, dass dies der Fall ist und der OS-Blockierungs-Lesefaktor 2K beträgt. Das Sicherungsprogramm liest einen 8k-Oracle-Block. Das Betriebssystem gibt 4k aus. In der Zwischenzeit hat DBWR darum gebeten, diesen Block neu zu schreiben. Das Betriebssystem plant, dass der DBWR-Schreibvorgang jetzt ausgeführt wird. Der gesamte 8k-Block wird neu geschrieben. Das Sicherungsprogramm beginnt erneut zu laufen (hier Multitasking-Betriebssystem) und liest die letzten 4k des Blocks. Das Sicherungsprogramm hat jetzt einen gebrochenen Block bekommen – Head und Tail stammen von zwei Zeitpunkten.
Oracle kann damit während der Wiederherstellung nicht umgehen. Daher protokollieren wir das gesamte Block-Image, damit dieser Block während der Wiederherstellung von Redo vollständig neu geschrieben wird und zumindest mit sich selbst konsistent ist. Wir können es von dort wiederherstellen.
Wichtiger Punkt bei Hot Backup
1)Um die Auswirkungen dieser zusätzlichen Protokollierung zu begrenzen, sollten Sie sicherstellen, dass Sie jeweils nur einen Tablespace in den Backup-Modus versetzen und den Tablespace aus dem Backup-Modus holen, sobald Sie ihn gesichert haben. Dadurch wird die Anzahl der zu protokollierenden Blöcke auf das mögliche Minimum reduziert.
2) Wenn sich der Tablespace im Hotbackup-Modus befindet und die Datenbank abgebrochen wird. Und dann versuchen Sie zu starten, es wird sich über die Wiederherstellung beschweren, da die Datendatei-SCN dieses Tabellenbereichs älter sein wird. Um die Datenbank zu starten, müssen wir zuerst die Sicherung dieses Tabellenbereichs beenden. Es aktualisiert einfach den Checkpoint-SCN mit dem Hot Backup Checkpoint-SCN
Recovery Manager-Backup
Wir müssen den Tablespace nicht in den Hotbackup-Modus versetzen, um die Sicherung im Hotback-Modus zu erstellen.
Da RMAN ein Oracle-Tool ist, wissen sie, wie man mit gebrochenen Blöcken umgeht, sodass keine Blockfragmente geschrieben werden Teilblöcke in das Backup schreibt es das vollständige konsistente Block-Image auf das Backup-Medium. Der Wiederherstellungsmanager muss also nicht den vollständigen Block in der Redo-Protokolldatei aufzeichnen. Dies bedeutet also eine enorme Einsparung bei der Redo-Protokollierung bei einem manuellen Hotbackup-Fall
Außerdem friert rman den Datendatei-Header nicht ein, es fährt mit dem Checkpoint genauso fort, aber es führt einen Checkpoint zum Tablespace durch.
Die RMAN-Sicherung notiert den Start-SCN, den absoluten Fuzzy-SCN (was am Anfang derselbe ist wie der Start-SCN), wenn die Sicherung beginnt, und da die Blöcke in der Datendatei gesichert werden, werden die Blöcke auf die SCN überprüft, wenn sie höher ist als der Start SCN, Absolute Fuzzy SCN wird mit dieser Nummer aktualisiert. Dasselbe gilt für alle Blöcke, wenn die gesamte Datendatei gesichert wird, werden diese beiden Nummern im Backup-Header gespeichert.
Wann immer RMAN diese Sicherung wiederhergestellt hat, weiß es also, dass es weiß, von welchem SCN bis zum Ende es die Datendatei sicher wiederherstellen muss
Im Grunde gibt es also keinen Overhead wie eine erhöhte Protokollierung in RMAN-Hot-Backups.
Gleiches gilt für die Image-Sicherung mit RMAN
