Die Oracle Datenbank 19c: Eine Einführung für DBAs

Von Thorsten Grebe

Diese Einführung in die Oracle Datenbankadministration bietet einen schnellen Einstieg in die Installation, den Betrieb und das Backup einer Oracle 19c Datenbank. Dabei liegt der Fokus auf Datenbanken, die nicht in der Cloud, sondern auf eigenen Servern (on premise) betrieben werden. Es wird gezeigt, wie eine Einzelinstanz als herkömmliche Non-CDB oder als Multitenant-Containerdatenbank aufgesetzt werden kann und wie beim Aufbau eines Real Application Clusters vorgegangen werden muss. Erläutert werden die Komponenten, aus denen eine Datenbank und ihre Instanz bestehen, die Bedeutung von Speicherbereichen und Schemaobjekten. Die Besonderheiten einer Containerdatenbank gegenüber der älteren Non-CDB Architektur werden beschrieben. Hinweise werden gegeben, welche Initialisierungsparameter besser auf ihren Vorgabewerten belassen und welche unbedingt angepasst werden sollten. Besonderen Raum wurde dem Thema Backup und Recovery eingeräumt. Es wird gezeigt, welche Befehle in einem Sicherungsskript nicht fehlen sollten und wie Schäden an einer Oracle Datenbank erkannt und repariert werden können. Nach der Lektüre sollten sich Leserinnen und Leser nicht mehr orientierungslos gegenüber einer Oracle Datenbank fühlen.  

• Sprache: Deutsch
• Herausgeber: Springer Vieweg
• Erscheinungsdatum: 18. Juni 2021
• ISBN: 9783662625705

Buchvorschau

© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2021

T. GrebeDie Oracle Datenbank 19chttps://doi.org/10.1007/978-3-662-62570-5_1

1. Einführung

Thorsten Grebe¹  

(1)

Berlin, Deutschland

1.1 Warum Oracle?

Die Oracle Datenbank ist die funktionsreichste und die mit dem höchsten finanziellen und personellen Aufwand entwickelte Datenbank unter allen verfügbaren kommerziellen und freien Datenbanksystemen. Sie zählt zu den ältesten am Markt etablierten Datenbanken und hat regelmäßig mit der Entwicklung neuer Funktionen Maßstäbe gesetzt. Die Transaktionsverwaltung, die Multiversionierung, das Locking-Verfahren, der Umgang mit Undo und die konsequente Instrumentierung des Oracle Kernel-Codes waren richtungweisend. Oracle war die erste Datenbank, die den gleichzeitigen ändernden und transaktionssicheren Zugriff auf einen Datenbestand durch mehrere Instanzen ermöglichte, eine Technik, die erst als Parallel Server , später als Real Application Clusters bekannt wurde. Bis zur aktuellen Version der Datenbank ist Oracle stets so innovativ geblieben, dass es für Oracle Administratoren zu einer Dauerherausforderung geworden ist, auf dem Laufenden zu bleiben. Neue Major Releases, wie 10g, 11g, 12c oder 20c führten jedes Mal Hunderte teils kleine, teils große Neuerungen ein, deren Studium eigentlich Jahre benötigen würde. Immer wieder bleiben neue Funktionen als „verborgene Juwelen" zunächst unentdeckt, weil sie unauffällig in der Innovationsmasse untergehen. Oracles Anspruch, den Platz unter den führenden Datenbanksystemen zu behalten, hat auch dazu geführt, dass die Oracle Datenbanksoftware zu den komplexesten unter allen Datenbanken gehört. Zwar wurde in den vergangenen 20 Jahren großer Wert daraufgelegt, den Installationsprozess und den Betrieb der Datenbank durch immer mehr Automatismen und Selbstoptimierungen zu erleichtern. Dennoch sind die Möglichkeiten, eine Oracle Datenbank zu erstellen, zu betreiben, zu konfigurieren, zu optimieren oder auch versehentlich lizenzrechtlich illegal zu nutzen unüberschaubar, selbst für erfahrene Kollegen.

Mit der Datenbankversion 12c, die im Juni 2013 veröffentlicht wurde, schockierte Oracle altgediente Administratoren mit einem radikalen Architekturumbruch. Es wurde die Mehrmandanten-Option eingeführt, auch als Multitenant , Pluggable , oder Container Database bekannt. Es ist in den Versionen 12c, 18c und 19c immer noch möglich, eine Datenbank so zu erstellen und zu betreiben wie in den vorherigen Jahrzehnten. Oracle nennt diese ursprüngliche Architektur inzwischen Non-CDB und hat sie mit dem Status deprecated gebrandmarkt. Deprecated ist wie eine Gelbe Karte. Danach kommt der Status unsupported, die Rote Karte. Funktionen mit Status deprecated werden noch unterstützt, aber von Oracle nicht mehr weiterentwickelt. Sie sollen abgekündigt werden. Für Funktionen mit Status unsupported übernimmt Oracle keine Verantwortung mehr. Mit der Deprecation-Ankündigung signalisierte Oracle bereits 2013, dass die alte Architektur in Zukunft nicht mehr unterstützt werden soll. Wie ernst eine solche Ankündigung zu nehmen ist, kann zunächst niemand einschätzen. In der Vergangenheit wurden regelmäßig Funktionen mit dem Status deprecated belegt, die dann aufgrund des stillen und sturen Protestes der Endkunden ewig weitergepflegt worden sind. Oder weil Oracle selbst nicht in der Lage war, ohne diese Funktion auszukommen. Beispiele sind die Entwicklungsumgebung Forms/Report, die Replikationstechnik Streams, der Datentyp LONG, das alte Exportprogramm exp, der alte Scheduler dbms_job, der Optimizer Mode RULE. Einige große Funktionen, wie das in 12.1 eingeführte und kräftig beworbene Information Lifecycle Management (ILM), waren in den ersten Jahren noch gar nicht für den Containerbetrieb freigegeben. Nicht jeder nahm die Deprecation-Ankündigung ernst. Doch dann schockierte Oracle erneut, als auf der Open World im September 2019 die Desupport-Ankündigung für die alte Non-CDB-Architektur folgte. Ab 20c müssen alle Oracle Datenbanken im Containermodus laufen.

Die Einführung der Mandanten-Architektur ist eine der gravierendsten Änderungen in der Oracle Datenbank seit ihrer Einführung in den 1970er-Jahren. Die neue Architektur führt viele neue Funktionen und Fähigkeiten ein, erfordert jedoch auch in vielfacher Hinsicht ein Umdenken und Umlernen bei den Administratoren – auch heute noch, Jahre nach ihrer Einführung. Regeln, die bisher galten, gelten nicht mehr. Neue Regeln müssen gelernt werden. Tom Kyte [1–3], ein legendärer und brillanter Oracle Pädagoge, sprach einst vom Learning und Unlearning , das bei Oracle besonders wichtig sei. Alte Regeln und altes Wissen sind nicht immer förderlich, sie können dem reibungslosen, performanten Oracle Datenbankbetrieb wie ein Hindernis im Weg stehen.

Die Lernkurve ist bei Oracle leider steil. Darüber sollte die scheinbar einfache Installation über den Universal Installer nicht hinwegtäuschen. Jeder kann Oracle installieren. Betreiben und Probleme erkennen funktioniert jedoch nicht ohne ein gewisses Fundament an Oracle Know-how. Auch das Erstellen eines Backups gelingt scheinbar mühelos. Der Versuch, eine Datenbank aus einer Sicherung wiederherzustellen, kann dagegen schnell zum Fiasko entgleiten. Viele Funktionen einer Oracle Datenbank lassen sich schnell anklicken oder per einzeiligem Kommando aktivieren. Nicht immer ist aber klar, wie die erfolgreiche Aktivierung verifiziert werden kann oder ob eine Funktion zusätzliche, kostenpflichtige Lizenzen erfordert. Notorische Beispiele sind Kompression und Performancefunktionen. Für Neueinsteiger besteht hier häufig eine regelrechte Lizenzfalle, denn Oracle hat von Beginn an nie mit Lizenzschlüsseln zum Freischalten von Funktionen gearbeitet. Alles ist zunächst freigeschaltet, abgerechnet wird hinterher.

Es gibt ca. 200 relationale Datenbanksysteme plus ca. 250 bis 300 NoSQL-Datenbanken am Markt. Doch nur wenige verfügen über den Funktionsumfang und die Zuverlässigkeit einer Oracle Datenbank. Viele sind hochspezialisiert auf eng umschriebene Aufgaben, die sie sehr gut und performant verrichten – mit empfindlichen, aber für den jeweiligen Anwendungsfall akzeptierten Einbußen bei einer ACID-konformen Transaktionsunterstützung, bei Multiversion Read Consistency, beim Sperrverhalten, bei Verfügbarkeit, bei Sicherheit und vor allem beim Funktionsumfang. Im Gartner Magic Quadrant für Datenbanksysteme belegt Oracle seit Jahren konstant den vorderen oder einen der vorderen Plätze. Gartner bewertet die Datenbanken nach einem umfangreichen Kriterienkatalog, u. a. mit folgenden als kritisch erachteten Eigenschaften eines operationalen Datenbanksystems:

Hochverfügbarkeit

Sicherheit

Geschwindigkeit/Durchsatz bei der Datenverarbeitung

