O wie Datenbank

Oracle und Unicode: Raus aus der 8-Bit-Welt

Eine Zeichensatz-Migration ist ein Projekt, kein Schalter

Johannes steigt diesmal mit einer Frage aus aktuellem Anlass ein: Gibt es in Roberts Projekten noch Datenbanken mit einem Ein-Byte-Zeichensatz? Gibt es, und zwar reichlich. Datenbanken, die vor zwanzig Jahren aufgesetzt und seitdem immer wieder migriert wurden, ohne dass jemand den Zeichensatz angefasst hätte. Manche davon laufen bis heute mit WE8ISO8859P1, dem Zeichensatz ohne Eurozeichen. Johannes betreut gerade eine Unicode-Migration, die nach zwei Jahren noch nicht abgeschlossen ist, und will wissen, was dabei alles zu beachten ist.

Zunächst die Grundlagen: Oracle 6 und 7 wurden standardmäßig mit US7ASCII installiert, 7 Bit, 128 Zeichen. Das achte Bit wurde für Umlaute zweckentfremdet, war aber nicht supported. Danach kam die Zeit der standardisierten Ein-Byte-Zeichensätze: MSWIN1252 auf Windows, in der Oracle-Datenbank WE8ISO8859P1 ohne und WE8ISO8859P15 mit Eurozeichen. Westeuropa war damit abgedeckt, aber nur westeuropäisch: Das Gravis-Zeichen aus offiziellen Dokumenten fehlt im ISO-Zeichensatz, nordische Umlaute ebenso. Die Oracle-Datenbank kennt dazu einen zweiten Zeichensatz, den National Character Set für NCHAR, NVARCHAR und NCLOB. Johannes nennt ihn einen Exoten, der die Migration nur komplexer macht.

Der Standard für neue Datenbanken ist AL32UTF8, ein Zeichensatz mit variabler Breite von einem bis vier Byte pro Zeichen. A bis Z brauchen ein Byte, Umlaute zwei, das Eurozeichen drei. Damit beginnt das eigentliche Problem: VARCHAR2(50) bedeutet standardmäßig 50 Byte, nicht 50 Zeichen. Nach der Umstellung passen Namen mit Umlauten nicht mehr in die Spalte, und abgeschnittene Namen will niemand. Die Antwort heißt Längensemantik CHAR, also VARCHAR2(50 CHAR). Der Parameter NLS_LENGTH_SEMANTICS könnte das zum Default machen, Oracle rät aber davon ab, ihn auf Instanzebene zu setzen: Das Data Dictionary bleibt ein Ein-Byte-Zeichensatz, und beim Patchen muss der Parameter wieder zurückgedreht werden. Johannes' Empfehlung: von Anfang an mit CHAR-Semantik arbeiten und den Parameter per ALTER SESSION setzen.

Vor der Migration steht der Scan mit dem DMU, dem Database Migration Assistant for Unicode. Das kostenlose Tool von Oracle findet Sonderzeichen, Längenprobleme und Spalten am 4000-Byte-Limit von VARCHAR2, und zwar nicht auf der Produktion, sondern auf einem Backup oder einer Standby-Datenbank. Migriert wird dann per Export und Import in eine neue Datenbank mit AL32UTF8. Das dauert bei Terabyte-Datenbanken Stunden bis Tage und ist komplett offline. Die In-Place-Konvertierung hat Johannes noch nie gemacht, weil ihm Strukturänderungen auf Produktionsdaten zu gefährlich sind.

Robert bringt MAX_STRING_SIZE=EXTENDED ins Spiel, mit dem VARCHAR2 bis 32K groß werden darf. Der Pferdefuß: Ab etwa 4000 Byte speichert Oracle den Wert intern als LOB, also out of line, mit anderer Performance und einer Tabellengröße, die nicht mehr die ganze Wahrheit zeigt. Dazu kommt, dass CLOBs nach der Umstellung doppelt so groß werden, weil sie nicht in AL32UTF8, sondern in UCS-2 mit mindestens zwei Byte pro Zeichen gespeichert sind. Das kostet Platz, Buffer Cache und Performance und muss eingeplant werden. Ein Grund, bei 8 Bit zu bleiben, ist das trotzdem nicht: Java und praktisch alle Anwendungen setzen UTF-8 voraus.

