News & Events
Make backup compression great again

Wenn die Komprimierung von RMAN-Backups gewünscht ist und der Backupserver ein komprimierendes Filesystem über NFS präsentieren kann, wird es die mit gehörigem Abstand bessere Lösung sein.

Icon Unternehmen

Der Artikel beleuchtet ausschließlich RMAN-Backups, die auf ein NFS-Share geschrieben werden. Eingeschränkt anwendbar wären die Schlussfolgerungen noch auf RMAN-Backups, die in lokale Filesysteme des Backupservers erfolgen.
RMAN-Backups via SBT_TAPE-Treiber sollten auf die Komprimierungsmechanismen (Hardwarekomprimierung etc) der 3rd-Party-Sicherungslösung zurückgreifen. Sichern Sie Ihre Datenbanken via SBT_TAPE-Treiber, richtet sich der Artikel explizit nicht an Sie.

 

RMAN-Komprimierung pros/cons

Die Komprimierung von RMAN-Backups wird gern eingesetzt bei großen Datenmengen oder einer Backup-Policy, die viele Backupdaten generiert. Der in allen Editionen der Oracle-Datenbank verfügbare BASIC-Mode – hinter dem sich der BZIP2-Algorithmus verbirgt - bietet dabei akzeptable Komprimierungsraten, ist allerdings sehr langsam und CPU-intensiv. Schnellere oder besser komprimierende Algorithmen dürfen hingegen nur bei lizenzierter Advanced Compression Option (ACO) in der Enterprise Edition (EE) benutzt werden oder bedingen die Lizenzierung von Oracle Secure Backup.

Nun ist allerdings nicht davon auszugehen, dass sich viele Anwender nur wegen der Backupkomprimierung eine EE mit ACO zulegen oder ihre existierende Backuplösung auf Oracle Secure Backup umstellen. Auf der anderen Seite stehen einige nicht zu vernachlässigende Nachteile der BASIC-Compression zu Buche:

  • Der bzip2-Algorithmus ist sehr CPU-intensiv und belastet, der Natur der Sache geschuldet, die CPU des Datenbankservers, denn die Komprimierung findet auf dem Datenbankserver statt.
  • Das Hinzufügen von CPU-Leistung ist praktisch meist unmöglich, weil Limitierungen der SE2 oder Lizenzkosten der EE dem entgegen stehen.
  • Die Komprimierungslast kann, abgesehen von der EE, nicht über mehrere CPUs verteilt werden, da keine parallelen RMAN-Backups möglich sind.
  • Der mit Abstand wichtigste Nachteil ist jedoch, dass der Restore von BASIC-komprimierten Backups ausgesprochen langsam ist. Er dauert in jedem Fall länger als das Backup dauerte. Man läuft damit zwangsläufig in das Risiko, bei der Wiederherstellung unternehmensrelevanter Daten wertvolle Zeit zu verlieren. Die daraus resultierenden Ausfallkosten sind um ein Vielfaches höher als die ursprüngliche Einsparung durch die Komprimierung. Schon aus diesem Grund verbieten sich daher BASIC-komprimierte Backups für Produktivumgebungen. Oracle begründet die hohe Restorezeit übrigens mit den Eigenheiten des bzip2-Algorithmus. Ob das tatsächlich stimmt oder doch eher auf eine schlechte Implementierung zurückzuführen ist, die vielleicht gar künstlich Bedarf an ACO generieren soll, dazu kann man sich grob eine eigene Meinung bilden, wenn man einfach einmal ein unkomprimiertes RMAN-Backuppiece auf OS-Ebene mit bzip2 komprimiert und wieder dekomprimiert:
     

$ ls -lh 48ug2ac7_1_1
-rw-r----- 1 oracle oinstall 3.8G Nov  4 21:52 48ug2ac7_1_1
$ time bzip2 -z 48ug2ac7_1_1 # compress

real    7m54.258s
user    7m43.413s
sys     0m7.063s

$ time bzip2 -d 48ug2ac7_1_1.bz2 # uncompress

real    2m19.838s
user    2m5.495s
sys     0m10.851s

 

Alternative

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 Database 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.

LegendeKompressionszenario (Backup auf ein NFS-Share, das ein ext4- oder btrfs-formatiertes Filesystem präsentiert)Backup in minRestore in minGröße des Backups in GB
RMAN uncompRMAN unkomprimiert auf unkomprimiertes ext400:4500:353.99
RMAN basicRMAN BASIC-Compression auf unkomprimiertes ext402:0602:360.64
RMAN basic LORMAN BASIC-Compression auf unkomprimiertes ext4 (load optimized)02:0502:350.78
RMAN lowRMAN LOW-Compression auf unkomprimiertes ext400:1500:250.90
RMAN low LORMAN LOW-Compression auf unkomprimiertes ext4 (load optimized)00:3500:261.13
RMAN mediumRMAN MEDIUM-Compression auf unkomprimiertes ext400:2500:250.75
RMAN medium LORMAN MEDIUM-Compression auf unkomprimiertes ext4 (load optimized)01:1500:350.92
RMAN highRMAN HIGH-Compression auf unkomprimiertes ext406:0501:560.53
RMAN high LORMAN HIGH-Compression auf unkomprimiertes ext4 (load optimized)08:1702:260.66
btfrs ZLIBRMAN unkomprimiert auf btrfs mit compress-force1=ZLIB gemountet00:3500:260.94
btrfs LZORMAN unkomprimiert auf btrfs mit compress-force=LZO gemountet00:2500:251.43

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.

Backup Komprimierung in der Übersicht

Spätestens in der grafischen Darstellung ist zu erkennen, dass es augenscheinlich kaum Argumente für RMAN-Komprimierung gibt. Selbst die kostenpflichtigen Algorithmen der EE schneiden nicht signifikant besser ab als die kostenfreien auf dem Backupserver verwendeten Algorithmen, die zudem noch für alle Editionen verwendbar sind.

Für Nutzer der SE ist zusätzlich beachtenswert, dass mit BASIC-komprimierten Backups der relative Zeitaufwand für den Restore ggü dem Backup noch deutlich höher sein wird als oben dargestellt. Die hier dokumentierten Tests wurden auf einer EE durchgeführt. RMAN führt bei EE im Gegensatz zur SE zusätzlich ein s.g. unused block compression durch. Das heißt, die EE sichert grundsätzlich keine leeren Blöcke. Die SE hingegen lässt bei der Sicherung nur Blöcke aus, die noch nie belegt waren (s.g. null compression). Fragmentierung in Extents schlägt also in der SE bei RMAN-Sicherungen zusätzlich signifikant zu Buche, während sie in der EE in dem Fall irrelvant ist. Details hierzu findet man in der MOS Note Doc ID 563427.1

Fazit

Wenn die Komprimierung von RMAN-Backups gewünscht ist und der Backupserver ein komprimierendes Filesystem über NFS präsentieren kann, wird es die mit gehörigem Abstand bessere Lösung sein, die Komprimierung vom Backupserver erledigen zu lassen, nicht vom RMAN. Bietet das Backupshare dieses Feature nicht an, sollte man auf Backupkomprimierung besser ganz verzichten. Auch wenn die Kosten für den Backupspace dann höher sind. Spätestens wenn ein Restore nötig wird, werden sich die Kosten durch den zum Teil enormen Zeitgewinn schnell amortisieren.


Newsletter-Archiv