Cloud-Kompatibilität

Administration

Konsistenz

Multiple Datentypen

Automatische Datenverteilung

Kontinuierliche Datenaufnahme mit hoher Geschwindigkeit

Die meisten Datenbanksysteme am Markt glänzen in der einen oder anderen Disziplin. Nur sehr wenige beherrschen das komplette geforderte Portfolio. Neben MS SQL-Servern und DB2 zählt hierzu seit sehr langer Zeit die Oracle Datenbank. Besonders hohe Bewertungen erhält Oracle vor allem für seine Hochverfügbarkeits- und Sicherheitslösungen. Oracle zählt seit Jahrzehnten zu den verlässlichsten und innovativsten Datenbanksystemen und die Chancen stehen gut, dass sich im kommenden Jahrzehnt nicht viel daran ändern wird.

1.2 Versionen, Funktionen, Meilensteine in der Entwicklung der Oracle Datenbank

Die Geschichte von Oracle beginnt 1977, als Larry Ellison zusammen mit Bob Miner und Ed Oates die Firma Software Development Laboratories (SDL) gründete. Mit 2000 US-Dollar Startkapital und einer VAX begannen sie ihre Arbeit in Redwood Shores im kalifornischen Silicon Valley. Sie schufen ein neues Datenbankprogramm, dessen Datenhaltung auf voneinander abhängigen Tabellen basierte, so wie es in den grundlegenden theoretischen Vorarbeiten des IBM-Mathematikers Edgar Frank Codd vorgedacht worden war. Ellison erkannte, dass es noch keine kommerzielle Anwendung am Markt gab, die Codds Ideen zur neuen relationalen Datenbank umsetzten. Zur selben Zeit wurde an der Universität von Kalifornien, Berkeley, der Vorläufer der freien Postgres Datenbank entwickelt. Bis dahin basierten Datenbanken auf hierarchischen oder netzartigen Strukturen. Die drei Kollegen arbeiteten damals an einem Projekt für die CIA. Die engen Verbindungen zu den amerikanischen Geheimdiensten bestehen bei Oracle von Beginn an. Ein komplettes Feature von Oracle, die Label Security, war eine Auftragsarbeit der CIA. 1979 veröffentlichten Miner und Ellison die erste Version ihrer Datenbanksoftware. Die Firma war inzwischen umbenannt in Relational Software Inc. (RSI). Auf eine benannte Version „1 wurde wegen der schlechten Reputation von 1-er Versionen verzichtet. Im Dienste des Marketings hieß die erste Ausgabe der Datenbank offiziell Version „2. Der Firmenname wurde 1982 erneut geändert, dieses Mal in Oracle , nach einem damaligen Projekt, das von der CIA beauftragt worden war. Für die dritte Version, die 1983 auch in Deutschland angeboten wurde, schrieb Oracle die Software komplett in die Programmiersprache C um.

Heute stecken in dem Softwareprodukt über 40 Jahre Entwicklungsgeschichte. Über 30 Jahre Forschung und Entwicklung sind in die clusterfähige Version der Datenbank, den Real Application Cluster (RAC), geflossen. Tab. 1.1 zeigt, wann welche Oracle-Version erschienen ist und in Stichworten, welche wichtigsten Neuerungen mit ihr verbunden sind.

Tab. 1.1

Oracle-Versionen und Meilensteine in der Datenbankentwicklung

Nur in den Datenbankversionen 7 und 8 wurden drei Releases herausgegeben. In den Versionen 9 bis 12 gab es nur noch 2 Releases. Nach Version 12 wird das Jahreszahlenmodell eingeführt. Es gibt ein Jahresrelease mit quartalsweisen Aktualisierungen: 18.1, 18.2, …, 18.7, 18.8. Nicht immer spiegelt die Position der Versionsnummer die Bedeutung eines Release wider. So wurde das Release 11gR1 allgemein als verkapptes 10gR3 betrachtet, da die großen architektonischen Änderungen in ASM und Grid-Infrastruktur erst mit dem zweiten Release, der Version 11gR2, herauskamen. Die Neuerungen von 11gR1 nach 11gR2 waren schwerwiegender als die Änderungen von 10gR2 nach 11gR1. Bei 12cR1 kann wieder mit Recht von einem komplett neuen Release gesprochen werden, während die Versionen 18 und 19 intern als Weiterführung von 12c gelten: 18c = 12.2.0.2, 19c = 12.2.0.3. Oracle spricht vom 12c-Schirm (umbrella), unter dem die Versionen 18 und 19 intern betrachtet werden. Auf der Seite Release Schedule of Current Database Releases, die im Oracle Support-Portal¹ unter der Doc-ID 742060.1 gefunden wird, und auf der verbindlich die Supportzeiträume für die aktuellen Softwareversionen veröffentlicht werden, verwendet Oracle offiziell beide Zählweisen bis Ende 2019 (Abb. 1.1). Anfang 2020 verschwindet die doppelte Versionierung aus den offiziellen Dokumenten und Support-Seiten – sie stiftete zu viel Verwirrung. Es heißt jetzt nur noch 18c und 19c.²

../images/480514_1_De_1_Chapter/480514_1_De_1_Fig1_HTML.png

Abb. 1.1

Oracles offizieller Versionsfahrplan, die Database Release Roadmap (Doc-ID 742060.1)

Seit der Einführung des neuen Versionsmodells ab 18c gibt es jedes Jahr ein neues Hauptrelease, dessen Versionsnummer sich am aktuellen Datum orientiert. Die vorherige Praxis, bei der ca. alle vier bis fünf Jahre ein neues Major Release veröffentlicht wurde, für welches dann binnen ein bis zwei Jahren ein Release-Update herausgegeben wurde (von 11gR1 nach 11gR2, von 12cR1 nach 12cR2), ist seitdem nicht mehr gültig. Oracle begründet dies mit einem Vorteil für den Endkunden: Statt alle fünf Jahre eine neue Hauptversion mit Hunderten neuer Funktionen zu veröffentlichen, soll jetzt jedes Jahr eine neue Hauptversion herausgebracht werden, die nicht mehr so viele Neuerungen auf einen Schlag mitbringt und Upgrades aus Administratorensicht verdaulicher machen soll. Zurzeit muss Oracle bis zu fünf Hauptversionen der Datenbank pflegen. Ende 2018 waren dies gleichzeitig die zu diesem Zeitpunkt noch unter Support stehenden Versionen 11.2.0.4 und 12.1.0.2 sowie die gerade als aktuell geltenden Versionen 12.2.0.1 und 18, während die größten Anstrengungen in die vor der Veröffentlichung stehenden Version 19 geflossen sein dürften. Die bis zu fünf Stellen einer kompletten Release-Bezeichnung (11.2.0.4.0) werden dadurch auf 2 reduziert, denn es werden jetzt nur noch die Quartals-Updates in der Nachkommastelle angegeben, z. B. führte das Release-Update der Datenbank im Juli 2018 zur Version 18.3.

Mit dem Wechsel auf das neue Modell plant Oracle, den Extended Support grundsätzlich einzustellen. Gleichzeitig gilt die neue Regel, dass mit der Herausgabe einer neuen Hauptversion der Support der vorherigen mindestens noch zwei Jahre lang weiterläuft, sodass im ersten Quartal 2019 sowohl eine Version 19.1 als auch eine Version 18.5 veröffentlicht wird. Dauerläufer wie das Release 11.2.0.4, das von 2013 bis 2018 unter Support stand, wird es vermutlich nicht mehr geben. Die Hauptversion 11g hätte rechnerisch sogar eine kumulierte Supportzeit von 11 Jahren, wobei sich die Version 11.1. aus dem Jahr 2007 vom Funktionsumfang drastisch von einer 11.2 aus dem Jahr 2018 unterscheidet.

1.3 Vorgefertigte Komplettsysteme/Engineered Systems

2008 stellte Oracle mit Exadata das erste vorgefertigte Komplettsystem vor, bei dem – ähnlich Apple Computern – Hardware und Software von einem Hersteller stammen. Damals arbeitete Oracle eng mit HP zusammen, um Rechnersystem, Verkabelung, Host Bus Adapter, Firmware, Betriebssystem und Datenbanksoftware optimal aufeinander abzustimmen, ohne Kompromisse auf Kosten von Kompatibilitäten mit fremden Herstellerkomponenten eingehen zu müssen. Oracle entschied sich, in diesen vorgefertigten Systemen nur solche Komponenten zu verbauen, die in ihrer Disziplin zu den besten zählen – in Marketingvorträgen gerne als Best-in-Breed-Ansatz bezeichnet. Für die Verkabelung zwischen Datenbankserver und Storagesystem wurde Infiniband verwendet, für die Speicherung wurde von Beginn an neben konventionellen Festplatten auch auf SSDs gesetzt. Inzwischen sind SSDs im Storage-Betrieb selbstverständlich, 2008 war die Verwendung von SSDs für Oracle Datenbanken noch nicht üblich. Das Kommunikationsprotokoll zwischen Datenbank und Storage wurde speziell für die von Oracle gewählte Hardwarekombination neu entwickelt, damit es eng auf die ebenfalls neu entwickelten Speicherzellen des Storage (storage cells) abgestimmt werden kann. In einer Exadata können Optimierungen umgesetzt werden, die nicht möglich sind, wenn Endkunden ihr Datenbanksystem mit Komponenten unterschiedlicher Hersteller frei zusammenstellen.

