Ein RMAN-Backup mit mehreren Channels ist nicht automatisch für jede einzelne Datei parallelisiert. Enthält eine Tablespace nur ein sehr großes Datafile, kann dieses zum Laufzeit-Flaschenhals werden, während zusätzliche Kanäle wenig beitragen. Mit einem Multisection-Backup lässt sich die Datei in zusammenhängende Blockbereiche aufteilen, die RMAN auf mehrere Channels verteilen kann.
SECTION SIZE die Auslastung verfügbarer Kanäle verbessern. Bei vielen kleinen Dateien oder einem bereits ausgelasteten Storage ist der Effekt oft geringer.Kanäle und Section-Größe festlegen
Die Geräteparallelität muss genügend Channels bereitstellen. Anschließend gibt SECTION SIZE an, wie groß die Abschnitte eines Datafiles sein sollen. Ein beispielhafter Startpunkt für einen Disk-Backup-Lauf:
CONFIGURE DEVICE TYPE DISK PARALLELISM 4;
BACKUP SECTION SIZE 32G
DATABASE;Die passende Größe hängt von Datei- und Datenmenge, Storage-Durchsatz, Channel-Zahl sowie dem zulässigen Backup-Fenster ab. Sehr kleine Sections erzeugen viele Einheiten und Verwaltungsaufwand; sehr große Sections begrenzen den möglichen Parallelismus. Oracle begrenzt die Aufteilung auf höchstens 256 Sections pro Datei. Section Size und MAXPIECESIZE können nicht gemeinsam in derselben Backup-Operation angegeben werden.
Nicht nur Laufzeit messen
Ein schnellerer Backup-Lauf ist nur dann ein Gewinn, wenn er die Produktions-I/O nicht übermäßig belastet und die erzeugten Backups ins Recovery-Konzept passen. Vergleichen Sie Laufzeit, Kanal-Auslastung, Storage-Latenz und Backup-Fenster vor und nach dem Pilot. Testen Sie mit einer repräsentativen großen Datei und kontrollieren Sie auch Restore-Dauer und Medienmanager-Verhalten.
Ob ein Backup-Set tatsächlich multisection ist, zeigt die Repository-View V$BACKUP_SET. Die Spalte MULTI_SECTION ist dafür ein direkter Prüfpunkt:
SELECT recid, set_stamp, multi_section, pieces
FROM v$backup_set
ORDER BY completion_time DESC;Bei einem abgebrochenen Multisection-Backup kann RMAN Metadaten zu einem partiellen Backup-Set hinterlassen. Solche Teil-Sets gelten nicht als Restore-Kandidaten; prüfen Sie den Job-Output und bereinigen Sie unvollständige Artefakte gemäß dem RMAN-Runbook, statt sie als erfolgreiche Sicherung zu zählen.
Praktische Einführung
- Große Datafiles und die tatsächliche Engstelle im aktuellen Backup identifizieren.
- Channel-Parallelität mit den Grenzen von CPU, Storage und Medienmanager abgleichen.
- Section-Größe für eine repräsentative Datei testen und Laufzeit sowie Nebenwirkungen messen.
V$BACKUP_SET.MULTI_SECTION, RMAN-Logs und vollständigen Jobstatus prüfen.- Restore-Probe für das resultierende Backup-Format einplanen und den neuen Ablauf dokumentieren.
Fazit
RMAN-Multisection-Backups lösen einen speziellen Engpass: Sie machen ein einzelnes großes Datafile für mehrere Channels bearbeitbar. Der Parameter ist kein pauschaler Beschleunigungsschalter. Erst eine gemessene Section-Größe, passende Channel-Kapazität und ein erfolgreich getesteter Restore zeigen, ob das Verfahren im eigenen Backup-Fenster wirklich hilft.
Weiterführend: Oracles Anleitung zum Aufteilen großer Datafiles in RMAN-Sections, die BACKUP-Referenz und die Referenz zu V$BACKUP_SET.