Data Pump in Oracle Database 12c: die wichtigsten Neuigkeiten

Letztes Jahr hat Oracle CEO Larry Ellison während der Oracle OpenWorld in San Francisco ein neues Datenbank Release angekündigt, das nun endlich zur Verfügung steht. In diesem Blogbeitrag möchte ich einige der wichtigsten Data Pump-Neuigkeiten vorstellen. Eine komplette Übersicht der Features finden Sie in Oracles Dokument „Oracle Database Utilities“. Fangen wir an mit dem riesen Hype von Oracle 12c!

Oracle 12c Pluggable Databases (PDB): wie soll ich mit diesem Feature umgehen?

In Oracle Database 12c Release 1 sind weder der Export aller Pluggable Databases mittels des Root Container (CDB$ROOT) noch mittels des Pluggable Database Template (PDB$SEED) unterstützt. Falls Sie es trotzdem versuchen, erinnert Sie folgende Datapump-Meldung daran:

Gibt es vielleicht einen Data Pump PDB Parameter? Die Antwort ist etwas peinlich … Nein! Die Data Pump-PDB-Verbindung findet genauso statt wie eine Clientverbindung: über einen TNS Alias.

Bisher also nicht sehr reizvoll…

Sicherheit

Im Bereich Sicherheit gibt es einige Neuigkeiten. Dank des Oracle 12c New Features “Unified Audit Policies” ist es möglich, alle Data-Pump-Operationen zu auditieren. Leider stellen wir fest, dass auch hier nicht alles korrekt funktioniert: Das Resultat nach “Audit Policy” zu filtern, ist unmöglich. Aber weswegen? Sieht man im Feld „UNIFIED_AUDIT_POLICIES“ nach, wo laut Dokumentation die Policy-Namem stehen sollten, findet man keine Einträge:

Ein anderer Sicherheitsaspekt ist das Verschlüsseln des DUMPFILE mit einem Passwort. Dies ist keine Neuigkeit, allerdings musste man früher beim Export das Passwort auf der Kommandozeile in Klartext eintippen. Oracle Datapump 12c erlaubt jetzt, dieses Passwort verschlüsselt abzufragen. Dank des Parameters „ENCRYPTION_PWD_PROMPT“:

Besser, oder?

Komprimierung

Verschlüsselung und Komprimierung sind Themen, die meist zusammen betrachtet werden. Jeder von uns hatte schon mal zu wenig Plattenplatz für einen Data-Pump-Export und sicher auch den Wunsch, einen Komprimierungsalgorithmus zu wählen – genauso wie bei RMAN in Oracle 11g. Ab Oracle 12c Release 1 ist es nun möglich: Dank des Parameters „COMPRESSION_ALGORITHM“ (Default BASIC).

• BASIC: Bester Kompromiss zwischen Komprimierungsfaktor und Leistung (Oracle 11g Komprimierungsalgorithmen)
• LOW: Niedrigste CPU-Beanspruchung (bei limitierten CPU-Ressourcen)
• MEDIUM: Identisch mit BASIC – ein anderer Algorithmus
• HIGH: Laut der Dokumentation geeignet für Umgebungen mit limitierter Netzwerkbandbreite. Die CPU der Instanz wird hier am meisten beansprucht.

Es wäre an diese Stelle nicht sinnvoll, die Testresultate vollständig zu präsentieren, da der Komprimierungsfaktor und die Lauzeiten stark von den Daten abhängig sind. Während unserer Tests haben wir einen Komprimierungsfaktor von bis zu Faktor 10 erreicht. Je nach Algorithmus wurde die CPU des Datenbankservers deutlich mehr oder weniger belastet.

Beachten Sie, dass der Parameter „COMPRESS_ALGORITHM“ nur den Algorithmus bestimmt. Der Typ der zu komprimierenden Daten hängt vom Parameter „COMPRESSION“ ab.

Beachten Sie auch, dass die Komprimierung kostenpflichtig ist. (Teil der „Oracle Advanced Compression“ Option).

Performance

Last, but not least: Performance. Oracle bietet an, durch die Import-Klausel „TRANSFORM“ Tabellen und/oder Indizes mit NOLOGGING zu importieren. Dies soll eigentlich den ganzen Redo-Mechanismus entlasten (Log-Buffer, Redo-Logs, Archivelogs). Der versprochene Effekt dieses Features wurde durch unsere Tests allerdings nur teilweise bestätigt:

Nachprüfbar wurden beim Import nur Indizes mit NOLOGGING erstellt (unabhängig von Indextyp, B-Tree, BitMap). Erst nach dem Datenimport wurden die Indizes auf LOGGING gesetzt. Obwohl es zu erwarten wäre, traf diese Beobachtung für Tabellen nicht zu.

Wir haben die Werte von V$SYSSAT vor und nach dem Import verglichen: Der Unterschied mit und ohne DISABLE_ARCHIVE_LOGGING war nicht nennenswert:

Klar ist, dass die Erstellung und Wartung eines Indexes weniger Logging beansprucht, als dies bei den Daten selbst der Fall ist. Wir möchten Sie ermutigen, selbst mit Datapump zu experimentieren.

DDL für Tabellen und Indexes können sehr einfach mittels des Data Pump Parameters SQLFILE in einem erzeugtem SQL-Skript analysiert werden.

Achtung! DISABLE_ARCHIVE_LOGGING hat keine Auswirkung, falls die Datenbank im FORCE LOGGING läuft.

Sonstiges

Eine weitere Oracle Datapump 12c Neuigkeit ist der Export-Parameter „VIEWS_AS_TABLES“.

Wie der Parametertitel es bereits andeutet, können Views als Tabellen exportiert werden.

Im Hintergrund wird beim Export eine temporäre Tabelle erzeugt, um die Metadaten (Data Definition Language) zu exportieren. Diese Tabelle kann auch durch eine benutzerdefinierte Tabelle ersetzt werden, wie im folgenden Beispiel. Der Begriff „temporär“ bezeichnet keine „Global Temporary“ Tabelle, sondern ein normale heap-organized Tabelle, die nach dem Export gelöscht wird.

Durch folgende DDL verhinderen wir Null-Werte in der ID-Spalte und vergrössern auch die Spaltenlänge in der “Temporäre” Tabelle:

Wir exportieren der Inhalt der View:

Nach dem Export sollte die Temporäre Tabelle gelöscht werden:

Beim Import benennen wir die Tabelle auf “new_table_1” um:

Et voilà, die neue Definition der Tabelle:

Zum Schluss möchten wir den neuen Parameter „LOGTIME“ erwähnen. Diesen finde ich besonders hilfreich, weil er bei jedem Data-Pump-Schritt ein Zeitstempel im Output einfügt:

Data Pump wurde in verschiedenen Bereichen ergänzt. Daher empfehlen wir, einen Blick auf das “Oracle Database Utilities”-Dokument zu werfen. Denn, wie schon erwähnt, die obigen Features sind nur ein Teil der Neuigkeiten. Ob Ihnen diese Features wirklich alle reif erscheinen, müssen Sie schlussendlich selber beurteilen.

Viel Spass mit Oracle 12c 🙄