Mit der Übernahme von Sun Microsystems wurde Oracle selbst zum Hardwarelieferanten und beendete die Kooperation mit HP. Die zweite Version der Exadata lief bereits auf Sun Hardware. Inzwischen wurde aus dem vorgefertigten Komplettsystem Exadata eine eigene Produktfamilie, die als sogenannte Engineered Systems bekannt sind. Heute bietet Oracle eine ganze Palette solcher Systeme an. Auf der kalifornischen Oracle Open World, der weltweit größten Oracle Konferenz, die jedes Jahr in San Francisco stattfindet, wurden ab 2008 folgende Komplettsysteme vorgestellt:

1.

Oracle Exadata Database Machine

Das erste Mitglied der Engineered Systems für Datawarehouse- und OLTP³-Betrieb.

2.

Oracle Exalogic Elastic Cloud

Für Oracle Application Server.

3.

OracleSuper Cluster

4.

Oracle Virtual Compute Appliance

Für Oracles eigene Virtualisierungslösung Oracle VM.

5.

OracleDatabase Appliance (ODA)

Eine miniaturisierte Exadata für mittelständische Betriebe und Fachabteilungen.

6.

OracleExalytics In-Memory Machine

7.

Oracle Big Data Appliance

Für moderne Workloads mit unstrukturierten Daten.

8.

Oracle ZFS Storage Appliance

Ein erweiterbares für Exadata optimiertes Storage Array.

9.

Oracle Network Applications Platform

10.

Zero Data Loss Recovery Appliance(ZLDRA)

Für die Sicherung von Oracle Datenbanken.

Die beiden häufigsten Argumente gegen den Erwerb derartiger Komplettsysteme sind neben den sehr hohen Anschaffungskosten die Abhängigkeit, in die man sich dadurch zu Oracle begibt. Man spricht vom Vendor Lockdown – ein einzelner Händler ist in der Lage, ohne Furcht vor Konkurrenz die Bedingungen einer Geschäftsbeziehung zu diktieren. Andererseits haben die Komplettsysteme von Oracle unbestreitbar zwei große Vorteile für den Endanwender: Die Hardwarekomponenten in den Komplettsystemen sind von Oracles Technikern bereits auf Kompatibilität vorselektiert. Nicht der eigene Systemadministrator muss mühselig herausfinden, welcher Switch in welcher Netzwerktopologie mit welcher Firmware bei welcher Storage-Anbindung zu welchen schwer reproduzierbaren Fehlern oder Performance-Anomalien führen kann. Bei auftretenden Fehlern kennt Oracle die Konfiguration genau, denn die Komplettkonfiguration stammt von Oracle selbst, sie kennen die Hardware- und Softwarezusammenstellung im Detail. Wer einmal miterlebt hat, wie zeitaufwendig und zermürbend derartige Fehlersuchen sein können, weiß diesen Pluspunkt besonders zu schätzen. Der zweite große Vorteil bei dem Ansatz, alles zusammen anzubieten, ist die Möglichkeit, Software und Hardware optimal aufeinander abzustimmen und zusammen zu entwickeln. Die Software weiß, was die Hardware kann. Nur durch diese enge Verknüpfung von Soft- und Hardware in einer Exadata war die Entwicklung der Storage-Zellen mit ihren hocheffizienten Storage-Indizes, die hybride Spaltenkomprimierung oder das neue Kommunikationsprotokoll zwischen Datenbank- und Storage-Servern möglich.

1.4 Neue Funktionen in neuen Datenbankversionen

Jede neue Datenbankversion von Oracle stellte in der Vergangenheit eine unüberschaubare Anzahl neuer Funktionen vor oder baute bestehende aus. Manche sind klein und so unbedeutend, dass auch erfahrene Oracle Datenbankadministratoren erst nach Jahren beiläufig Kenntnis davon nehmen. Andere stehen unter solch einem Trommelwirbel, dass auch nicht in der IT verwurzelte Mitmenschen plötzlich mitreden können – für Exadata wurde an den großen Flughäfen der Welt mit unübersehbaren Plakatsäulen geworben.

Oracle 11g startete mit über 400 neuen Funktionen, Oracle 12c mit über 500. Auch eingefleischte Oracle Profis sind längst nicht mehr in der Lage, hier den Überblick zu behalten. Zu schnell sind die Entwicklungen, zu viele einzelne Fachdisziplinen sind im Datenbankumfeld entstanden:

Datawarehouse-Spezialisten, die sich mit großen Datenvolumina auskennen.

Datenbankentwickler, die sich mit Apex und PL/SQL auskennen.

Datenbankentwickler, die sich mit Forms & Reports auskennen.

Datenbankentwickler, die sich in das komplexe Application Development Framework (ADF) eingearbeitet haben.

Datenbankentwickler, die sich auf Dot.Net-Anwendungen für Windows spezialisiert haben.

JAVA-Entwickler, die sich auf Oracle spezialisiert haben.

Datenbankanalysten, die sich mir R oder den analytischen Funktionen auskennen.

Geospezialisten, die sich mit der Spatial Option auskennen.

Publizisten und Linguisten, die sich speziell mit den Medien-, Text- und Suchfunktionen auskennen.

Sicherheitsexperten, die sich mit dem respektablen Datenbankportfolio in diesem Themensegment auskennen.

Deploy- und Upgrade-Experten, die sich mit den umfangreichen Möglichkeiten auskennen, Oracle Datenbanken bereitzustellen oder zu aktualisieren.

Backupexperten, die sich um die Sicherungen der Oracle Datenbanken sorgen.

Hochverfügbarkeitsexperten, die um die umfangreichen Möglichkeiten wissen, Funktionen, Services und ganze Server ausfallsicher zu gestalten.

Jedes der Engineered Systems benötigt ein spezielles Know-how.

Bei einem Upgrade auf eine neue Datenbankversion ist es der Wunsch und die Hoffnung von Datenbank- und Anwendungsadministratoren, dass hinterher alles so funktioniert wie vorher, und zwar ohne hierzu vorbereitend viele Seiten Upgrade-Dokumentation lesen und umfangreiche Anpassungen vornehmen zu müssen. Nicht immer ist dies möglich: die Umstellung auf das Automatic Storage Management (ASM, eingeführt in 10g), die Umstellung auf die Grid-Infrastruktur (GI, eingeführt in 11g) oder die Umstellung auf Container-Datenbanken (CDBs/PDBs, eingeführt in 12c), erforderte jedes Mal beträchtliches Umdenken und Hinzulernen bei den Administratoren. Bei den großen Versionsupdates mussten Datenbankadministratoren in den letzten 20 Jahren stets hinzulernen, sich umgewöhnen, bestehendes Know-how als überholt und hinderlich ablegen.

Gleichzeitig gilt für den überwiegenden Teil der Oracle Datenbankfunktionen: Mit dem Verständnis einer Oracle Datenbank der Version 7 versteht man auch die Kernfunktionalität einer aktuellen Version. Diese langlebigen Grundlagen zum Verständnis einer Oracle Datenbank werden in Kap. 3 beleuchtet. Hier sollen kurz die besonderen Verhaltensänderungen in den letzten Datenbankversionen überflogen werden, begonnen bei Version 11g, von der trotz des ausgelaufenen Supports immer noch zahlreiche Installationen existieren und vermutlich – in abgeschotteten Netzwerksegmenten – auch noch eine Weile existieren werden. Dies hat auch plausible Gründe: Die Version 11.2.0.4 (wie zuvor auch die Version 10.2.0.5) ist so stabil und funktionsreich, dass in einigen Umgebungen die einzige Notwendigkeit zum Upgrade durch den auslaufenden Oracle Support und das damit verbundene Ausbleiben von Sicherheitsaktualisierungen begründet ist. Problematisch sind Altanwendungen, für die es keine Entwickler mehr gibt, und die kein Upgrade auf 12c, geschweige auf 20c, vertragen. Sind solche Systeme netzwerktechnisch isolierbar, liegt die Frage nahe, ob man sie nicht lieber virtualisieren sollte, anstatt ihre Verfügbarkeit durch ein Upgrade zu riskieren.

1.4.1 Neue Funktionen in 11g

ADR, das Automatic Diagnostic Repository

In 11g wurde ein einheitliches Verzeichnissystem für Log- und Tracedateien eingeführt, nämlich das Automatic Diagnostic Repository , ADR. Notwendig wurde die Änderung der Verzeichnisstruktur zum einen durch die zunehmende Unübersichtlichkeit der Log- und Traceverzeichnisse. Alert-Logs, Trace-Dumps, User-Dumps, Core-Dumps, Audit-Dateien konnten individuell und kreuz und quer über Betriebssystemverzeichnisse verstreut liegen. Besonders im RAC, in dem jedes von Dutzenden Modulen eigene Logdateien schreibt, nahm die Anzahl an Logverzeichnisse und Tracedateien in den Versionen 10g und 11g stetig zu. Fehlersuche und das Suchen nach relevanten Logdateien wurden zu einer zeitraubenden Tätigkeit. Es wurde immer schwieriger, den Überblick darüber zu behalten, wo im Dateisystem Logdateien verstreut waren. Eine zweite Motivation, die Log- und Traceablage von Grund auf umzustrukturieren, war das neue automatische Paketiersystem IPS,⁴ , das die Versendung von diagnostischen Dateien an den Oracle Support erleichtern sollte. Alle relevanten Log- und Traceunterverzeichnisse sollten über einen Einstiegspunkt erreicht werden können. Dieser Einstiegspunkt ist seit 11gR2 das neue Logging-Mutterverzeichnis und wird als ADR Base bezeichnet. Es kann für jede Datenbank über den Initialisierungsparameter diagnostic_dest auf ein Verzeichnis der eigenen Wahl gesetzt werden:

SQL> show parameter diag

NAME TYPE VALUE

----------------- ---------- ----------------------------

diagnostic_dest string /u01/app/oracle/oracle_base

SQL> alter system set diagnostic_dest = ′/opt/oracle′;

Dieses Statement erzeugt unterhalb /opt/oracle ein neues Verzeichnis „diag", unter dem automatisch eine umfangreiche Verzeichnisstruktur aufgebaut wird. Das geht sogar im laufenden Betrieb. Das Einstiegsverzeichnis heißt stets diag. Man kann im laufenden Betrieb das komplette Diagnoseverzeichnis löschen, ohne dass irgendein Schaden entsteht. Prozesse, die neue Informationen in ihr diag-Unterverzeichnis schreiben wollen, legen ihre Datei inklusive Pfad neu an, falls es noch nicht oder nicht mehr existiert. Das Wurzel- oder Stammverzeichnis des ADR (ADR Base) wird, falls der Parameter diagnostic_dest nicht definiert ist, von der Umgebungsvariable $ORACLE_BASE abgeleitet. Einsehen lässt sich die Verzeichnisstruktur des ADR über die View v$diag_info:

SQL> select name, value from v$diag_info ;

NAME VALUE

--------------------- ----------------------------------------------------------

Diag Enabled TRUE

ADR Base D:\ORACLE\DB

ADR Home D:\ORACLE\DB\diag\rdbms\CDB\pdb1

Diag Trace D:\ORACLE\DB\diag\rdbms\CDB\pdb1\trace

Diag Alert D:\ORACLE\DB\diag\rdbms\CDB\pdb1\alert

Diag Incident D:\ORACLE\DB\diag\rdbms\CDB\pdb1\incident

Diag Cdump d:\oracle\db\diag\rdbms\CDB\pdb1\cdump

Health Monitor D:\ORACLE\DB\diag\rdbms\CDB\pdb1\hm

Default Trace File D:\ORACLE\DB\diag\rdbms\CDB\pdb1\trace\pdb1_ora_584.trc

Active Problem Count 0

Active Incident Count 0

11 Zeilen ausgewählt.

Hier sieht man das Ergebnis für eine Pluggable Datenbankinstanz „pdb1" unter Windows. Die Abfrage gegen v$diag_info verrät auch, wie die Tracedatei der aktuellen Session heißt (pdb1_ora_584.trc) und ob es noch nicht gewürdigte Probleme in der Datenbank gibt:

Active Problem Count = 0

und

Active Incident Count = 0.

Die Bezeichnungen Problem bzw. Incident orientieren sich am ITIL⁵-Standard, der Störungen im Betrieb in Probleme und Ereignisse (problems & incidents) unterteilt. Dabei ist ein Ereignis jedes Auftreten einer Störung oder eines Fehlers. Ein Problem kategorisiert diesen Fehler und fasst mehrere Ereignisse zusammen. So kann es in einer Datenbank wiederholt beim Ausführen einer bestimmten Funktion innerhalb einer Anwendung zu einem Fehler mit der Nummer ORA-07445⁶ kommen. ORA-07445 ist dann das „Problem, jedes Auftreten dieses Fehlers wäre ein „Incident. Mit der Einführung des ADR in 11g greift Oracle diese internationale Konvention auf und verwendet eine ITIL-konforme Deklaration von Fehlerfällen.

Grid-Infrastruktur – GI

11gR2, das zweite Release der Version 11, überraschte viele Administratoren mit einer bis dahin beispiellosen Umwälzung in der Softwarearchitektur. Oracle führte die sogenannte Grid-Infrastruktur (GI) ein und änderte damit das Fundament, auf dem die Clusterdatenbank RAC und das Storage Management ASM aufgesetzt wurden. Offenbar waren die Architekturänderungen, die Oracle ursprünglich in die Version 11g einbringen wollte, im Jahr 2007 noch nicht ausgereift genug. Tatsächlich gilt die Ende 2009 bereitgestellte Version 11gR2 als die eigentliche Einführung der Version 11, während 11.1 als ein verkapptes 10gR3 interpretiert wurde.

Durch die Einführung der Grid-Infrastruktur ebnete Oracle den Weg für die Rollentrennung zwischen Datenbank- und Clusterverwaltung. Die Software für die Grid-Infrastruktur ist vollständig getrennt von der Software für die Datenbank. Dadurch können sie unter unterschiedlichen Betriebssystembenutzern angelegt werden. Die einzige Kopplung besteht darin, dass beide Softwareeigentümer derselben primären Betriebssystemgruppe angehören müssen, damit Hintergrundprozesse der Datenbank auf die Speicherbereiche des ASM zugreifen können. Seit 11gR2 zählt die ASM-Instanz dadurch zur Infrastruktur. Dies ermöglicht es, in großen Umgebungen einen ASM-Administrator und einen Datenbankadministrator mit unterschiedlichen Privilegien auszustatten: Der ASM-Administrator erhält über seine Betriebssystemgruppenmitgliedschaft (z. B. asmdba) die SYSASM-Rolle. Diese erlaubt es ihm, Festplatten des Storagesystems zu konfigurieren und die ASM-Instanz zu stoppen und zu starten. Er hat jedoch keine Berechtigung sich an einer Datenbank anzumelden. Der Datenbankadministrator erhält über seine Betriebssystemgruppenmitgliedschaft (z. B. dba) die SYSDBA-Rolle, die es ihm erlaubt, fast alle administrativen Eingriffe in der lokalen Datenbank auszuführen, er darf sich jedoch nicht an der Infrastrukturkomponente ASM-Instanz anmelden (Anmeldversuche werden mit der Fehlermeldung ORA-01031: insufficient privileges) quittiert. Eine solche Rollentrennung erhöht die Sicherheit und Stabilität einer Datenbankumgebung, aber auch ihre Komplexität. Ein sauberes Rollenkonzept muss hierfür erstellt werden. In kleinen Umgebungen mit wenigen Datenbanken und einem einzelnen Administrator, der sich um alles kümmert, wird auf diese Rollentrennung meist verzichtet.

Ein Release-Update wie von 11gR1 nach 11gR2 war ursprünglich als Stabilitätsupdate gedacht. Das Einführen von großen Änderungen rechtfertigte in der Vergangenheit das Hochzählen der Hauptversion, der Zahl für das Major Release. Dieses Einführen von großen Änderungen in einem Release-Update wiederholt Oracle in 12c: In dem scheinbar kleinen Release-Update von 12.1.0.1 nach 12.1.0.2 führte Oracle die In-Memory-Option ein. Durch SAPs Einführung der HANA Datenbank war Oracle unter Zugzwang und konnte nicht mehr bis zum nächsten Major-Release-Update warten. Solch große Funktionseinführungen, wie in 12.1.0.2 oder Verhaltensänderungen, wie in 11.2.0.1 führen ein Release-Modell mit Major Releases, Minor Releases und Release-Updates ad absurdum. Mit der neuen an der Jahreszahl orientierten Versionierung ab 18c befreit sich Oracle von diesem scheinbar inkonsequenten Umgang mit den Versionszahlen.

1.4.2 Neue Funktionen in 12c

Ca. 700 neue Funktionen und Erweiterungen wurden in Version 12c eingeführt. Darunter sind viele, von denen auch ein erfahrener DBA noch nie gehört hat, die er in seinem Leben vermutlich nie direkt oder bewusst verwenden wird oder die er nicht kennen kann, weil sie völlig neu sind. Darunter sind spezielle Funktionserweiterungen für Entwickler, kleinere Automatismen, die unbemerkt das Leben des Administrators erleichterten, Erweiterungen des Optimizers, neue Techniken zur Stabilisierung oder Verbesserung von Ausführungsplänen – das meiste davon im Verborgenen, quasi unter der Haube. Aber 12c führte auch eine ganze Reihe großer Neuerungen ein, die aktiv publiziert und beworben wurden, wie die Einführung von Mehrmandantenfähigkeit, Flex-Cluster, Flex-ASM, In-Memory.