Aus seinem laufenden Projekt berichtet Johannes, warum zwei Jahre vergehen können: viele abhängige Systeme und Datenbanken, die mit umgestellt werden müssen, und die Frage, wie sich die Downtime bei einer großen Datenbank reduzieren lässt. Der Kunde setzt eine Replikationslösung ein, die Änderungen während der Migrationsphase aus der alten in die neue Datenbank überträgt, GoldenGate oder Quest SharePlex. Eine eigene Folge zur Replikation ist damit ausgemacht. Zum Schluss der Klassiker falsch kodierter Altdaten: Ein Client, der der Datenbank sagt, sie brauche nicht zu konvertieren, speichert ein Ü als etwas völlig anderes ab und bekommt es auch so zurück. Garbage in, garbage out. Bei der Migration fällt das auf und muss in der Regel von Hand bereinigt werden. Das Fazit der beiden: 8-Bit-Datenbanken migrieren, neue Datenbanken nur noch mit AL32UTF8 anlegen, und die Umstellung als Projekt aufsetzen.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Nützliche Befehle:

-- Zeichensätze der Datenbank anzeigen

-- Längensemantik CHAR für die aktuelle Session (nicht auf Instanzebene setzen)

-- Spalte explizit mit Zeichensemantik anlegen

-- Byte- und Zeichenlänge eines Werts vergleichen

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen an jedem ersten und dritten Dienstag im Monat über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Diese Folge ist eine Eigenproduktion von ora2know.

Oracle Read-Only Homes: Software und Konfiguration endlich getrennt

Ein gutes Feature mit irreführendem Namen — und einem Haken beim Patchen

Robert steigt mit einer unbequemen Frage ein: Wie viele Oracle Homes hat man je gesehen, die nach zwei Jahren noch aussehen wie am Tag nach der Installation? Johannes will es lieber gar nicht so genau wissen. In einem Home von schnell einmal elf oder zwölf Gigabyte sammelt sich mit der Zeit allerhand an, das dort nicht hingehört — und das beim nächsten Patch oder beim Out-of-Place-Upgrade zuverlässig im Weg steht, vergessen wird oder über Symbolic Links notdürftig zusammengehalten werden muss.

Der eigentliche Konstruktionsfehler dahinter: Konfigurationsdateien liegen im Oracle Home, obwohl das Home eigentlich nur Software enthalten sollte, die man austauschen können möchte. Genau dafür gibt es seit Version 18 das Read-Only Oracle Home. Johannes stellt gleich klar, dass der Name nicht wörtlich zu nehmen ist: Technisch bleibt das Verzeichnis beschreibbar, man könnte weiterarbeiten wie bisher. Der Wert liegt woanders — die Installation der Software wird von den Konfigurationsdateien entzerrt.

Eingeschaltet wird das über das Read-Only Oracle Home Control Utility, kurz roohctl, mit dem Schalter -enable. Der Haken: Das funktioniert nur, solange noch keine Datenbank und kein Listener laufen, also direkt nach dem Auspacken der Software. Danach landen die Konfigurationsdateien unterhalb von ORACLE_BASE. Im dbs-Verzeichnis liegen SPFILE beziehungsweise init.ora, im homes-Verzeichnis listener.ora, tnsnames.ora, sqlnet.ora und was sonst noch anfällt. Damit sind sie unabhängig von der Software-Installation, und Ansätze wie Gold Images oder Automatisierung per Ansible werden erst richtig praktikabel.

Warum ist das dann nicht überall Standard? Oracle traut dem eigenen Feature offenbar nicht ganz: In 19c ist es optional, in 21c Pflicht, in 23ai und damit auch 26ai wieder optional. Dazu kommt die Macht der Gewohnheit — wer seit dreißig Jahren sein SPFILE unter ORACLE_HOME/dbs sucht, ist wenig begeistert, wenn es plötzlich woanders liegt. Und es knirscht tatsächlich noch an einer Stelle: Unter homes steckt nicht direkt ein network/admin, sondern erst ein Unterverzeichnis mit dem Namen der Installation, dem Oracle Home Name. Linux-Kollegen kennen dieses Konstrukt kaum, Windows-Administratoren dagegen schon. Der Pfad lautet dann etwa /u01/app/oracle/homes//network/admin — und beim Out-of-Place-Patching muss die Listener-Konfiguration damit doch wieder umziehen. Nebenbei klärt sich auch, dass es unter Windows database statt dbs heißt, ohne dass es dafür einen erkennbaren Grund gäbe.

