Make backup compression great again

In den meisten Fällen scheint es also keine gute Lösung zu sein, mit RMAN komprimierte Backups zu erstellen. Muss man nun vernünftigerweise komplett auf die Komprimierung der RMAN-Backups verzichten? Nein. Denn die Komprimierung muss ja nicht zwingend von RMAN durchgeführt werden und sie muss auch nicht auf dem Datenbankserver stattfinden. Bei Backups über SBT_TAPE-Libraries wird ja in der Regel auch die Komprimierung der Backupsoftware oder ‑hardware genutzt. Das lässt sich genau so einfach bei RMAN-Backups auf Shares bewerkstelligen. Man sorgt einfach dafür, dass das Backupshare auf einem komprimierten Filesystem angelegt wird. Das ist für Shares auf Windowsservern (NTFS compression), auf Solaris ZFS und auch auf Linux mit dem btrfs-Filesystem möglich.

Greifen wir nochmal die Nachteile der RMAN-Komprimierung auf und betrachten sie im Lichte einer backupserverseitigen Komprimierung:

• Die Backupkomprimierung belastet die CPUs des Backupservers, nicht des Datenbankservers. Check!

• Das Hinzufügen von CPU-Leistung verletzt keine Oracle-Lizenz-Limitierungen und zwingt auch nicht zum Nachkauf von Oracle-Lizenzen. Wenn der Backupserver virtualisiert ist, ist das ggf nicht einmal mit einer Hardwarenachrüstung verbunden. Check!

• Die Komprimierungslast wird von der Filesystemkomprimierung meist schon selbständig über mehrere CPUs verteilt. Zumindest war das bei der btrfs-Komprimierung der Fall. Check!

• Der Restore selbst hoch komprimierter Backups dauert nicht mehr länger als das Backup und ist in jedem Fall um Größenordnungen schneller als das Restore eines RMAN-BASIC-komprimierten Backups. Check!

• Zusätzlich stehen, je nach Filesystem, auch noch verschiedene Algorithmen kostenfrei und unabhängig von der verwendeten Datenbank Edition zur Auswahl. Je nach Bedarf kann somit ein gutes Maß zwischen Backupzeit und Komprimierungsrate gewählt werden. Check!

Zur Veranschaulichung der Unterschiede werden nachfolgend verschiedene Testläufe dargestellt, die sowohl mit den in RMAN verfügbaren Algorithmen als auch mit einem ZLIB- und LZO-komprimierten btrfs-Filesystem durchgeführt wurden. Gesichert und restored wurde jeweils die selbe Datenbank von ca. 40GB Größe auf ein per NFS angebundenes Share. Dabei sollte das Augenmerk weder auf die absoluten Backup- und Restorezeiten noch auf die absoluten Komprimierungsraten gelegt werden. Die Tests fanden in einer virtualisierten Testumgebung statt und die absoluten Ergebnisse sind daher eher mäßig. Der wesentliche Punkt sind die relativen Performanceunterschiede.

compress-force ist obligatorisch, da btrfs aufgrund der ersten Bytes des Backuppieces recht zuverlässig zu dem Trugschluss kommt, dass sich eine Komprimierung des gesamten Files nicht lohnt. Ohne „force“ werden die Backups dann sehr wahrscheinlich unkomprimiert abgelegt.