Gelegentlich werden Funktionen angekündigt, die noch nicht vollumfänglich umgesetzt worden sind, wie das ebenfalls in 12c hinzugekommene Information Lifecycle Management (ILM) . ILM ermöglicht über anpassbare Richtlinien (policies) die automatische Verschiebung von Daten, die nicht mehr verändert oder gelesen werden, in Archivbereiche. Ein kleines Framework wurde hierfür völlig neu entwickelt, das auf Heat-Maps, Wärmekarten, basiert. Heat-Maps zeigen an, welche Blöcke heiß sind, weil sie häufig angefragt werden, und welche für längere Zeit nicht mehr angefragt wurden, quasi erkaltet sind. Nicht mehr angefragte Daten können dann automatisiert auf preiswertere Laufwerke verschoben werden. Dieses Policy-basierte Verschieben von Daten bezeichnet Oracle als Automatic Data Optimization (ADO), es erfordert die Lizenzierung der Advanced Compression Option und ist zweifellos eine wunderbare Ergänzung in einem Konsolidierungsportfolio. Der Lebenszyklus der Information (Information Lifecycle), von der Entstehung bis zur Archivierung, ist dabei das übergreifende Thema, ADO eine Methode dafür. Zum Zeitpunkt der Bekanntgabe und Bewerbung der ILM/ADO/Heat-Map-Funktionalität in Version 12cR1 war diese allerdings noch gar nicht für die in 12c eingeführten Container-Datenbanken verwendbar, sondern ausschließlich für die bereits abgekündigte Non-CDB-Architektur, was eine gewisse Ironie barg. Inzwischen, mit einigen Jahren Verzögerung, werden Heat-Maps auch von einer Container-Datenbank unterstützt.

Auf viele kleinere Neuerungen, die in 12c eingeführt worden sind, haben DBAs und Entwickler lange gewartet, z. B. die Erweiterung des varchar2-Datentyps auf bis zu 32 KB, die Einführung von Autoinkrementspalten, das Online-Verschieben von Datenbankdateien oder die Top-N Abfrage zum einfachen Durchblättern eines Ergebnissatzes. Sehr nützlich ist auch die mit 12c eingeführte Privilegienanalyse,⁷ die den Gebrauch verwendeter Rechte aufzeichnet und bei der Umsetzung des Prinzips des kleinsten Rechts (Least Privilege) wertvolle Hilfe leistet. Dieses inzwischen zum allgemeinen Sicherheitsstandard erhobene Prinzip verlangt, dass ausschließlich die notwendigen Privilegien vergeben werden sollen, die eine Anwendung oder ein Anwender zum Arbeiten benötigen, aber keine darüber hinaus.

Zahlreiche andere Neuerungen werden gar nicht veröffentlicht, sondern stillschweigend eingeführt, um Performance oder Stabilität zu erhöhen.

1.4.2.1 Mandantenfähigkeit – die Pluggable Database

Als mit Abstand bedeutendste Neuerung in 12c gilt die Änderung des Instanzkonzeptes. Wie in anderen Datenbanksystemen (MS SQL-Server, MySQL) üblich, ist es nun auch bei Oracle möglich, mehrere Datenbanken unter einem einzigen Satz von Instanzenprozessen laufen zu lassen. Intern musste der Aufbau des Data Dictionary von Grund auf umorganisiert werden. Bis zur Version 11gR2 musste für jede Datenbank, die auf einem Server betrieben wurde, ein eigener Satz von Instanzprozessen gestartet werden, im typischen Fall sind dies für eine Datenbank mehrere Dutzend:

$ ps -ef | grep ora_

... ora_pmon_ORCL

...

... ora_dbw0_ORCL

... ora_lgwr_ORCL

... ora_ckpt_ORCL

... ora_smon_ORCL

... ora_mmon_ORCL

...

Das Betriebssystemkommando ps, gefiltert nach Prozessen, die mit „ora_" beginnen, zeigt alle Prozesse an, die zu laufenden Datenbankinstanzen gehören. Neben essenziellen Prozessen wie PMON (Prozessmonitor), DBW0 (Database Writer) oder LGWR (Logwriter) gibt es zahlreiche, die nur bei Bedarf aktiv werden. In Oracle-Version 10 gab es fünf essenzielle Datenbankprozesse, in 12c sind es mehr als zehn. Mit den optionalen Prozessen zusammen können jedoch ohne Weiteres 50, 100 oder 1000 Betriebssystemprozesse für eine einzelne Datenbankinstanz gestartet sein (Kap. 3).

Im mandantenfähigen Containermodus gibt es nur einen solchen Satz von Prozessen. Die Container-Datenbank hieße in diesem Beispiel ORCL und würde – auf Betriebssystemebene nicht sichtbar – eine Anzahl von sogenannten integrierten Containern, Pluggable Datenbanken, enthalten. In der ursprünglichen, inzwischen als Legacy-Modus bezeichneten Konfiguration, gibt es für jede Datenbank einen kompletten, eigenen Satz von Instanzprozessen, was im Betriebssystem wie folgt aussähe, wenn man nur nach dem Prozessmonitor filtert:

$ ps -ef | grep pmon

... ora_pmon_ORCL1

... ora_pmon_ORCL2

... ora_pmon_ORCL3

... ora_pmon_ORCL4

Hier laufen vier Datenbankinstanzen im Legacy-Modus mit je einer verbundenen Datenbank. Im mandantenfähigen Containermodus könnte diese Anzeige jedoch vier Container-Datenbanken mit jeweils Hunderten von Pluggable Datenbanken bedeuten. Auf den ersten Blick ist das ab Version 12c gar nicht unterscheidbar. Man kann sich leicht vorstellen, wie viel Verwirrung 2013 durch die Einführung der Datenbankcontainer entstand. Tatsächlich hat sich das Containerkonzept bis heute, Jahre nach Einführung, noch nicht flächendeckend durchgesetzt, obwohl Oracle von Beginn an alle Kunden zum Umstieg auf das neue Modell drängte. Man kann auch heute noch in der Version 19c beide Modi parallel nebeneinander betreiben. Erst ab Version 20c sind nur noch Container erlaubt.

Die Motivation von Oracle war es, den Betrieb von sehr großen Umgebungen zu vereinfachen. Im Blick sind hier vor allem Datenbankbetreiber in der Cloud, die mehrere Kunden betreuen – daher auch der Begriff Mandantenfähigkeit. Dies ist jedoch nicht in jeder Umgebung deckungsgleich mit der Motivation von Datenbankadministratoren, für die eine Umstellung auf das Containerkonzept– besonders in kleinen und mittleren Umgebungen – zunächst viel Aufwand bedeutet, denn im ungünstigen Fall muss eine Vielzahl von Skripten umgeschrieben werden.

1.4.3 Neue Funktionen im Überblick für die aktuellen Versionen

Tab. 1.2 vermittelt einen Eindruck, wie hoch der Innovationsdruck bei Oracle ist. Es sind beispielhaft einige der neuen Funktionen, die jenseits der beiden am meisten umworbenen Neuerungen in 12c, die Container-Architektur und die In-Memory-Option, eingeführt worden sind.

Tab. 1.2

Übersicht über ausgewählte neue Funktionen ab Version 12c

Die vollständige Liste der Neuerungen würde einige Hundert Einträge lang sein. Als DBA kommt man nie hinterher. Seit 10g hat jedes neue Release so viele neue kleine und große Funktionen eingeführt, dass die Zeit kaum bis zum nächsten Release ausreicht, diese zu studieren. Einige Funktionen werden leider auch etwas unausgereift ausgeliefert und man tut sich keinen Gefallen, sie zu früh zu adoptieren. Mit welcher Geschwindigkeit der Funktionsumfang einer Oracle Datenbank in den vergangenen Versionen gestiegen ist, verdeutlichen ein paar Stichproben aus den Systemviews der Datenbank (Tab. 1.3). Die ständigen Neuerungen hinterlassen auch Spuren in der Größe des Data Dictionary.

Tab. 1.3

Wachstum des Data Dictionary von Version 10 bis 19

Die Zahlen können je nach Release-Update, Patchstand und Ausstattung abweichen, aber der Trend ist klar. Das Data Dictionary wächst. Der Funktionsumfang nimmt stetig zu, aber niemals ab.

1.5 Die großen Trends

Die Einführung von neuen Funktionen, wie die clusterfähige Oracle Datenbank (Real Application Clusters, RAC) in Version 9i, der Oracle-eigene Volume Manager ASM (Automatic Storage Management) in Version 10g, die Grid-Infrastruktur (GI) mit eigenem Werkzeugset in 11gR2, die Einführung der Container-Datenbanken in 12c oder der starke Drang in die Cloud ab 18c, zwingen Betreiber und Betreuer der Oracle Datenbank stets zum Umdenken und Weiterbilden. Hinzu kommen ständige Weiterentwicklungen von bestehenden Techniken um automatische, adaptive und zuletzt autonome Funktionen. Die Treiber für die ständige Neuentwicklung sind vielfältig. Einerseits gibt es Feature Requests: Kundenwünsche nach einer neuen Funktion erhöhen aus Oracles Perspektive die Kundenbindung. Es gibt aber auch einen enormen kommerziellen Druck, der alle Datenbankhersteller zwingt, mit stets neuen Funktionen und spektakulären Verbesserungen die Konkurrenten zu übertrumpfen. SAP gelang mit der Entwicklung von HANA ein vorbildhafter Marketing Coup, den Oracle 2014 im Release-Update 12.1.0.2 mit der In-Memory-Offensive konterte. Nun entstehen solche Neuerungen nicht zufällig, sondern sie werden von großen Trendentwicklungen geleitet.

1.5.1 Standardisierung – Automatisierung – Konsolidierung

