Wenn man für die Sicherung von Oracle Datenbanken rman in Verbindung mit den brtools von SAP nutzt ist das eine feine Sache. Die Architektur ist ausgereift, ermöglicht inkrementelle Datenbankbackups und bietet noch einige Vorteile mehr.
Ein großer Nachteil beim Einsatz von rman ist jedoch die Sicherung der Archivelogs mit dem brtool brachive. Hier wird nämlich eine Bestandsaufnahme der zum Start der Archivelogsicherung zu sichernden Archivelogs vorgenommen und die Dateien erst dann gelöscht, wenn die letzte Archivelogdatei erfolgreich gesichert wurde. Dies stellt gerade dann ein Problem dar, wenn das System kurz vor einem Archiverstuck steht und die zu sichernde Datenmenge das Backuptool vor eine große Herausforderung stellt. Es kann auch passieren, dass die Archivesicherung abbricht, nachdem bereits einige 100 Gigabyte in das Sicherungstool übertragen worden sind – die bereits gesicherten Dateien werden nämlich dann nicht gelöscht, da der komplette rman Aufruf als solches ja nicht erfolgreich war. Bei der nächsten Archivesicherung werden die Dateien dann erneut übertragen und währenddessen füllt sich die Archivedestination munter weiter.
Das rman Verhalten lässt sich jedoch über einen undokumentierten Parameter in der init<SID>.sap beeinflussen. Hierzu muss man lediglich den Parameter „_rman_grp_cnt =“ setzen.
Stellt man diesen Parameter auf 10, so werden um beim Beispiel von brarchive zu bleiben nach dem erfolgreichen Sichern von 10 Archivelogs diese auch direkt gelsöcht, egal ob noch weitere Archivelogs zu sichern sind. Wenn also 88 Archivelogs im /oracle/<SID>/oraarch liegen und die Sicherung per brarchive und rman gestartet wird, dann löscht rman nach 10 erfolgreich gesicherten Archivelogs diese auch direkt und wartet nicht ab, bis alle 88 Archivelogs gesichert wurden. Dies passiert, da es nicht mehr nur noch einen rman-Aufruf gibt, sondern diese entsprechend der Konfiguration in mehrere (hier 10) aufgeteilt werden. Sofern der einzelne rman Aufruf für das sichern der 10 Dateien erfolgreich war werden diese auch gelöscht. Über den Parameter „_util_grp_cnt=“ kann man die backint-Aufrufe selbst unterteilen.
Für die brtools bleibt alles beim Alten. Es bleibt bei einer gestarteten Sicherung mit entsprechend einem Logfile. Es werden quasi die „Häppchen“, die rman am Stück verarbeitet lediglich verkleinert. Dies geschieht übrigens auch bei einem Backup der Datenbank. Der Vorteil hier liegt klar auf der Hand – bei einem Fehler im Backuptool sind dann nicht alle gesicherten Files invalid, sondern lediglich die Charge, die aktuell vom rman gesichert wird, wärhend der Fehler auftritt. Die bereits erfolgreich gesicherten Dateien können dann zum Beispiel für ein Fill-up genutzt werden und müssen bei einem Nachstarten des Backups nicht wieder komplett gesichert werden. Man spart also Zeit und Volumen im Backuptool. Gerade für Datenbanken mit mehreren Terrabyte an Volumen eine echte Erleichterung bzgl. des Backup Handlings.
Weitere Informationen gibt es in der SAP Note 1129197.
Wenn man eine Datenbank mit 1200 Datenfiles hat und die Werte wie folgt einsetzt passiert grob Folgendes bei einem Backup:
_util_grp_cnt= 10 _rman_grp_cnt = 20
brbackup startet das Backup und initiiert die backint Schnittstelle.
Die 1200 Datenfiles der Datenbank werden in 10 backint Aufrufe a 120 Dateien aufgeteilt. Würde man brbackup mit der Option „-abort stop“ aufrufen würden die 120 Dateien aus dem aktuell laufenden backint Block noch gesichert werden und das Backup anschließend sauber beendet werden. Die 120 Dateien aus einem backint Block Augruf werden nun von rman in Chargen zu je 20 Dateien gesichert. rman wird also von backint alle 20 Dateien erneut gestartet und parametrisiert. Kommt es zu einem Fehler während der Sicherung (Medialayer, Netzwerk, Ausfall des Backuptools) sind also nicht x von 1200 Dateien des Backups, die bereits gesichert wurden, als invalid gekennzeichnet, sondern lediglich die Dateien, die in der aktiven 20er Charge des rman Aufrufs nicht gesichert werden konnten.
Es reicht übrigens aus die Parameter einfach in die initSID.sap einzufügen. Wird im Anschluss ein brarchive oder brbackup gestartet sind die Parameter direkt aktiv und verwendet. Während eines laufenden Datenban-Backups oder wenn brarchive mit der Option -f gestartet wurde haben die Parameter keinen Einfluss auf das Verhalten der backinit oder rman Schnittstelle.