Der Sinn des Ganzen erschließt sich beim Patchen. Früher wurde in-place gepatcht, die laufende Software also direkt verändert. Heute wird zunehmend out-of-place installiert: Die neue Version kommt neben die alte, und irgendwann wird umgeschaltet. Damit das funktioniert, müssen alle Konfigurationsdateien im neuen Home bereits vorhanden sein. Als Stolperfalle nennt Johannes Skripte mit hart kodierten Pfaden und den Mischmasch aus Homes mit und ohne Read-Only — er hat es gerade bei einem Kunden erlebt, wo ein altes Skript schlicht vergessen wurde. Die Empfehlung: Skripte auf orabase, orabasehome und orabaseconfig umstellen, damit sie die Pfade selbst ermitteln. Und am schlausten wäre ohnehin, gleich AutoUpgrade zu verwenden — das kennt ein Flag, mit dem die Software direkt als Read-Only Oracle Home installiert wird.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Nützliche Befehle:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Diese Folge ist eine Eigenproduktion von ora2know.

Oracle und JSON: Vom CLOB über den nativen Datentyp zu Duality Views

Wie das Format des Internets in die relationale Welt kommt

JSON ist das Textformat mit den geschweiften und eckigen Klammern, das praktisch jeder schon einmal gesehen hat. Das Akronym steht für JavaScript Object Notation, entstanden Ende der 90er, um JavaScript-Objekte zu persistieren. Heute ist JSON die Lingua Franca des Internets. Jeder Webservice und jedes API spricht es. In Folge 005 fragt Johannes aus der DBA-Ecke, und Robert erklärt aus Entwicklersicht, wie dieses verschachtelte Dokumentenformat in eine relationale Datenbank kommt.

Der Einstieg ist überraschend einfach. JSON ist reiner Text, also passt es in jede Spalte, die Text speichern kann. Bis 4000 Zeichen reicht eine VARCHAR2-Spalte, im Extended Mode sogar bis 32.000. Für größere Dokumente liegt das CLOB nahe, doch Oracle rät davon ab. Der Grund ist die Kodierung. JSON liegt per Definition immer in UTF-8 vor, deshalb kann man sich den NLS-Layer und den CLOB-Overhead mit den doppelten Bytes pro Zeichen sparen und speichert besser im BLOB. Bis Oracle 21 war das die einzige Möglichkeit.

Ab Oracle 21 und fest mit 23, das mittlerweile als 26ai firmiert, gibt es einen eigenen Datentyp namens JSON. Intern speichert er im OSON-Format, das die Keys nach oben zieht und die Werte separat ablegt und intern verpointert. Spannend daran: Der Aufbau des OSON-Formats ist offen. Zum Aufnahmezeitpunkt war er über die quelloffenen Thin Driver für Python und JavaScript nachlesbar, inzwischen hat Oracle nachgelegt und OSON als eigenständige Spezifikation (Version 1.0) unter osonspec.org veröffentlicht, dazu eine Java-Referenzimplementierung auf GitHub unter der Universal Permissive License. Damit folgt Oracle MongoDB und PostgreSQL, die ihre Formate ebenfalls offengelegt haben. Zur Einordnung, weil Robert das im Podcast verkürzt hat: Offen sind Format und Referenzimplementierung, nicht der JSON-Datentyp der Datenbank selbst. Womit auch die Frage im Raum steht, ob man überhaupt noch eine MongoDB braucht. Robert zeigt, dass die Oracle-Datenbank mit konfiguriertem ORDS im Mongo-Mode laufen kann und für die Clients ununterscheidbar von einer echten MongoDB wird.Abgefragt wird natürlich mit SQL. Für eindeutige Pfade ohne Arrays ist die Dot-Notation richtig bequem. Sobald es komplexer wird, kommt JSON_TABLE ins Spiel, ein Operator, der in der FROM-Clause lebt. Man gibt ihm das JSON-Dokument, definiert mit dem Row Producer, welche Elemente zu Zeilen werden, und legt die Spalten fest. Heraus kommen Zeilen und Spalten wie aus jeder anderen Tabelle, die sich joinen, filtern und sortieren lassen. Bei der Performance hilft das ganze Oracle-Arsenal. Text-Indizes, Function-Based-Indexes auf JSON_VALUE und JSON_QUERY und beim nativen Datentyp eigene JSON-Indizes mit eigenen Operatoren im Ausführungsplan.