Es gibt Megatrends im IT-Betrieb, die auch große Firmen nicht aufhalten können. Diese Trends werden diktiert durch neue Entwicklungen, neue Bedrohungen, neue Chancen, innovative Vorstöße einzelner Vordenker, neue Angriffstechniken von Cyberkriminellen und die Bedeutung des exponentiell wachsenden Datenvolumens. Der Drang in die Cloud, die Verlagerung auf In-Memory, die NoSQL-Bewegung, der Hype um die Blockchain, Verschärfungen im Datenschutz, neue Entwicklungen auf den Gebieten des Machine Learnings und der Künstlichen Intelligenz zwingen den IT-Betrieb, ständig in Bewegung zu bleiben. Der Takt, in dem Sicherheitspatches eingespielt werden müssen, hat sich erhöht. Das bewährte Prinzip, einen Sicherheitspatch erst ausgiebig zu testen und dann in der Produktion zu installieren, wurde umgekehrt. Es hat in den letzten Jahren einen Paradigmenwechsel in der Adressierung von Sicherheitsfragen gegeben. Heute wird von Sicherheitsverantwortlichen gefordert, Sicherheitsupdates schnellstmöglich auszurollen. Sicherheit geht heute vor Verfügbarkeit. Es ist leichter, die Nichtverfügbarkeit einer Anwendung mit einem fehlerhaften Sicherheitspatch zu begründen als mit einem Angriff, der durch einen Sicherheitspatch hätte verhindert werden können. Für Sicherheitsverantwortliche hat sich der politische und juristische Druck erhöht, für Administratoren der Druck zur Standardisierung und Automatisierung. Für Sicherheitspatches, die Zero-Day-Exploits verhindern sollen, können heute nicht mehr mehrere Monate für das Ausrollen eingeplant werden.

In großen Umgebungen werden verlässliche, standardisierte und automatisierte Verfahren benötigt, um den aktuellen Herausforderungen gewachsen zu sein. Große, zerklüftete IT-Umgebungen müssen konsolidiert werden, um sie noch beherrschen zu können. Die drei Disziplinen Standardisierung, Automatisierung und Konsolidierung lassen sich kaum voneinander trennen. Konsolidierung lässt sich ohne Standardisierung nicht bewerkstelligen und je größer der Konsolidierungsbedarf wird, desto größer wird die Notwendigkeit der Automatisierung. Die folgenden Abschnitte sollen kurz beleuchten, wie sich diese drei Trends in den Entwicklungen der letzten Datenbankversionen von Oracle widerspiegeln.

1.5.1.1 Standardisierung

Standardisierung bedeutet Vereinheitlichung – auf jeder Ebene. Im Kleinen bei der Benennung von Variablen oder einem einheitlichen Error-Logging. Aber auch im Großen beim Umgang mit Prozessen. Heute gilt Standardisierung nicht nur als ein bewährtes Vorgehen, es wird gefordert, und zwar mit Vehemenz – von ISO 9000, von ISO 27000, von Sicherheitsauditoren, von großen Firmen, die kleine Firmen als Subunternehmer verdingen.

In Version 11gR1 führte Oracle den Incident Packaging Service (IPS) ein, der für Oracle Support diagnostische Informationen aus Tracedateien zusammensammelt. Der Ablageort für Log- und Tracedateien wurde dazu über das Automatic Diagnostic Repository (ADR) vereinheitlicht. Oracle unterscheidet seitdem ITIL-konform zwischen Incidents und Problems . IPS sollte das Eröffnen von Service Requests vereinfachen und das wiederholte Nachfragen von einzelnen Log- oder Tracedateien ersetzen. Mit einem standardisierten Aufruf durch einen eigens entwickelten ADR Command Interpreter, dem adrci, kann der Hilfe suchende Datenbankadministrator alle relevanten Log- und Tracedateien mit einem Aufruf zusammensammeln. Später, während der Lebenszeit der Version 11gR2, wurde das standardisierte Sammeln diagnostischer Daten durch den Remote Diagnostic Assistant (RDA) massiv erweitert. RDA wurde unabhängig von der Datenbanksoftware entwickelt, aktualisiert und per Download im Support-Portal bereitgestellt. Vor dem Erstellen eines neuen Service-Requests (SR) wurde eine Zeitlang vom Oracle Support gefordert, die aktuelle RDA-Version zu beziehen, dessen voluminöse Datensammlung ins Portal hochzuladen, was die Ticketeröffnung bei Oracle zu einer zweistündigen Übung ausufern ließ. Neu für den RDA war auch, dass er nicht nur die Datenbanksoftware, sondern alle möglichen anderen Oracle Produkte bediente, sodass man beim Aufruf des Kommandozeilenprogramms rda erst eine langwierige Interviewphase durcharbeiten musste. Heute ist auch RDA nicht mehr das Mittel der Wahl, sondern der Trace File Analyzer -Collector (TFA-Collector oder gelegentlich auch nur TFA ). Dieser ist inzwischen Teil einer noch umfangreicheren Werkzeugsammlung, die zum Autonomous Health Framework (AHF) zählt. Autonomie ist die angestrebte Endstufe der Automatisierung.

1.5.1.2 Automatisierung

Automatisierung soll ständig wiederkehrende, nach festen Regeln ablaufende Arbeitsroutinen überflüssig machen. Datenbankadministratoren sollen von Aufgaben entbunden werden, die Zeit rauben, Konzentration erfordern, stets wiederkehren und von wichtigeren, kreativeren Tätigkeiten abhalten. In dieser Disziplin hat Oracle bisher mit jeder neuen Version Akzente gesetzt, oft zum Verdruss der alten DBA-Hasen, deren teils skurriles Detailwissen nach derartigen Erneuerungen der Datenbank nicht nur überflüssig, sondern häufig auch schädlich erschien. Die Verwaltung von Rollbacksegmenten, Transaktionslisten, das Feintuning des Extentmanagements oder das manuelle Sichern einzelner Datendateien gehören längst der Vergangenheit an. Erstaunlich ist es, wie einfach und robust eine Sicherung, Wiederherstellung oder Duplizierung einer Datenbank mit dem Recovery Manager RMAN geworden ist. Beispielsweise sichert das folgende Kommando mit vier Worten eine Oracle Datenbank in Gänze:

RMAN> backup database plus archivelog;

Die Sicherung umfasst nicht nur die Datendateien und Transaktionslogs, sondern auch die wichtige Parameterdatei zum Starten der Instanz sowie die zentrale Kontrolldatei, ohne die eine Oracle Datenbank nicht betriebsfähig ist. Der Recovery Manager speichert automatisch alles, was er zum verlustfreien Wiederherstellen der Datenbank benötigt, auch wenn der Administrator nicht daran denkt. Noch mehr Automatismus beherrschen die Restore- und die Duplizierungsfunktion des Recovery Managers. Besonders im Vergleich zum Backup und Restore anderer Datenbanken wie MySQL- oder MariaDB zeigt sich, wie viel Entwicklung in Oracles Recovery Manager geflossen ist.

Das Automatisierungsthema zieht sich bei Oracle durch alle Softwareschichten. Mit Grid Control wurde es in Version 11g bereits möglich, Sicherheitspatches automatisch zu verteilen, wenn auch zu respektablen Lizenzkosten, die sich nicht für jeden rechnen. 12c hat unter Marketingfachleuten ein neues Modewort populär gemacht: das Provisionieren. Heute müssen ungeduldige Entwickler und Tester nicht mehr auf den DBA warten, bis dieser mittels DBCA oder per Skript eine neue Testdatenbank eingerichtet hat – sie können sie sich im Self-Service-Portal selbst zusammenklicken und – falls Copy-on-Write-Snapshots im Hintergrund konfiguriert sind – innerhalb von Sekunden auf ihre neue Testinstanz zugreifen. Die Datenbank wird automatisiert und beeindruckend schnell auf Knopfdruck bereitgestellt oder wie man heute sagt: Sie wird provisioniert, und zwar flugs. Der Aufwand zur Bereitstellung eines solchen Selbstbedienungsportals ist allerdings beträchtlich und lohnt sich nur für große Umgebungen. Dafür, dass ein Entwickler viel Zeit sparen kann, muss nämlich ein Administrator erst einmal viel Zeit investieren.

Automatisierung muss jedoch nicht immer gleich der große Wurf sein, sie wird auch im Kleinen zunehmend bedeutender. Einzelne DBAs können heute für mehrere Dutzend bis hundert Datenbanken zuständig sein. Ein Jammer, wenn sie dann ihren Tag mit müßigen Alltagsroutinen wie dem Erweitern von Tablespaces, dem Entsperren von Benutzerkonten, dem Erzeugen neuer Benutzerkonten, dem Exportieren von Tabellen und Schemata, dem Point-in-Time-Restore verbringen müssen. Dies sind alles gute Beispiele, in denen es sich lohnt, Aufwand in standardisierte Automatisierungsroutinen zu investieren. Abb. 1.2 zeigt eine Zusammenfassung von Automatisierungsfunktionen, die in den Datenbankversionen 9i bis19c eingeführt wurden. Ab Version 12c gibt es eine neue Qualitätsstufe von Automatisierung: Automatikfunktionen, die eigenständig agieren und deshalb als autonom bezeichnet werden. Zu den ersten autonomen Funktionen zählte das Autonomous Health Framework (AHF), das selbstständig Fehler erkennen und beheben können soll. Im Hintergrund lernt die Datenbank dazu. In der Cloudvariante der Datenbankversion 12.2.0.2 (offiziell 18c) wird Machine Learning (ML) eingesetzt. Aus einer Fülle permanent erhobener diagnostischer Daten, dem Abgleich mit Regelwerken und unter Hinzuziehung von Erkenntnissen aus automatisch erstellten Analysen anderer cloudbasierter Datenbanken soll die Datenbank eigenständig auf Fehler reagieren, Probleme erkennen und beheben, Performanceengpässe vorhersehen und durch geeignete Parametrierung der Datenbank bereinigen. Wie dies im Detail erfolgt, wird von Oracle nicht publiziert, es soll wohl aber so gut funktionieren, dass Oracle bereits in 18c offiziell von der autonomen Datenbank spricht, die das Eingreifen eines DBAs überflüssig machen soll – allerdings nur in der Cloudversion, die im permanenten Austausch mit Oracles Machine-Learning-Infrastruktur steht.

