Gerade in der Startup-Szene wird der Begriff der Disruption häufig verwendet. Er beschreibt die Einführung einer bahnbrechenden Innovation, welche bestehende Technologien, Geschäftsmodelle und/oder Prozesse obsolet macht. So hat die Einführung der Digitalfotografie z.B. das Geschäftsmodell von Kamera- und Filmherstellern (z.B. Eastman Kodak) nachhaltig verändert.

Um es vorwegzunehmen: Die Überschrift ist hier eher plakativ gewählt, um auf ein Problem hinzuweisen, welches mit der Einführung von Oracle Tenant einhergeht und  in vielen Fällen unterschätzt wird.

​Der Befund

Doch worum geht es hier? Mit der Einführung der Tenant-Technologie (oder Container-Technologie) hat Oracle mit einem Paradigma gebrochen. Ab dem Release 12c ist es nun möglich, unterhalb eines Datenbank-Containers (CDB) mehrere Pluggable Databases (PDBs) mandantenfähig zu betreiben. Andere Datenbankprodukte konnten dies bereits seit langer Zeit (SQL Server, MySQL, ….). Auch aus diesem Grund handelt es sich nicht wirklich um eine Disruption (Innovation) ;-)

Bei vielen unserer Kunden hat sich aber in den letzten zwanzig Jahren im Oracle-Biotop in vielen Fällen eine Betriebsstruktur entwickelt, dem dieses alte Paradigma quasi als eine Art Naturgesetz zu Grunde lag. Auch aus diesem Grund haben sich einige Kunden in den letzten Jahren und Monaten nur unzureichend mit dieser Veränderung beschäftigt und sich oftmals nur auf die naheliegenden datenbanktechnischen Veränderungen konzentriert.

Und hier liegt das Problem….

​Zu Risiken und Nebenwirkungen…

Aus den Erfahrungen der vergangen Monate haben wir verstanden, dass bei der Einführung aktueller Oracle Releases (> 12c), bei denen auch die Tenant-Technologie verwendet wurde, Probleme meist nicht im technisch-administrativen Bereich zu suchen waren. Die Installation und die Migration auf neue Releases konnte der Zielgruppe der DBAs recht schnell vermittelt werden. Das benötigte Wissen konnte durch ein paar Workshops und/oder ein paar Tage Schulung meist schnell vermittelt werden. Die „Beschwerden" traten oft dann auf, wenn das Release das Labor (Testumgebung) verlassen sollte und in den Regelbetrieb der jeweiligen Firmen und/oder Kunden integriert werden sollte.

Symptome und Ursache​

Die Identifikation von Systemen (z.B: in Inventories, CMDBs, Audit- / Monitoring-Systemen, …) erfolgt bei vielen Kunden über den Namen der Datenbank (ORACLE_SID). Oftmals wird diese Information noch um den Servernamen (Oracle SID + Server = eindeutig) ergänzt. Bei einer Tenant-Architektur ist „das Objekt der Begierde", welches den Kunden oder die Fachabteilung interessiert, jedoch die PDB.

Diese kann nun aber relativ dynamisch verschoben werden. So lässt sich auf Basis der Tenant-Technologie eine Migrationsstrategie nutzen, die darauf beruht, dass eine PDB aus einem älteren Container auf einem Server in einen neueren Container auf einem anderen Server (Stichwort Pluggable Databases) umgehängt wird. Technologisch ist dies für den DBA sicherlich ein Vorteil (auch für den Kunden).

Ist jetzt aber die CMDB noch darüber im Bilde, wo sich die Datenbank des Kunden befindet? Ist der Umzug transparent für das Monitoring? Weiß das Change-Management-System noch, welche Änderungen auf diesem System durchgeführt wurden?

Ähnliche Probleme mit der Namenskonvention finden sich auch in anderen Bereichen der Infrastruktur. Storage-Bereiche, Backup-Shares und andere Ressourcen tragen oftmals die Oracle-SID im Namen. Dies ist für den Container sicher ok, für die PDB aber nicht hilfreich.

Aber auch DB-intern kommt es zu Veränderungen, die Betriebsprozesse stören können. Das Namens- und User-Konzept muss an die beiden Ebenen (CDB/PDB) angepasst werden. Gleiches gilt für ein eventuell vorhandenes Audit-Konzept.

Natürlich gibt es aber auch administrative/technologische Herausforderungen. Beim Betrieb von Mutli-Tenant-Systemen muss sicherlich auch das Backup-Konzept überdacht werden. Die etablierten Skripte waren auf das Backup und den Restore einer Datenbank und nicht auf Subeinheiten wie PDBs fokussiert. Analoge Gedanken sollte man bezüglich des HA- und/oder DR-Konzeptes anstellen.

Auch die Frage der Ressourcenverteilung unter den PDBs stellt sich neu. Bislang ließen sich mehrere Mandanten zumindest zum Teil (z.B: Memory/SGA) separieren. Innerhalb eines Containers müssen neue Verfahren evaluiert werden (z.B. der eher unbeliebte Ressourcen-Manager).

Auch der Prozess des Lifecycle-Managements muss neu durchdacht werden: Wie und wo werden PDBs gepatched und migriert. Diese Frage wird z.B. dann spannend, wenn nur ein Kunde mit seiner PDB auf einen Bug läuft, von dem die anderen PDBs der anderen Kunden nicht betroffen sind.

Und natürlich sollte man sich beim Einsatz mehrerer Container (die ggfs. auch noch unterschiedlich lizenziert sind) auch Gedanken über die Lizenz-Compliance in einem so dynamischen Umfeld (Pluggable Databases) machen.

​Die Behandlung, die Therapie

Zunächst einmal sollte man sich von dem Gedanken trennen, dass es sich lediglich um die Einführung eines neuen Datenbank-Releases handelt und lediglich ein paar Parameter anzupassen sind. Alle (!) Betriebsprozesse sollten bei der Einführung der Tenant-Technologie auf den Prüfstand gestellt werden (hier ein paar mögliche):

• Software- und DB-Provisionierung
• Lifecylce-Management (Patches & Upgrades)
• Backup-Konzepte
• HA-/DR-Konzepte
• Security-, Monitoring- und Audit-Konzepte

Nachdem man hier im Datenbankumfeld Klarheit gewonnen hat, sollten alle angeschlossenen Prozesse, Verfahren, Methoden und Abteilungen involviert werden, um weitere mögliche Symptome zu finden (CMDBs, Infrastruktur-Prozesse, …).

Alternativtherapie

Natürlich kann man sich einer Vielzahl dieser Probleme entziehen, indem dieses neue Paradigma ignoriert und Datenbanken einfach weiterhin separat betrieben werden (Single-Tenant). Viele Probleme können so vermieden werden, da die Datenbank (inkl. der 1 PDB) weiterhin als singuläres Objekt betrachtet wird. Allerdings verzichtet man so natürlich auch auf die guten Seiten der Tenant-Technologie. Und ja – auch die existieren.