Das Highlight zum Schluss sind die JSON Relational Duality Views aus Oracle 23. Sie mappen JSON-Dokumente bidirektional auf relationale Tabellen. Man wirft ein JSON-Dokument in die View, und sie verteilt es im Hintergrund automatisch auf normalisierte Tabellen. Umgekehrt liefert ein Select aus der View ein fertiges JSON-Dokument zurück. Für Robert ist das eine echte Kampfansage an die Object-Relational-Mapper. Java-Entwickler, die heute Hibernate brauchen, könnten künftig auf Duality Views setzen und sich den Mapper sparen.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Dieser Podcast ist eine TON.EINS Produktion.

Oracle 26ai Multitenant - da führt kein Weg dran vorbei

Eine Lok, viele Container

Robert kommt frisch aus einer Woche voller Docker-Container und fragt sich, warum die Oracle-Datenbank das eigentlich auch selbst kann. Johannes holt die Metapher, die hängenbleibt: Die Container-Datenbank (CDB) ist das Schiff, die Lokomotive oder der LKW. Die einzelnen Pluggable Databases sind die Container, die huckepack mitfahren. Jede PDB ist für sich autark, ans Laufen kommt sie aber nur durch den Master-Container.

Warum hat Oracle das gebaut? Weil jede klassische Datenbank rund 40 Prozesse mitbringt und kräftig Memory und Storage verbraucht. Johannes erzählt von einem Kunden, der über 140 Testdatenbanken auf einen Server packen wollte und feststellte, dass die Datenbanken nur noch mit sich selbst beschäftigt waren. Multitenant teilt SGA und Hintergrundprozesse und holt so mit weniger Ressourcen mehr heraus.

Spannend wird es bei den Vorteilen im Alltag. PDBs lassen sich in Sekunden deployen statt in Stunden, sie lassen sich aus einer Vorlage klonen, und mit Copy-on-Write entstehen PDBs, die nur ihre eigenen Änderungen wegschreiben und kaum Platz brauchen. Jeder Entwickler kann seine eigene Datenbank bekommen. Natürlich sprechen die beiden auch über Noisy Neighbors, also die Sorge, dass sich eine entgleiste PDB auf alle anderen auswirkt. Johannes ordnet ein, warum das Problem nicht neu ist.

Dann die Geldfrage. Es gibt zwei Multitenants: die Architektur, die kostenlos bis zu drei PDBs erlaubt, und die kostenpflichtige Option, die bis zu 4096 PDBs freischaltet und rund ein Drittel der Datenbanklizenz kostet. In der Standard Edition gilt dieselbe Drei-PDB-Grenze, die PDB Seed als Vorlage bleibt immer kostenlos. Zum Schluss geht es um CDB- gegen PDB-Sicht, gemeinsam vererbte User, das kuriose Detail, dass es zwar ein Unplug, aber keinen Plug-Befehl gibt, sowie um Auto-Upgrade und versionsübergreifende Migration, von denen Johannes ein bekennender Fan ist.

Die Kernbotschaft: Multitenant ist handfeste Technik mit echtem Nutzen und längst kein Hexenwerk. Und weil es ab Oracle 26ai ohnehin nichts anderes mehr gibt, lohnt es sich, jetzt damit vertraut zu werden.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Dieser Podcast ist eine TON.EINS Produktion.

Oracle Juli-CPU: Der CVSS-Score sagt nichts über dein Risiko

Warum der höchste Score selten das größte Problem ist

Am 21. Juli 2026 hat Oracle den Critical Patch Update für das dritte Quartal veröffentlicht: über alle Produkte hinweg weit über tausend Patches, für den Oracle Database Server fünfzehn neue Sicherheits-Patches. Durch die Presse ging vor allem eine Zahl: eine Lücke mit CVSS 9.9 in der Datenbank. Robert Marz fragt nach, Johannes Ahrends ordnet ein — und die Antwort auf die Frage „Müssen wir jetzt alle unsere Wochenenden absagen?" fällt differenzierter aus als die Schlagzeile.

Zuerst die Grundlagen: Jede offiziell gemeldete Lücke bekommt eine eindeutige CVE-Nummer und einen CVSS-Score. Je höher, desto gefährlicher, 10 ist das Maximum. Die wesentlichen Kriterien sind, wie einfach sich eine Lücke ausnutzen lässt und wie schwer der Schaden wiegt. Bei einem Wert nahe 10 heißt das: Ein Angreifer muss das System nur erreichen können, sich nicht einmal anmelden — und kann es komplett übernehmen.