../images/480514_1_De_1_Chapter/480514_1_De_1_Fig2_HTML.png

Abb. 1.2

Automatisierungsfunktionen der Datenbank, die seit Version 9i entwickelt wurden

1.5.1.3 Konsolidierung

Konsolidieren, das Zusammenlegen von zunächst getrennt verwalteten Komponenten, umfasst, wie auch das Streben nach Standards und Automatismen, alle Ebenen der IT: Hardware, Betriebssysteme, Storage, Netzwerke, Plattformen, Anwendungen und Services werden konsolidiert. Und eben auch Datenbanken, die auf unterschiedlichen Hosts liegen. Datenbankkonsolidierung ist ein Trend, der meist nicht vom DBA angestoßen wird. Der Anstoß kommt von oben. Das höhere Management möchte Kosten einsparen und glaubt, dies durch Konsolidierung erreichen zu können. Deshalb war eines der wichtigsten Verkaufsargumente von Exadata, dem ersten vollständig vorkonfigurierten Engineered System , neben der extremen Performance auch das große Konsolidierungspotenzial, das durch Hin- und Herrechnen schwierig kalkulierbarer Lizenzkosten⁸ besonders überzeugend zu sein schien. Das Argument für die Serverkonsolidierung durch IT-Verantwortliche und Virtualisierungsexperten ist stets, dass die meisten Server bei geringer Auslastung vor sich hindümpeln und es daher sinnvoll wäre, die Ressourcen zu bündeln, sodass die Anwendungen zweier nicht ausgelasteter Server auf einem vereint werden. Für die wenigen Ausnahmen, in denen eine High-Performance-Anwendung unter Dauerlast steht und permanent eine garantierte Leistung von der Hardware abrufen können muss, ist dies ein sinnvoller Ansatz. Eine ähnliche Argumentation gilt für Storagesysteme. Diese werden konsolidiert, um Schwankungen in Plattenbelegungen und Bandbreitenanforderungen gegeneinander auszutarieren. Die Sicherung des Storage-Bereichs auf Bandlaufwerke wird durch Storage-Konsolidierung in ein großes Storage Area Network (SAN) vereinfacht und Erweiterungen sowie Prognosen für zukünftigen Speicherbedarf werden leichter berechenbar und planbarer als in zerklüfteten Storage-Landschaften mit lokalen Platten oder versprenkelten Direct Attached Storage -Systemen.

Das gleiche Kalkül gilt für Datenbanken. Warum sollen zehn Datenbanken auf zehn Servern betrieben werden, auf denen kaum Betrieb ist. In vielen Fällen wird die Verwaltung von Datenbanken vereinfacht, wenn sie auf einem Server laufen, statt auf 10 Servern, die alle einzeln gewartet werden müssen – von der Hardware mit allen Komponenten (Bios/Firmware/HBAs/Netzwerkanschlüsse) bis zur Software mit all ihren Layern (Betriebssystem, Treiber, Anwendungssoftware). Bis einschließlich der Datenbankversion 11g bedeutete das Zusammenlegen von zehn Datenbanken auf einem Host, dass dort zehn autarke Datenbanken mit zehn kompletten Prozess-Sets (10xPMON, 10xDBW0, 10xLGWR …) liefen. Dies war bei konkurrierenden Datenbanksystemen stets anders: Bei MySQL- und MS SQL-Servern konnten unter einem Prozess-Set mehrere Datenbanken betrieben werden. Bei Oracle erlaubte dies die Architektur bis einschließlich Version 11gR2 nicht: Es galt die strikte Regel, dass eine Datenbankinstanz an nur eine Datenbank gebunden werden konnte. Erst die in 12c eingeführte Multitenant-Architektur lockerte diese starre Regel.

Ein wichtiger Aspekt sollte beim Thema Konsolidierung nicht außer Acht gelassen werden: die Verfügbarkeit. Systeme, sei es Server, Storagesystem, Netzwerkkomponenten oder Datenbanken, die unterschiedliche Anforderungen an Verfügbarkeit und Wartungsintervalle haben, sollten nicht gemeinsam konsolidiert werden. Eine Anwendungsdatenbank, die rund um die Uhr verfügbar sein muss, sollte nicht mit einer Anwendung zusammengelegt werden, die nur tagsüber zur regulären Arbeitszeit erreichbar sein muss, dafür aber schnelle Wartungs- oder Update-Zyklen fordert. In großen Umgebungen kann es erheblichen kommunikativen Aufwand bedeuten, ein Wartungsfenster für eine Datenbank zu finden, in der ein Sicherheitspatch eingespielt werden muss. Je mehr Datenbanken aus unterschiedlichen Fachabteilungen zusammengelegt werden, desto schwieriger kann es werden, ein solches Zeitfenster zu finden. Unmöglich ist dies jedoch nicht: Mit Unterstützung der Geschäftsleitung und Verweis auf gesetzlich relevante Sicherheitsrichtlinien lassen sich feste monatliche Wartungsfenster vereinbaren, wie z. B. jeden Samstag zwischen 15:00 und 17:00 Uhr oder jeden ersten Montag zwischen 17:00 und 19:00 Uhr.

1.5.2 Plötzlich Multitenant. Von der Schema- zur Datenbankkonsolidierung

Der Umbau der ursprünglichen Non-CDB-Architektur vor 12c in die neue integrierbare Architektur war für Oracle mit einem beträchtlichen Entwicklungsaufwand verbunden. Das interne Datenbankinventar, das Data Dictionary, das die Strukturen der Datenbank aufbaut, darstellt und verwaltet, musste grundlegend umgebaut werden. In der Datenbankversion 11gR2 bestand es aus ca. 1300 Tabellen und 3800 Views. Jede einzelne Tabelle, jede einzelne View musste um neue Spalten erweitert werden. Ein ganz neuer Satz von Tabellen und Views für die globalen Sichten im Wurzel- oder Root-Container (CDB$ROOT) musste eingeführt werden. In Version 12.2.0.2 (alias 18c) gibt es bereits ca. 3000 Tabellen und über 13000 Views im Data Dictionary, wie über folgende SQL-Abfrage nachvollzogen werden kann:

12.2.0.2> select object_type, count(*)

from cdb_objects

where owner = 'SYS'

and object_type in ('VIEW', 'TABLE')

group by object_type;

OBJECT_TYPE COUNT(*)

----------- --------

TABLE 3020

VIEW 13205

Die zentralen Memorystrukturen von Oracle, PGA und SGA, mit ihren zahlreichen Unterbereichen mussten umgestaltet werden (Kap. 3). Neue Methoden für den Umgang mit den ein- und aussteckbaren, Pluggable Datenbanken (PDBs) mussten erdacht werden. Bestehende Werkzeuge für den alltäglichen Umgang mit Oracle, wie SQL*Plus, SQL Developer oder Enterprise Manager mussten angepasst werden. Komplett neue Programme wie catcon.pl mussten geschrieben werden. Und das alles in einer Art und Weise, die Upgrades von früheren Versionen zulassen, ohne dabei eine Anwendung zu zerstören. Warum hat Oracle diese Kraftanstrengung angenommen? Vor allem, wenn man bedenkt, wie undankbar gerade die treuesten Fans dafür sein mussten – altgediente, erfahrene, konservative Oracle Datenbankadministratorinnen und -administratoren.

Es gibt zwei große Triebkräfte, die Oracle zum Umdenken genötigt haben: der ewige und stetig steigende Trend zur Konsolidierung und der ewige und stetig wachsende Wunsch nach der kurzfristigen, häufig nur vorübergehenden Bereitstellung von Oracle Datenbanken für Test und Entwicklung. Bis einschließlich Version 11g waren nur zwei Arten der Konsolidierung möglich: die Schema-Konsolidierung, bei der Anwendungsschemata aus mehreren Datenbanken in einer einzigen Datenbank vereint werden, und die Datenbankkonsolidierung, bei der Datenbanken von mehreren Hostsystemen auf ein einziges Hostsystem zusammengeführt werden, dort aber parallel nebeneinanderlaufen. Bei der zweiten Methode, der Datenbankkonsolidierung, bietet Oracle ab Version 12c mit der Multitenant-Option einen völlig neuen Ansatz (Abb. 1.3).

../images/480514_1_De_1_Chapter/480514_1_De_1_Fig3_HTML.png

Abb. 1.3

