Oracle - Logo white
PostgreSQL_Datenbank - Logo Elephant white
Microsoft SQL Server - Logo white
News zu Oracle

Make backup compression great again

Immer wieder steht der durch das Backup benötigte Speicherplatz im Fokus der Bestrebungen wertvolle Plattenkapazitäten freizu­schaufeln. Insbesondere für größere Oracle Datenbanken kommt im nächsten Schritt das Thema Backup Komprimierung auf die Agenda. Aus diesem Grund wollen wir uns heute mit eben diesem Thema beschäf­tigen und einmal beleuchten, was die Vor- oder auch Nachteile eine Backup Komprimierung sind.

Unter der Überschrift “make backup compression great again” beleuchtet dieser Artikel 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ück­greifen. Sicherst du deine Datenbanken via SBT_TAPE-Treiber, richtet sich der Artikel explizit nicht an dich.

RMAN-Komprimierung pros/cons

Die Komprimierung von RMAN Backups wird gern einge­setzt 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 akzep­table Komprimierungsraten, ist aller­dings sehr langsam und CPU-intensiv. Schnellere oder besser kompri­mie­rende Algorithmen dürfen hingegen nur bei lizen­zierter Advanced Compression Option (ACO) in der Oracle Enterprise Edition (EE) benutzt werden oder bedingen die Lizenzierung von Oracle Secure Backup.

Nun ist aller­dings nicht davon auszu­gehen, dass sich viele Anwender nur wegen der Backupkomprimierung eine EE mit ACO zulegen oder ihre existie­rende Backuplösung auf Oracle Secure Backup umstellen. Auf der anderen Seite stehen einige nicht zu vernach­läs­si­gende 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 paral­lelen RMAN Backups möglich sind.

  • Der mit Abstand wichtigste Nachteil ist jedoch, dass der Restore von BASIC-kompri­mierten Backups ausge­sprochen langsam ist. Er dauert in jedem Fall länger als das Backup dauerte. Man läuft damit zwangs­läufig in das Risiko, bei der Wiederherstellung unter­neh­mens­re­le­vanter Daten wertvolle Zeit zu verlieren. Die daraus resul­tie­renden Ausfallkosten sind um ein Vielfaches höher als die ursprüng­liche Einsparung durch die Komprimierung. Schon aus diesem Grund verbieten sich daher BASIC-kompri­mierte 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ück­zu­fü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 unkom­pri­miertes RMAN-Backuppiece auf OS-Ebene mit bzip2 kompri­miert 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 kompri­mierte Backups zu erstellen. Muss man nun vernünf­ti­ger­weise komplett auf die Komprimierung der RMAN-Backups verzichten? Nein. Denn die Komprimierung muss ja nicht zwingend von RMAN durch­ge­führt werden und sie muss auch nicht auf dem Datenbankserver statt­finden. 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 bewerk­stel­ligen. Man sorgt einfach dafür, dass das Backupshare auf einem kompri­mierten 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 backup­ser­ver­sei­tigen 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 virtua­li­siert 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 kompri­mierter Backups dauert nicht mehr länger als das Backup und ist in jedem Fall um Größenordnungen schneller als das Restore eines RMAN-BASIC-kompri­mierten Backups. Check!

  • Zusätzlich stehen, je nach Filesystem, auch noch verschiedene Algorithmen kostenfrei und unabhängig von der verwen­deten 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 darge­stellt, die sowohl mit den in RMAN verfüg­baren Algorithmen als auch mit einem ZLIB- und LZO-kompri­mierten btrfs-Filesystem durch­ge­führt wurden. Gesichert und restored wurde jeweils die selbe Datenbank von ca. 40GB Größe auf ein per NFS angebun­denes Share. Dabei sollte das Augenmerk weder auf die absoluten Backup- und Restorezeiten noch auf die absoluten Komprimierungsraten gelegt werden. Die Tests fanden in einer virtua­li­sierten Testumgebung statt und die absoluten Ergebnisse sind daher eher mäßig. Der wesent­liche Punkt sind die relativen Performanceunterschiede.

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

compress-force ist obliga­to­risch, da btrfs aufgrund der ersten Bytes des Backuppieces recht zuver­lässig zu dem Trugschluss kommt, dass sich eine Komprimierung des gesamten Files nicht lohnt. Ohne „force“ werden die Backups dann sehr wahrscheinlich unkom­pri­miert abgelegt.

csm_dba_tipp_backup_komprimierung_2019-11_f000234292.png
Abbildung: Backup Komprimierung in der Übersicht

Spätestens in der grafi­schen Darstellung ist zu erkennen, dass es augen­scheinlich kaum Argumente für RMAN-Komprimierung gibt. Selbst die kosten­pflich­tigen Algorithmen der Oracle Enterprise Edition (EE) schneiden nicht signi­fikant besser ab als die kosten­freien auf dem Backupserver verwen­deten Algorithmen, die zudem noch für alle Editionen verwendbar sind.

Für Nutzer der Oracle Standard Edition (SE) ist zusätzlich beach­tenswert, dass mit BASIC-kompri­mierten Backups der relative Zeitaufwand für den Restore ggü dem Backup noch deutlich höher sein wird als oben darge­stellt. Die hier dokumen­tierten Tests wurden auf einer EE durch­ge­fü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 grund­sä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 signi­fikant 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 kompri­mie­rendes Filesystem über NFS präsen­tieren 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.

Hier findest du weitere News, Updates und Insights rund um das Thema “Backup und Recovery” von Datenbanken 
icon-arrow_right_medium-violet-blue.svg

Share this article

Share on facebook
Facebook 
Share on twitter
Twitter 
Share on linkedin
LinkedIn 
Share on xing
XING 
Share on whatsapp
WhatsApp 
Share on email
Email