Genau hier beginnt die Entzauberung. Die 9.9 hängt am Package DBMS_CLOUD. In der Oracle Cloud wird es intensiv genutzt, dort patcht Oracle aber ohnehin selbst. On premises lässt es sich nachinstallieren, was manche Unternehmen für KI-Features tun, nötig ist es aber nicht. Wer DBMS_CLOUD nicht installiert hat, hat für diese Lücke erst einmal Entwarnung. Ähnlich sieht es bei der 9.1 im Connection Manager aus: Johannes schätzt, dass rund 90 Prozent der Unternehmen CMAN gar nicht einsetzen. Nebenbei erklärt er, wofür der Connection Manager überhaupt gut ist — Tunneling im Oracle Net, Whitelisting und Blacklisting, kaskadierende Verbindungen zwischen Firewalls — und weist darauf hin, dass er ausschließlich mit der Enterprise Edition verwendet werden darf.

Kritischer wird es bei den unauffälligeren Einträgen. Die 8.8 in Spatial and Graph betrifft heute deutlich mehr Systeme als früher, weil Oracle diese Funktionen ab Version 19c kostenlos gemacht hat und sie seitdem vielerorts installiert sind. Und dann ist da die Rechteausweitung mit 8.8, die alle Datenbanken betrifft: Ein beliebiger angemeldeter Benutzer reicht aus, um die Datenbank zu übernehmen. Das ist die Lücke, wegen der gepatcht werden muss. Die 8.2 ist zwar ohne Anmeldung über Oracle Net ausnutzbar, betrifft aber nur die Versionen 23ai und 26ai.

Im Praxisteil geht es um die Reihenfolge. Johannes schert seine Datenbanken bewusst über einen Kamm, patcht aber sauber über die Stages von Test über Vorproduktion bis Produktion. Für ihn stellt sich nur noch die Frage nach dem Wann, nicht mehr nach dem Ob. Robert ergänzt die Entwicklerperspektive: Tests brauchen Zeit, weil sich das Verhalten der Systeme ändern kann. Dazu die Entwarnung, dass Oracle Performance-Patches seit einigen Jahren zwar ausliefert, aber nicht mehr automatisch aktiviert — Optimizer-Fixes muss man bewusst einschalten. Als Zeitrahmen nennt Johannes einen Monat, mit Vorrang für alles, was ohne Anmeldung erreichbar ist. Sein größtes Augenmerk gilt allerdings der Plattform-Verfügbarkeit: Linux ist versorgt, für Windows und AIX fehlen die Patches zum Aufnahmezeitpunkt noch. Umso wichtiger ist es, die Testsysteme jetzt vorzubereiten. Zum Schluss ein klarer Tipp aus der Praxis: AutoUpgrade nutzen. Es lädt die benötigten Patches automatisch herunter und patcht das Oracle Home, denkt auch an Dinge wie Data Pump und funktioniert entgegen einem hartnäckigen Gerücht auch ohne Internetverbindung auf dem Datenbankserver. Eine eigene Folge zu AutoUpgrade ist damit beschlossene Sache.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Prüf-Query für DBMS_CLOUD:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Diese Folge ist eine Eigenproduktion von ora2know.

Sponsored Link:

Database & Technology, Milano Web: D&T

Oracle 26ai Feature Häppchen für DBAs

Vier Häppchen, die an die Engine gehen

Die spannenden Sachen passieren im Maschinenraum, hatte Johannes Ahrends behauptet. In dieser Häppchen-Folge dreht Robert Marz den Spieß um: Diesmal fragt der Entwickler und der DBA erklärt. Es geht um die Features aus Oracle 26ai, die man im SQL kaum sieht und die im Betrieb, im Cluster und tief in der Datenbank-Engine ihre Wirkung entfalten.

Den Anfang macht die Transaction Priority. Wenn sich zwei Sitzungen um eine Sperre streiten, wartet bisher die eine, bis die andere fertig ist, und das kann im Extremfall Stunden oder Tage dauern. Mit einer Priorität lässt sich der niedriger priorisierte Langläufer nach Ablauf einer Frist zurückrollen, sodass die wichtigere Transaktion durchkommt. Gerade bei großen Maintenance-Operationen ist das praktisch, auch wenn standardmäßig alle Transaktionen dieselbe Priorität haben und man das erst testen sollte. Robert und Johannes sind sich einig: Ein sauberes Anwendungsdesign macht so ein Feature im Idealfall überflüssig.

