Oracle Read-Only Homes: Software und Konfiguration endlich getrennt

Was das Read-Only Oracle Home wirklich macht, wie man es einschaltet und an welcher Stelle es beim Patchen doch noch knirscht. 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: Oracle Homes werden schnell elf bis zwölf Gigabyte groß und sammeln über die Jahre allerhand an, das dort nicht hingehört. Der Kern des Problems: Konfigurationsdateien liegen im Oracle Home, obwohl dort nur austauschbare Software liegen sollte. Read-Only Oracle Home gibt es seit Version 18. Der Name ist irreführend — das Verzeichnis bleibt technisch beschreibbar. Eingeschaltet wird es mit roohctl -enable, und zwar nur, solange weder Datenbank noch Listener laufen. Danach wandert die Konfiguration unter ORACLE_BASE: SPFILE und init.ora ins dbs-Verzeichnis, listener.ora, tnsnames.ora und sqlnet.ora ins homes-Verzeichnis. Verfügbarkeit: in 19c optional, in 21c Pflicht, in 23ai und 26ai wieder optional. Der Haken: Unter homes steckt erst der Oracle Home Name und dann network/admin — beim Out-of-Place-Patching muss die Listener-Konfiguration deshalb doch wieder umziehen. Unter Windows heißt das Verzeichnis database statt dbs, ohne erkennbaren Grund. Der eigentliche Zweck: sauberes Out-of-Place-Patching, bei dem die neue Software neben die alte installiert und dann umgeschaltet wird. Stolperfallen: Skripte mit hart kodierten Pfaden und ein Mischmasch aus Homes mit und ohne Read-Only. Werkzeuge für Skripte: orabase, orabasehome und orabaseconfig ermitteln die Pfade zur Laufzeit. Praxistipp: AutoUpgrade kann die Software direkt als Read-Only Oracle Home installieren. Weiterführende Links und Ressourcen: ora2know Website About Read-Only Oracle Homes (Oracle Docs, 26ai) Configuring Read-Only Oracle Homes (Oracle Docs, 19c) Enabling a Read-Only Oracle Home (Oracle Docs) Evolution of Oracle Homes (Oracle Docs) About Oracle Base Homes (Windows) (Oracle Docs) About the Oracle AutoUpgrade Utility (Oracle Docs) Folge 009: Oracle Juli-CPU 2026 (die Folge, in der AutoUpgrade schon einmal Thema war) Nützliche Befehle: # Read-Only Oracle Home einschalten (vor dem ersten Start von DB und Listener) $ORACLE_HOME/bin/roohctl -enable # Pfade zur Laufzeit ermitteln, statt sie im Skript hart zu verdrahten $ORACLE_HOME/bin/orabase $ORACLE_HOME/bin/orabasehome $ORACLE_HOME/bin/orabaseconfig Die Podcast-Hosts und Director: Johannes Ahrends: Oracle ACE, DBA, ora2know. Web: carajandb.com Robert Marz: Oracle ACE, IT-Architect, ora2know. Web: robbie.databee.org Oliver Pyka: Oracle ACE, Freiberufler, ora2know. Web: pyka.de Ü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.