Home > technisches Webinar > Unnötige Optionen in der Oracle DB vermeiden

Unnötige Optionen in der Oracle DB vermeiden

Dieses Webinar finden Sie auch auf unserem Youtube Webinar Channel.

DB Masters Webinar: Warum soll man unnötige Optionen in der Oracle DB vermeiden?

In diesem Webinar behandel wir, welche Optionen im Data Dictionary vorhanden sind, gehen auf den Security Aspekt ein, behandeln die Abhängigkeiten zwischen Optionen und erklären wie man Optionen auch wieder los wird.

Warum ist es relevant, welche Datenbank Optionen im Data Dictionary vorhanden sind?

Security Footprint

Bei jedem Critical Patch Update liefert Oracle neben den entsprechenden CVE-Nummern auch die entsprechende Risikoeinschätzungen sowie die Information, in welchem Bereich der Datenbank der Fehler angesiedelt ist. Wenn man in der Datenbank alle Optionen installiert hat, ist man somit auch von allen Security Lücken betroffen. Bei genauerer Betrachtung in welchen Bereichen es Lücken mit hohem Risiko gibt, stellt man oft fest: Meist ist es nicht der Datenbank Kern, sondern eine der verschiedenen Optionen.

Nutzt man die Optionen nicht und sind diese auch nicht in der Datenbank vorhanden, kann man so manchen CPU einfach auslassen, ohne ein höheres Sicherheitsrisiko einzugehen.

Laufzeiten für Create Database, Patching und Upgrades

Neben dem Security Footprint ist vor allem die Laufzeit für das Erzeugen, Patchen und Updaten von Datenbanken ein Faktor, der nicht zu unterschätzen ist. Speziell wenn man plant, die Multitenant Option - ab Oracle 20c ist diese verpflichtend - zu nutzen. Diese verlängert die Laufzeiten für solche Tätigkeiten deutlich!

Wir haben mehrere Laufzeit-Benchmarks auf unterschiedlicher Hardware durchgeführt und dabei die Auswirkungen von Optionen festgestellt - dazu gleich mehr. Besonders aufwändig wird es, wenn man die OJVM Option (Java in der Datenbank) nutzt. Dazu müssen gleich mehrere Patches in das ORACLE_HOME eingespielt werden.

Laufzeit Benchmarks für Oracle Upgrade mit dbupgrade

Damit die Benchmarks vergleichbar sind, haben wir sie immer mit folgenden Memory-Einstellungen durchgeführt:

  • SGA = 8GB
  • PGA = 1GB

Im ersten Benchmark haben wir eine VM mit 2 Cores (4 Threads) auf einer Server mit Intel® Core™ i7-7700 CPU @ 3.60GHz eingesetzt und ein Upgrade von 12.2 auf 19.3 (jeweils ohne weitere CPUs) durchgeführt. Hier die Ergebnisse:

  • Oracle Enterprise Edition OHNE jegliche Optionen, NON-CDB: 21:42 Minuten
  • Oracle Enterprise Edition MIT allen Optionen, NON-CDB: 1:30:40 Stunden
  • Oracle Enterprise Edition MIT allen Optionen, 3PDBs: 3:09:31 Stunden

Der limitierende Faktor war nicht die CPU (maximal 25-30% busy), es waren die IOPS (zwischen 850 und 1250).

Im zweiten Benchmark haben wir einen Server mit AMD Ryzen Threadripper 3970X @ 3.70GHz (32 Cores, 64 Threads) mit der Datenbank auf einem RAID Array mit 4 SSDs (188.000 IOPS, 4.222 MBPS) durchgeführt. Ergebnisse:

  • Oracle Enterprise Edition OHNE jegliche Optionen, NON-CDB: 12:11 Minuten
  • Oracle Enterprise Edition MIT allen Optionen, NON-CDB: 17:10 Stunden
  • Oracle Enterprise Edition MIT allen Optionen, 1PDBs: 46:49 Stunden
  • Oracle Enterprise Edition MIT allen Optionen, 1PDBs: 47:58 Stunden

Keine limitierenden Faktoren, sowohl CPU als auch IO Subsystem waren unterfordert, das ist aktuell die Mindestlaufzeit (sofern man keine CPU mit noch höherem Takt hat).

Wie man sieht, hängt beim den Upgrades einiges von der Hardware ab (knapp Faktor 2). Viel größer sind jedoch die Auswirkungen der Optionen und ob die Multitenant Option eingesetzt wird. Der Grund für die so viel längere Dauer der Multitenant Option ist, dass zuerst die CDB, dann die PDB$SEED und zuletzt bis zu 8 PDBs gleichzeitig bearbeitet werden.

Potentielle Lizenzfallen: Was nicht installiert ist, kann man nicht nutzen!

Viele Optionen in der Datenbank werden von der Applikation nicht benötigt, und stellen somit nur eine unnötige Belastung dar. Mehr dazu in unserem Webinar DB Masters Webinar zum Thema Oracle Datenbank Optionen - Welche gibt es?.

Nicht alle Optionen haben auch Schemata oder Inhalte im Data Dictionary, zusätzlich gibt es aber auch einige Erweiterungen, die nicht als eigene Datenbank Option bezeichnet werden, sich aber im Data Dictionary befinden. Einige der Data Dictionary Componenten sind zwingend nötig (zB: CATALOG, CATPROC, XDB) und andere haben untereinander Abhängigkeiten, so dass man bei der Auswahl von Option A, auch die Option B automatisch mit installiert bekommt.