Konsolidierungstechniken für Oracle Datenbanken

In einer Multitenant-Datenbank (Abb. 1.3 rechts) gibt es ähnlich der Schema-Konsolidierung (Abb. 1.3 links) nur einen Satz von Datenbankprozessen, die Anwendungsschemata sind aber so gut voneinander isoliert wie bei einer Prä-12c Datenbankkonsolidierung (Abb. 1.3 Mitte), bei der jedes Schema in einer eigenständigen Datenbank beherbergt ist.

Schema-Konsolidierung

Die Schema-Konsolidierung ist die einfachste Art der Zusammenführung von mehreren Datenbanken. Der Begriff Schema wird bei Oracle meist synonym mit dem Begriff Benutzerkonto verwendet.⁹ Ein Benutzerkonto muss jedoch keine Objekte besitzen. Der Begriff Schema bezeichnet ein Benutzerkonto, das als Sammelbehälter für Objekte verwendet wird – meist die Objekte einer Anwendung inklusive ihrer in Tabellen gespeicherten Daten. Bei der Schema-Konsolidierung werden Anwendungsschemata aus verschiedenen Datenbanken in einer Datenbank vereint. Eine wesentliche Voraussetzung für diese Art der Konsolidierung ist jedoch, dass alle Objekte (Tabellen, Views, Trigger, Jobs, Synonyme …) nur einem einzigen Oracle Benutzerkonto (Schema) gehören und dieses möglichst einen eigenen Tablespace (logische Gruppierung von Datendateien) verwendet. Im günstigen Fall können so mehrere Anwendungen ihre Daten in einer einzigen Datenbank abspeichern (Abb. 1.3 links). Eine Anwendung A verbindet sich dazu mit dem Datenbank-Schema A und speichert dort ihre Daten. Anwendung B verbindet sich mit Datenbank-Schema B in derselben Datenbank und speichert hier ihre Daten. Das klingt einfach, hat in der Praxis jedoch häufig nicht reibungslos funktioniert, weil zahlreiche Objekte bei einer Oracle Datenbank nicht an ein Schema gekoppelt sind. Hierzu zählen Verzeichnisobjekte, die grundsätzlich dem Superuser SYS gehören oder öffentliche Synonyme, die immer dem öffentlichen, für alle zugänglichen Pseudoschema PUBLIC gehören. Ebenso sind Rollen und Profile, die entscheidend für ein zeitgemäßes Rechtekonzept sind, Bestandteil der gesamten Datenbank und nicht eines einzelnen Schemas. Anwendung A und B dürfen bei einer Schema-Konsolidierung keine Verzeichnisse, öffentlichen Synonyme, Rollen oder Profile mit kollidierenden Namen verwenden. Je mehr Anwendungen man jedoch per Schema-Konsolidierung zusammenlegt, desto schwieriger wird diese saubere Trennung. Und hier hört es nicht auf: Logon-Trigger, Auditpolicies, Initialisierungsparameter, Speicherparametrierung oder Parallelisierung lassen sich nur mit großer Sorgfalt und nicht ohne Einschränkungen auf einzelne Schemata beziehen. Sobald weitere Datenbankbenutzer eingerichtet werden müssen, die mit erweiterten Rechten (z. B. ANY-Privilegien) ausgestattet sind, lassen sich versehentliche oder mutwillige Übergriffe von einem Anwendungsschema in ein anderes nicht mehr effektiv kontrollieren. Ein weiteres Problem stellen in solch schemakonsolidierten Datenbanken Wartungsfenster für Patchtermine dar. Je mehr Anwendungen in einem System laufen, desto mehr Betroffene müssen für einen Wartungstermin einbezogen werden. Weitere unangenehme Konsequenzen einer Schema-Konsolidierung bestehen darin, dass sich aufgrund der Abhängigkeiten von Objekten und Funktionen außerhalb des Anwendungsschemas in vielen Fällen kein einfacher Export eines Anwendungsschemas durchführen lässt. Ebenso wenig lässt sich ein Schema isoliert auf einen früheren Zeitpunkt zurücksetzen, ohne alle anderen Schemata zu betreffen. Besonders unerfreulich können Hängesituationen oder Blockaden sein, die – von einer einzelnen Anwendung ausgelöst – alle anderen Anwendungen in Mitleidenschaft ziehen.

Die Schema-Konsolidierung war in den 1990er-Jahren der empfohlene Ansatz zur Konsolidierung, um Server mit wenigen Ressourcen besser ausnutzen zu können. In Einzelfällen kann sie auch heute noch sinnvoll sein. Im Grunde ist dieses Konzept jedoch wegen der vielen Komplikationen gescheitert. Die Oracle Datenbank war für eine solche Kapselung einer Anwendung (anders als MySQL- oder MS SQL-Server) nie ausgelegt. Deshalb funktionierte die Schema-Konsolidierung durch Kapselung von Anwendungen in eigene Schemata und Tablespaces nie so sauber, wie es die Theorie vorschlug. Tab. 1.4 fasst die Komplikationen und Einschränkungen zusammen, auf die man bei einer Zusammenlegung von zwei oder mehr Anwendungsschemata in einer Datenbank vorbereitet sein muss. Das Kernproblem ist die unzureichende Isolierung von Schemaobjekten, Schemaprivilegien und das unzureichend kontrollierbare Teilen von datenbankweit gültigen Ressourcen.

Tab. 1.4

Komplikationen der Schema-Konsolidierung

*Die markierten Einschränkungen treffen auch auf Schemaexporte mit den Export-Programmen exp und expdp zu: Ein Schema umfasst zwar die Tabellendaten, nicht aber die vielen Objekte und Privilegien, die außerhalb eines Schemas organisiert werden und für die uneingeschränkte Funktion einer Anwendung benötigt werden

Datenbankkonsolidierung in den Zeiten, als es noch keine Container-Datenbanken gab

Um die möglichen Komplikationen einer Schema-Konsolidierung zu umgehen, bot sich vor Version 12c einzig die Datenbankkonsolidierung im ursprünglichen Sinn an – ohne Multitenant-Option, ohne Container-Datenbanken. Diese Konsolidierungsmethode ist heute immer noch die Methode der Wahl, wenn Datenbanken im Non-CDB-Modus betrieben werden. Dabei laufen auf einem Datenbankserver zwei oder mehr völlig eigenständige Datenbankinstanzen nebeneinanderher. Wie viele dies sein können, hängt von der Ausstattung des Hosts ab. Jede Datenbank benötigt mind. 2 GB RAM,¹⁰ um performant laufen zu können, möglicherweise wesentlich mehr. Außerdem benötigt jede Datenbank einen kompletten Satz aus mindestens 30 (meist wesentlich mehr) Instanzprozessen für ihren regulären Betrieb. Der I/O-Durchsatz muss entsprechend dimensioniert sein, sodass alle Datenbankdateien, Transaktionslogs und Backups bedient werden können, ohne in eine I/O-Sättigung zu geraten. Der Betreuungsaufwand für diesen Konsolidierungstyp ist zwar geringer, als wenn jede Datenbank auf einem eigenen Hostserver laufen würde, aber er ist deutlich höher als bei einer Schema-Konsolidierung. Für jede einzelne Datenbank müssen Sicherung und Alert-Überwachung eingerichtet werden. Der große Vorteil der Datenbankkonsolidierung gegenüber der Schema-Konsolidierung liegt in der vollständigen Isolierung der Anwendungsschemata. Die Datenbanken können sich in Version, Zeichensatz, freigeschalteten Zusatzfunktionen, Rollen- und Berechtigungskonzepten unterscheiden, ohne miteinander zu interferieren.

Datenbankkonsolidierung mit der Multitenant-Option

Die Einführung der Multitenant-Option in Version 12c ermöglicht eine Zusammenlegung von Datenbanken auf eine völlig neue Art, die die Vorteile der beiden vorherigen Konsolidierungsmechanismen vereint. Anwendungsschemata sind strikt voneinander isoliert. Die ganze Liste der Einschränkungen, die Tab. 1.4 aufzählt, trifft für das Zusammenführen von Anwendungsschemata in einer Multitenant-Datenbank nicht zu. Gleichzeitig ist der Verwaltungsaufwand ähnlich gering wie bei der Schema-Konsolidierung. Es wird nur eine einzige Container-Datenbank mit einem einzigen Prozesssatz betrieben. Die Anforderung an den RAM-Speicher bleibt moderat, sie ist abhängig von der Anzahl der integrierten Container-Datenbanken, der Anzahl gleichzeitig zugreifender Benutzersitzungen und von der Summe der gleichzeitig zu verarbeitenden Workloads. Ein möglicher minimaler Startwert für die Memory-Zuteilung einer kleinen Container-Datenbank liegt bei 4–8 GB RAM.

Für die Konsolidierung von Datenbanken bedeutet das Multitenant-Konzept einen deutlichen Fortschritt. Allerdings profitiert nicht jeder hiervon vollumfänglich, denn nicht jeder verfügt über die kostenpflichtige Multitenant-Option, die zusätzlich eine kostenintensive Enterprise Edition voraussetzt. Die Standard Edition lässt nur bis zu drei PDBs pro Container-Datenbank zu – und das auch erst seit der Desupport-Verkündigung für das Non-CDB-Modell auf der Open