
Sign up to save your podcasts
Or


Oracle-Klassentreffen in Nürnberg: Vorschau auf die DOAG Anwenderkonferenz 2026
Klassentreffen, eigener Stand, Live-Aufnahmen und die Vorträge des ora2know-Vorstands
Heute bleibt die Technik zu Hause. Vom 17. bis 19. November findet in Nürnberg die DOAG Anwenderkonferenz 2026 statt, und Johannes feiert dort sein 30-jähriges Jubiläum: Seine erste DOAG war 1996. Robert hat die 30 Jahre auch schon fast voll. Beide haben seitdem kaum eine Konferenz ausgelassen. Johannes erinnert sich an seinen Vortrag von 1998 zum Enterprise Manager 1.1, seinem Urteil nach ein furchtbares Produkt.
Drei Konferenztage, an zwei davon parallel die KI Navigator: Im Programm stehen Datenbank, Development, Performance und Security, und ohne AI geht es natürlich auch nicht. Den Grund für die Reise liefert Johannes mit einem Augenzwinkern: Nürnberg ist super, die Vorträge stören etwas. Man trifft Leute, diskutiert und wird Probleme und Wünsche direkt beim Oracle-Produktmanagement los. Robert schätzt das Wissen aus erster Hand und die Gespräche mit Menschen, die man ein Jahr nicht gesehen hat. Am meisten lernen beide bei der Vorbereitung ihrer eigenen Vorträge. Newcomer, die selbst auf die Bühne möchten, dürfen sich gern an die Hosts wenden.
ora2know ist in diesem Jahr zum ersten Mal mit einem eigenen Stand vertreten. Dazu entstehen vor Ort zusammen mit TON.EINS Live-Aufnahmen mit Kommentaren von Teilnehmern, die noch am selben Tag im Podcast erscheinen können.
Den größten Teil der Folge nimmt das Programm ein. Die beiden gehen die Vorträge des ora2know-Vorstands Tag für Tag durch, darunter Roberts Reihe zu KI als Co-Entwickler, Annotations und RAG sowie einem MCP-Server über ORDS, Olivers Vortrag zum ACE-Apprentice-Programm, Martin Kliers Vorträge zu KI im Kriegseinsatz und zur Performance-Optimierung und das Quiz „Wer weiß denn sowas" mit Axel vom Stein und Markus Flechtner. Johannes spricht am Mittwochabend im großen Saal Tokio über die neuen Features für DBAs, direkt vor der Keynote zum Thema Entscheidungen unter Druck. Am Donnerstag folgt The Battle: Zwei Leute streiten über die These, KI sei nur ein Hype, und die Positionen werden erst auf der Bühne ausgelost.
Zum Schluss gibt es die Keynotes und Tipps für das restliche Programm, von den Upgrade-Vorträgen von Dierk Lenz und Sascha Schäfer über Mike Dietrich, Beda Hammerschmidt und Michael Paege bis zur Oracle Database Feedback Session. Alle, die nicht nach Nürnberg kommen, bekommen die Eindrücke von der Konferenz über den Podcast.
Diese Folge in der Übersicht:
Ergänzungen zur Folge:
Die Aufnahme entstand am 16. Oktober 2026, einiges hat sich seitdem bewegt oder lässt sich präziser sagen.
Termine:
Vorträge des ora2know-Vorstands:
Dienstag, 17. November:
Mittwoch, 18. November:
Donnerstag, 19. November:
Raumangaben können sich bis zur Konferenz noch ändern, maßgeblich ist die Agenda.
Weiterführende Links und Ressourcen:
Ü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:
Aufgenommen am 16. Oktober 2026.
Diese Folge ist eine Eigenproduktion von ora2know.
Oracle 26ai: Die Datenbank ist kein Sprachmodell
Die KI sitzt außerhalb, die Datenbank liefert Daten, Suche und Rechteprüfung
Die Folge beginnt mit einer Wette. Aus Oracle 23ai ist Oracle 26ai geworden, und Robert tippt für nächstes Jahr auf SI für Superintelligence. Johannes hält dagegen, kurz vor der Oracle AI World, auf der traditionell Namen geändert werden. Der Einsatz: eine Tüte Gummibärchen. Aufgelöst wird spätestens nächstes Jahr.
Dann die eigentliche Frage des DBAs: Wo steckt in der Datenbank die KI? Robert ordnet ein. Die Datenbank trainiert kein Sprachmodell und ist selbst keins. Sie speichert Vektoren, ruft Sprachmodelle auf und kann kleinere Modelle sogar selbst ausführen. Johannes ergänzt den Punkt, der ihm am wichtigsten ist: Zugriffsrechte, Authentifizierung und Autorisierung bleiben bei der Datenbank. AI Vector Search ist in Oracle 26ai ohne Aufpreis enthalten.
Mit Vektoren wird die Suche praktischer. Wer nach „Kündigung" sucht, findet auch „Vertrag beenden", ohne dass ein Wort übereinstimmt. Mit LIKE oder Stichwörtern braucht man dagegen den exakten Suchbegriff. Oracle 26ai bringt dafür den Datentyp VECTOR mit, zwischen zwei Vektoren lässt sich der Abstand berechnen. Die Embeddings erzeugt entweder ein externes Modell oder ein kleines Modell, das direkt in die Datenbank geladen wird. Ein Vektor ist eine lange Reihe von Gleitkommazahlen, seinen Sinn bekommt er erst durch das Modell, das ihn erzeugt hat. Vergleichen lassen sich deshalb nur Vektoren aus demselben Modell, und schon ein Versionswechsel bedeutet, alle Vektoren neu zu berechnen.
Johannes sieht die Betriebsseite. Bei fast 1000 Dimensionen pro Vektor ist man schnell bei zweistelligen Gigabyte, dazu kommen spezielle Indextypen, die ebenfalls Platz brauchen. Modelle, die in der Datenbank laufen, belasten den Datenbankserver. Vector Search mal eben dazuzunehmen, wird also nicht so einfach.
Damit eine KI die Daten versteht, braucht sie die Bedeutung der Spalten. Bei älteren Anwendungen mit Spaltennamen wie KZ_ST_2 hilft das wenig. Oracle hat dafür Annotations eingeführt: Beschreibungen an Tabellen und Spalten, die jede Anwendung nutzen kann. Auf Johannes' Frage nach deutschen und internationalen Inhalten antwortet Robert, dass mehrsprachig trainierte Modelle auf den Inhalt achten und die Sprache egal ist. Multimodale Modelle verarbeiten sogar Bilder.
In den Cloud-Varianten der Oracle-Datenbank gibt es Select AI. Man schreibt SELECT AI und dahinter die Frage auf Deutsch, die Datenbank lässt ein SQL-Statement erzeugen und führt es aus. Robert hat sich die Funktion für seine lokale Datenbank mit wenigen Zeilen PL/SQL nachgebaut, letztlich ruft er ein Sprachmodell auf und wertet die Antwort aus. An das Modell gehen dabei die Metadaten: Tabellenbeschreibungen und, wenn vorhanden, Annotations. Die Daten selbst bleiben in der Datenbank. Syntaktisch ist das erzeugte SQL heute fast immer korrekt, ob es inhaltlich stimmt, muss man prüfen. Je mehr Kontext das Modell über Spalten und Beziehungen hat, desto besser wird das Ergebnis.
Ergänzung zur Folge: Im Gespräch heißt es, Select AI gebe es aktuell nur in der Cloud. Seit Oracle 26ai für Linux x86-64 on-prem verfügbar ist, läuft Select AI auch dort. Voraussetzung ist, dass die DBMS_CLOUD-Pakete nachinstalliert werden (catclouduser.sql und dbms_cloud_install.sql über catcon.pl). Dazu kommen eine Netzwerk-ACL und ein Credential für den Endpunkt des Sprachmodells. Details stehen im Select AI User's Guide für Oracle 26ai, verlinkt unten.
Das meiste Wissen einer Firma steckt in Dokumenten, Handbüchern und Verträgen. Dafür gibt es RAG, Retrieval Augmented Generation. Dokumente werden in Abschnitte zerlegt, eingebettet und mit einem Vektorindex in der Datenbank abgelegt, das PL/SQL-Paket DBMS_VECTOR_CHAIN übernimmt das. Johannes will sein Oracle-Buch auf diese Weise durchsuchbar machen. Für die Vektorisierung reicht ein kleines Modell auf einer kleinen Grafikkarte, die Daten müssen die Datenbank dafür nicht verlassen. Halluzinationen gibt es weiterhin, bei vorgegebenen Dokumenten aber deutlich weniger. Die Qualität steht und fällt mit dem Zerschneiden in sinnvolle Abschnitte, die sich in der Praxis leicht überlappen. Weil die Quellen angezeigt werden, können Anwender jede Antwort im Originaltext nachlesen.
Zum Schluss geht es um Agenten. Seit gut einem Jahr gibt es das Model Context Protocol (MCP), einen offenen Standard, über den KI-Assistenten Werkzeuge und Datenquellen ansprechen. Oracle stellt mehrere MCP-Server bereit: den SQLcl MCP Server für die lokalen SQLcl-Verbindungen, MCP in ORDS seit Version 26.2 und Managed MCP Server in OCI. Agenten können damit die Datenbank befragen und sogar administrieren. Das muss man allerdings wollen, und Johannes will es definitiv nicht. Für einen Agenten, der DROP TABLE ausführen will, hat der Default Blame Acceptor eine klare Antwort: Ein Agent bekommt wie jeder andere Benutzer die geringstmöglichen Rechte. Für Vector Search reicht Lesezugriff, DML läuft über einen anderen Benutzer, DDL gar nicht. Das ist schlicht saubere Rechtevergabe.
Im Fazit will Johannes RAG mit seinem Buch ausprobieren und sich Agenten ansehen, die ihn im Alltag unterstützen. Robert zeigt seine Beispiele erstmals auf der DOAG 2026 Konferenz + Ausstellung in Nürnberg und sieht in der Vektorisierung die Zukunft der Suche in der Datenbank. Ganz am Ende meldet sich Oliver Pyka mit einem Hinweis der Redaktion: ora2know lädt am 9. November 2026 zur Oracle AI World Nachlese nach Frankfurt ein.
Diese Folge in der Übersicht:
Termine:
Weiterführende Links und Ressourcen:
Beispiele:
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 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.
From the publisher's feed