Hier eine Liste der aktuellen Oracle 19c Datenbank Komponenten mit Data Dictionary Inhalten:

  • APEX: Oracle Application Express - ein Sonderfall, verhält sich wie eine Option, ist aber offiziell keine
  • APS: OLAP Analytics Workspaces
  • CATALOG: Oracle Datenbank Data Dictionary (zwingend nötig)
  • CATPROC: Oracle Datenbank PLSQL Packages und Types (zwingend nötig)
  • CATJAVA: Oracle Datenbank Java SQL und PLSQL Wrapper
  • CONTEXT: Oracle Text
  • DV: Database Vault
  • JAVAVM: JAVA Virtual Machine
  • OLS: Oracle Label Security
  • ORADIM: Oracle Multimedia
  • OWM: Oracle Workspace Manager
  • RAC: Real Application Cluster - ab Oracle 19c automatisch mit dabei, gegebene Falles OPTION = OFF
  • SDO: Oracle Spatial
  • XDB: Oracle XML Datenbank (zwingend nötig)
  • XML: Oracle XDK
  • XOQ: Oracle OLAP API

Bezüglich der Änderungen der Lizensierung rund um die Oracle Datenbank Optionen finden Sie die aktuellen Informationen auf unserer Homepage unter Know-How / Oracle Datenbank Lizenzierung sowie im Produktupdate Webinar Oracle Datenbank Lizensierungsupdate Sommer 2020.

Vermeiden von nicht benötigten Optionen

Nicht benötigte Optionen vermeidet man am einfachsten, indem man diese bei der Datenbankerstellung einfach nicht auswählt. Dazu muss man im DBCA - Database Creation Assistant - das Datenbank Template Benutzerdefinierte Datenbank auswählen. Das ist jenes Template, bei dem die Datenbankfiles nicht im Template enthalten sind. Dann können die gewünschten Datenbank Komponenten einfach ausgewählt werden und es werden auch nur diese installiert. Sollte  später eine zusätzliche Option benötigt werden, so können diese mit dem DBCA jederzeit nachinstalliert werden. Hinweis für Oracle Standard Edition Nutzer. Nur über das Template Benutzerdefinierte Datenbank kann eine Lizenzkorrekte Datenbank erzeugt werden! Alle anderen Templates sind Enterprise Edition Datenbanken.

Löschen von nicht benötigten Optionen

Oracle liefert unter support.oracle.com nur für einige Optionen - unvollständige und fehlerhafte - Anleitungen, wie man diese Option löschen kann. Auch Mike Dietrich schreibt in seinem Block Remove and Clean Up Components from Oracle folgendes:

This series of blog posts is not meant to recommend the removal of any options from an Oracle Database. It is not meant to create any sort of negativeness on any of the components or options. It’s is only meant to give you some advice and guideline in the case you’ll need to remove something.

Hält man sich jetzt an die verschiedene Anleitungen seitens Oracle, führt das in der Regel zu:

  • Invaliden Objekte, weil nicht alles korrekt entfernt wurde.
  • EXPDP funktioniert nicht mehr, weil er versucht, nicht mehr vorhandene Optionen zu löschen.
  • Fehlende Scripts (ab Oracle 18c) um bestimmte Optionen überhaupt löschen zu können.
  • einem korrupten Data Dictionary, so dass man keine weiteren Patches oder Upgrade mehr durchführen kann.

Also bleibt nur der mühsame Weg: EXPDP, DROP DATABASE, CREATE DATABASE, IMPDP, oder?

Sicheres Löschen von nicht mehr benötigten Optionen

Wir von DB Masters haben durch aufwändige Analyse, für die verschiedene Datenbank Versionen Wege für ein sauberes löschen aller Datenbank Optionen entwickelt, beginnend mit Oracle 11.2.0.3 bis hin zu den aktuellen Oracle Releases. Zusätzlich bieten wir auch ein Script, das die aktuelle Nutzung von Datenbank Optionen analysiert und ausgibt.

Options In Use - Analyse

Mit diesem Script stellen wir fest, welche Datenbank Optionen in der jeweiligen Datenbank genutzt werden. Allerdings gibt es hier eine kleine Falle. Wenn man beim Patchen der Datenbank nach dem datapatch die Datenbank nicht neu startet, kommt es zu False Positive Meldungen, weil der datapatch im Zuge des Patchvorgangs die eine oder andere Option genutzt haben kann. In diesem Fall muss man manuell verifizieren, wann die Datenbank zuletzt gepatched wurde und mit DBA_FEATURE_USAGE_STATISTICS abgleichen, ob die Nutzung mit dem Patching zusammen fällt. Unsere Empfehlung daher, nach dem Datenbank Patching die Datenbank Instanz immer restarten.

DB Masters Serviceangebot: Löschen der nicht benötigten Optionen

Wir entfernen die nicht benötigten Optionen sauber aus dem Data Dictionary, so dass es keine Reste in der DBA_REGISTRY gibt und auch keine invaliden Objekte zurück bleiben. Im Anschluss wird mittels eines Metadaten Exports verifiziert, dass auch der EXPDP noch problemlos funktioniert.

Hinweis für Multitenant Nutzer: Es gibt beim Plugin von PDBs in eine CDB kein Problem, wenn die PDB weniger Optionen nutzt, als die CDB anbietet. Sollte die PDB jedoch eine Option enthalten, die in der CDB fehlt, kann man die PDB nicht öffnen!

 

Interesse an diesem Webinar geweckt?

Dann schauen Sie es sich doch direkt auf unserem Youtube Channel an: DB Masters Webinar: Warum soll man unnötige Optionen in der Oracle DB vermeiden?.

 

Vergessen Sie nicht unseren Youtube Channel zu abonnieren, damit Sie keines unserer Videos verpassen!