Im RAC-Umfeld wird endlich gelöst, was Multitenant lange schwer gemacht hat. Eine Plugable Database war bisher keine Cluster-Resource, ihr Starten und Stoppen ließ sich nicht direkt steuern. Bei 40 oder 50 Datenbanken wird das schnell kritisch. In Oracle 26ai lassen sich PDBs als Resource verwalten und sogar in einer priorisierten Reihenfolge hochfahren. Das bringt die beiden zum eigentlichen Aufreger: Application Services. Seit etlichen Versionen sollte man eigene Services pro Anwendung definieren, doch viele nehmen immer noch die SID, weil das vor 20 Jahren auch funktioniert hat. Dabei steckt im Service der eigentliche Hebel, um Anwendung und Datenbank sauber zu steuern.

Bei Data Guard granular pro PDB raten beide zur Vorsicht. Technisch geht es, eine Standby kann man auf PDB-Ebene definieren, aber stellt man sich eine CDB mit 50 Plugable Databases vor, wird der Aufwand mit eigenen Redo-Logs und ungleicher Verteilung schnell unverhältnismäßig. Im Worst Case muss der DBA jemandem sagen, dass seine PDB ausgerechnet nicht abgesichert war. Klare Empfehlung: bei der klassischen Methode bleiben. Das letzte Häppchen geht am tiefsten: Lock-Free Reservations. Für zählerartige Tabellen, auf denen sich alle Sitzungen um denselben Wert prügeln, lässt sich eine Spalte sperrfrei definieren. Oracle garantiert die Konsistenz erst beim Commit und nimmt damit den Bottleneck heraus. Optimistische Nebenläufigkeit, jetzt auf Datenbank-Ebene statt in der Applikation. Und als Bonus: der lang ersehnte GRANT auf alle Objekte eines Schemas, der die riesige Lücke zwischen einer einzelnen Tabelle und „select any table" schließt.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Dieser Podcast ist eine TON.EINS Produktion.

Oracle Standard Edition 2: Noch zukunftsfähig?

Günstig, beliebt und mit ein paar handfesten Tücken

Oracle ist teuer, das wissen alle. Aber es gibt eine günstige Alternative: die Standard Edition 2. Robert Marz fragt nach, Johannes Ahrends erklärt als langjähriger SE2-Fan, was die kleine Edition wirklich kann und wo Oracle klare Grenzen zieht.

Zuerst die Herkunft des Namens. Früher gab es die Standard Edition und die Standard Edition One. Mit der Version 12.1.0.2 fasste Oracle beide zur Standard Edition 2 zusammen, mit der prägenden Grenze von maximal zwei Sockets. Die „2" steht also für die zweite Generation und zugleich für das Socket-Limit. Danach die harten Fakten: maximal zwei Sockets pro Server und 16 Threads, also rund acht Cores. Die Datenbankgröße selbst ist dagegen nicht begrenzt, eine 10-TB-Datenbank auf SE2 ist problemlos möglich.

Bei den Features wird es differenziert. SE2 kennt keine Optionen, kein Data Guard und seit Version 18 auch kein RAC mehr. Dafür sind Spatial, Graph und sogar AI Vector Search enthalten. Für die Hochverfügbarkeit gibt es Standard Edition High Availability (SEHA), die das Fehlen von RAC und Data Guard abfedert. Johannes erklärt nebenbei verständlich, was RAC und Data Guard überhaupt unterscheidet.

Das wichtigste Praxisthema ist die Socket-Falle. Auf modernen Multi-Chip- und Chiplet-Prozessoren, etwa Intel Xeon der Serie 6 sowie AMD Ryzen und EPYC, zählt laut Oracle Technology Price List jeder Chip als belegter Socket. Damit ist SE2 auf solcher Hardware nicht mehr erlaubt. Ein realer Kunde musste deshalb neue Server kaufen, und die Nachlizenzierung auf die Enterprise Edition geht schnell ins 40- bis 50-fache. Der Ausweg führt über die Oracle Database Appliance, wo eine Prozessorlizenz je acht aktivierte Cores gilt und SE2 auch mit Multi-Chip läuft.

Zum Schluss die aktuelle Lage rund um Oracle 26ai. On-premises läuft SE2 für 26ai auf den Oracle Engineered Systems, also etwa auf der Oracle Database Appliance oder auf Exadata. Auf beliebiger Hardware gibt es sie dagegen noch nicht. In der OCI Cloud ist sie ebenfalls verfügbar, und in den Oracle Licensing Guides ist bereits die 26.2 gelistet. Das Fazit der beiden: SE2 bleibt eine starke und günstige Wahl, solange man die Enterprise-Features nicht braucht. Vor dem Einsatz lohnt sich aber der genaue Blick auf die Hardware.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Dieser Podcast ist eine TON.EINS Produktion.

