News zu Oracle
Immer wieder steht der durch das Backup benötigte Speicherplatz im Fokus der Bestrebungen wertvolle Plattenkapazitäten freizuschaufeln. 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äftigen 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ückgreifen. Sicherst du deine Datenbanken via SBT_TAPE-Treiber, richtet sich der Artikel explizit nicht an dich.
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 Oracle 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
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.
| Legende | Kompressionszenario (Backup auf ein NFS-Share, das ein ext4- oder btrfs-formatiertes Filesystem präsentiert) | Backup in min | Restore in min | Größe des Backups in GB |
| RMAN uncomp | RMAN unkomprimiert auf unkomprimiertes ext4 | 00:45 | 00:35 | 3.99 |
| RMAN basic | RMAN BASIC-Compression auf unkomprimiertes ext4 | 02:06 | 02:36 | 0.64 |
| RMAN basic LO | RMAN BASIC-Compression auf unkomprimiertes ext4 (load optimized) | 02:05 | 02:35 | 0.78 |
| RMAN low | RMAN LOW-Compression auf unkomprimiertes ext4 | 00:15 | 00:25 | 0.90 |
| RMAN low LO | RMAN LOW-Compression auf unkomprimiertes ext4 (load optimized) | 00:35 | 00:26 | 1.13 |
| RMAN medium | RMAN MEDIUM-Compression auf unkomprimiertes ext4 | 00:25 | 00:25 | 0.75 |
| RMAN medium LO | RMAN MEDIUM-Compression auf unkomprimiertes ext4 (load optimized) | 01:15 | 00:35 | 0.92 |
| RMAN high | RMAN HIGH-Compression auf unkomprimiertes ext4 | 06:05 | 01:56 | 0.53 |
| RMAN high LO | RMAN HIGH-Compression auf unkomprimiertes ext4 (load optimized) | 08:17 | 02:26 | 0.66 |
| btfrs ZLIB | RMAN unkomprimiert auf btrfs mit compress-force1=ZLIB gemountet | 00:35 | 00:26 | 0.94 |
| btrfs LZO | RMAN unkomprimiert auf btrfs mit compress-force=LZO gemountet | 00:25 | 00:25 | 1.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.
Spätestens in der grafischen Darstellung ist zu erkennen, dass es augenscheinlich kaum Argumente für RMAN-Komprimierung gibt. Selbst die kostenpflichtigen Algorithmen der Oracle Enterprise Edition (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 Oracle Standard Edition (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
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.
Share this article