Oracle 26ai Feature Häppchen für Developer

Vier kleine Features, die lange genervt haben

Manchmal sind es die kleinen Dinge, die den Alltag besser machen. Robert Marz bringt Johannes Ahrends in dieser Häppchen-Folge ein paar Developer-Features aus Oracle 26ai mit. Alles Sachen, die lange gefehlt haben und jetzt endlich da sind.

Den Anfang macht IF NOT EXISTS und IF EXISTS für CREATE und DROP TABLE. Wer Skripte schreibt, die immer wieder laufen sollen, musste bisher umständlich abfangen, wenn eine Tabelle schon da war oder eben fehlte. Robert zeigt, warum das bei DROP ein Segen ist und warum man bei CREATE TABLE IF NOT EXISTS trotzdem vorsichtig sein sollte, denn geänderte Spalten werden dann einfach ignoriert.

Weiter geht es mit einem echten Boolean-Datentyp in SQL-Tabellen. Schluss mit der Einzeichenspalte voller J, N, Y und 0. Oracle übernimmt die Umwandlung, und nebenbei klären die beiden, was die dreiwertige Logik mit NULL macht. Danach das Ende einer Ära: Der Pflicht-FROM mit der DUAL-Tabelle ist Geschichte, ein SELECT ohne FROM ist jetzt erlaubt. Und zum Schluss der native JSON-Datentyp. Sein Speicherformat OSON ist offengelegt: Der Aufbau des OSON-Formats steckt quelloffen in den Thin Drivern für Python und JavaScript.

Die Kernbotschaft ist größer als die einzelnen Features. Oracle nutzt den technischen Vorsprung und räumt endlich auf, holt nach, was andere Datenbanken länger können, und hört auf die Entwickler.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Dieser Podcast ist eine TON.EINS Produktion.

APEX 26.1 ist da: Programmiert die KI jetzt unsere Apps?

Das KI-Release im Praxis-Check: APEXlang, AI Reports und AI Agents

Oracle APEX 26.1 ist da, nach rund anderthalb Jahren Pause. 24.2 war das letzte Release, danach kam im ganzen Jahr 2025 nichts Neues. Johannes Ahrends und Robert Marz ordnen das KI-Release in gut zwölf Minuten ein. Sie klären, was APEX überhaupt ist und wie sich die Low-Code-Plattform vom Vibe-Coding und vom KI-Coding mit Werkzeugen wie Claude Code abgrenzt.

Robert stellt die drei großen KI-Säulen vor. Mit APEXlang gibt es eine neue, deklarative und KI-freundliche Sprache, in der man nur noch beschreibt, was man haben möchte, ganz ohne die alten internen IDs. Passend dazu das Motto „if you generate it, you own it". Die AI Interactive Reports erlauben es Anwendern, ihre Reports per Knopfdruck in natürlicher Sprache umzubauen. Und mit den AI Agents lassen sich selbst definierte AI Tools im MCP-Stil bereitstellen.

„Die KI bekommt Werkzeuge statt direkten Zugriff auf die Daten" ist das Motto, das sich wie ein roter Faden durch die Episode zieht. Der Entwickler entscheidet, welche Daten überhaupt in Richtung KI gehen, und behält Governance und Sicherheit fest in der Hand. Zum Schluss beantworten die beiden die Praxisfragen. Läuft das noch auf Oracle 19? Welche Edition braucht man? Und warum kommt APEX trotzdem mit wenig Ressourcen aus? Das liegt an den Metadaten in der Datenbank, am PL/SQL-Rendering und an der Auslieferung über ORDS.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe. Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz.

Über diese Podcast-Produktion:

Dieser Podcast ist eine TON.EINS Produktion.

Oracle Patch Mythos

Oracle ändert seinen Patch-Release-Zyklus

Anthropic hat ein neues Large Language Model (LLM) namens Claude Mythos entwickelt. Das Modell wurde zunächst nicht öffentlich zugänglich gemacht. Stattdessen bekamen ausgewählte Unternehmen wie Microsoft und Amazon ein kontrolliertes Preview.

Mythos ist enorm gut darin, Sicherheitslücken und Schwachstellenketten zu entdecken. Im Rahmen des Projekts Glasswing erhielten Unternehmen wie Oracle die Gelegenheit, mit Hilfe von Claude Mythos neue Lücken zu finden und zu schließen, bevor sie öffentlich bekannt werden.

Zur Erinnerung der bisherige Patch-Zyklus von Oracle: Quarterly Release Updates (RU) erscheinen einmal pro Quartal, immer am Dienstag, der dem 15. des ersten Quartalsmonats am nächsten liegt. Früher gab es zusätzlich Release Update Revisions (RURs). Diese wurden vor zwei bis drei Jahren eingestellt. Als Ersatz dienen die Monthly Release Patches (MRPs), die seit etwa zwei Jahren verfügbar sind.

Oracle kündigt jetzt zusätzlich Monthly Critical Security Patch Updates (CSPUs) an. Diese fokussieren sich auf kritische Sicherheitslücken, etwa auf unauthentifizierten Remote-Zugriff. Sobald ein Patch veröffentlicht wird, lässt sich der zugrunde liegende Exploit in der Regel rekonstruieren. Schnelles Einspielen ist deshalb entscheidend.

Aktueller Stand im April und Mai 2026: Das Quartals-RU vom April wurde zweimal verschoben, vom 21.04. auf den 28.04. und schließlich auf den 30.04. Bereits jetzt liegen zahlreiche zusätzliche Patches vor, die beim Einspielen berücksichtigt werden sollten, unter anderem ein JDK-Patch und ein Datapump-Bundle-Patch. Das nächste Monthly CSPU ist für den 28. Mai 2026 geplant. Das ist weniger als ein Monat nach dem letzten Quartals-RU. Das nächste Quartals-RU folgt im Juli 2026.

Einspielen oder warten? Datenbanken, die aus dem Internet erreichbar sind, müssen monatlich gepatcht werden. Bei internen Datenbanken kommt es auf die Risikoexposition und die Patch-Zyklen im Unternehmen an. Dabei darf man nicht vergessen, dass Patching nicht nur die Datenbank betrifft, sondern das gesamte System mit Betriebssystem, Storage, Netzwerk und Windows-Patches. Oracle weist außerdem darauf hin, dass Quarterly RUs beim Release bereits rund drei Monate alt sind. Genau diese Lücke sollen die monatlichen Patches schließen.

Für Version 19 stellt Oracle jetzt Gold-Images bereit. Das manuelle Zusammensuchen von Base-Release, RU und Sub-Patches entfällt damit. Beim In-Place-Verfahren wird die Datenbank heruntergefahren, der Patch auf das bestehende Oracle Home angewendet und die Datenbank wieder hochgefahren. Beim empfohlenen Out-of-Place-Verfahren wird ein neues Oracle Home parallel aufgebaut und gepatcht. Anschließend wird die Datenbank vom alten ins neue Home geschwenkt.

Oracle Cloud als Lösung? In der OCI Autonomous Database werden Patches automatisch von Oracle eingespielt. Die neue Patch-Frequenz nutzt Oracle auch als Argument für die Migration in die eigene Cloud.

Diese Folge in der Übersicht:

Weiterführende Links und Ressourcen:

Die Podcast-Hosts und Director:

Über O wie Datenbank:

Der deutschsprachige Oracle-Datenbank-Podcast von ora2know. Johannes Ahrends, Robert Marz und Oliver Pyka bringen zusammen über 90 Jahre Oracle-Erfahrung mit und sprechen alle vier Wochen über das, was DBAs, Entwickler und IT-Entscheider wirklich bewegt: Migration, Architektur, neue Features, Betrieb und Strategie rund um die Oracle Datenbank. Praxisnah, meinungsstark und ohne Marketing-Sprech.

Über ora2know:

Wissen teilen, Netzwerk aufbauen. ora2know ist eine unabhängige Community für Oracle-Datenbank-Administratoren und -Entwickler im deutschsprachigen Raum. Unser Ziel ist der praxisnahe Austausch von Wissen und Erfahrungen rund um Oracle Database, Oracle APEX und Oracle AI. Ohne kommerzielle Interessen, getragen von Enthusiasmus und gegenseitiger Hilfe.

Ob DBA, Entwickler oder Architekt: ora2know verbindet Oracle-Profis in Deutschland, Österreich und der Schweiz. Bei unseren Veranstaltungen, im Podcast und im Newsletter entsteht eine lebendige Gemeinschaft, die voneinander lernt.

Über diese Podcast-Produktion:

Dieser Podcast ist eine TON.EINS Produktion.