Verhaltensänderungen in Oracle 12c & 18c – Der Teufel steckt im Detail
In Zeiten der agilen Softwareentwicklung und DevOps und den damit verbunden Continuous-Integration- und Continuous-Delivery-Prozessen, kommen Unternehmen zur Abbildung von wiederkehrenden Prozessen um die Einführung von Automatisierungswerkzeugen – wie zum Beispiel Ansible oder Puppet – nur schwer herum. Automation kann an vielen Stellen, wie zum Beispiel bei der Installation von Oracle-Software, der Bereitstellung einer neuen Datenbank oder aber auch zum Einspielen aktueller Patches verwendet werden. Bei all diesen Beispielen setzen die Datenbankadministratoren voraus, dass sich die Oracle-Software so verhält, wie man es kennt und implementiert hat. Änderungen an den Prozessen werden in der Regel dann vorgenommen, wenn ein Versionssprung, wie zum Beispiel von 12c auf 18c, ansteht.
Doch was passiert, wenn sich die Oracle-Software durch einen neuen Patchstand nicht mehr so verhält, wie man es erwartet und vor allem, wie es der etablierte Prozess voraussetzt? In vielen Fällen fallen solche Verhaltensänderungen erst während der aktiven Benutzung auf und da ist es dann bereits zu spät. Die Zeit, die für die Analyse der Probleme verstreicht, kann Verzögerungen auf anderen Ebenen nach sich ziehen oder im schlimmsten Fall sogar Geld oder Reputation kosten.
Dieser Artikel zeigt eine Reihe von Verhaltensänderungen in Oracle 12c und 18c. Dabei werden die beiden Software-Produkte Grid Infrastructure und Oracle Database betrachtet. Viele dieser kleinen Verhaltensänderungen sind zudem nur spärlich bis gar nicht dokumentiert.
Die Gefahr lauert im Verborgenen
Jedes Upgrade einer Oracle-Software oder auch nur das Einspielen eines Patches birgt die Gefahr, dass sich das Verhalten des eingesetzten Oracle-Produktes ändert. Bei einem Major-Upgrade, also dem Anheben der Version von zum Beispiel 12c auf 18c, ist die Wahrscheinlichkeit hoch, dass es an der einen oder anderen Stelle Verhaltensänderungen geben wird, die man im Vorfeld näher betrachten sollte. Ein guter Einstiegspunkt hierfür sind der New Features und Database Upgrade Guide. Bei letzterem sollte dem Kapitel "Behavior Changes, Deprecated and Desupported Features" ein Hauptaugenmerk gewidmet werden.
Die Hauptgefahr besteht aber bei Änderungen, die nicht offiziell in der Oracle-Dokumentation oder im My Oracle Support Portal dokumentiert sind. In vielen Fällen ist es so, dass nach dem ersten Auftreten einer Verhaltensänderung und einem sich daraus ergebenden Service Requests eines betroffenen Oracle-Kunden eine My Oracle Support Note entsteht. Um eine gewisse Sicherheit für den Aktualisierungsprozess zu erhalten, sollten die vierteljährlichen Updates vorher gut getestet oder erst mit Verzug eingespielt werden. Bei letzterer Herangehensweise sollten vor dem Einspielen des Patches das My Oracle Support Portal oder entsprechende Oracle-Blogs nach Hinweisen durchsucht werden.
Ein Positivbeispiel für Verhaltensänderungen, die standardmäßig deaktiviert sind, sind die Optimizer Fixes. Optimizer Fixes können das Verhalten des Optimizers gravierend verändern und sollten vor Aktivierung intensiv getestet werden. Ansonsten können Performanceprobleme das Resultat sein.
Infrastruktur
Dieses Kapitel widmet sich Verhaltensänderungen, die sich bei der Grid Infrastructure ergeben haben.
OCR Backups in ASM Diskgroup
Für einen Cluster ist die Oracle Cluster Registry (OCR) eine der wichtigsten Komponenten für den reibungslosen Betrieb. Eine regelmäßige Sicherung der OCR ist somit unerlässlich. Bis einschließlich Version 12c Release 1 erstellte der OCR Master alle vier Stunden ein Backup und speicherte dies unter $ORACLE_HOME/cdata ab.
Ab Oracle 12c Release 2 werden OCR Backups in einer ASM Diskgroup abgelegt – standardmäßig wird die erste angelegte ASM Diskgroup verwendet. Der Vorteil dieser Speicherung ist der, dass alle Cluster-Knoten Zugriff auf die OCR Backups haben.
Doch was passiert, wenn die ASM Diskgroup nicht mehr gemounted werden kann, weil es zum Beispiel Probleme beim Starten des Oracle Stacks gibt oder die dazugehörigen LUNs nicht mehr verfügbar sind? Je nach Situation kann an dieser Stelle nur noch das ASM Metadata Dump Utility (amdu) helfen, um Dateien aus einer nicht gemounteten Diskgroup zu extrahieren.
$> amdu -diskstring="AFD:*" -extract MGMT.283
Die Verwendung von amdu ist nicht trivial und sollte wenn möglich vermieden werden. Das Verwenden einer Dateisystem-Lokation unterbindet Oracle mit einer entsprechenden Fehlermeldung.
$> ocrconfig -backuploc /ocr PROT-42: The specified backup location '/ocr' is not an ASM disk group.
Um sich vor solchen Problemen zu schützen, sollte das OCR Backup regelmäßig aus ASM herauskopiert und auf einen externen Backup-Server kopiert werden.
$> asmcmd cp +MGMT/*/OCRBACKUP/day.ocr* /ocr/day.ocr_$(date "+%Y%m%d") copying +MGMT/db18c-ol7-r1/OCRBACKUP/day.ocr.283.975471195 -> /ocr/day.ocr_20180510
Alternativ zu asmcmd kann ocrconfig verwendet werden. Wobei es hierbei aber keine Möglichkeit zur Verwendung von Wildcards gibt und der Befehl muss als root-Benutzer ausgeführt werden.
$> ocrconfig -copy +MGMT/db18c-ol7-r1/OCRBACKUP/day.ocr.283.975471195 /ocr/day.ocr_$(date "+%Y%m%d") PROT-60: The Oracle Cluster Registry backup is copied to '/ocr/day.ocr_20180510'.
Fehlende oratab-Einträge
In der oratab-Datei, die zum Beispiel unter Linux unter dem Pfad /etc/oratab zu finden ist, werden neben der ASM-Instanz alle installierten Datenbanken aufgelistet. Gepflegt wird diese Datei automatisch durch den Database Configuration Assistent (kurz DBCA) oder im Cluster-Umfeld durch den oraagent – zu erkennen an dem Kommentar "# line added by Agent".
Anmerkung: Das in diesem Kapitel beschriebene Problem tritt unter Windows nicht auf.
+ASM1:/app/grid/product/12.2.0.1:N # line added by Agent -MGMTDB:/app/grid/product/12.2.0.1:N CRMDB:/app/oracle/product/12.2.0.1:N # line added by Agent ERPDB:/app/oracle/product/12.1.0.2:N # line added by Agent
Für die Datenbank MGMTDB, die das Grid Infrastructure Management Repository (kurz GIMR) beinhaltet, wird kein Kommentar durch den oraagent angefügt. Warum dies so ist, erfahren wir an späterer Stelle des Artikels.
Die oratab bietet zum Beispiel die Grundlage für das mit der Oracle-Installation mitgelieferte oraenv-Skript, das zum Setzen von Datenbankumgebungen (ORACLE_HOME, ORACLE_SID, usw.) verwendet werden kann. Zu alledem verwenden viele Shell-Skripte sehr häufig die oratab-Datei, um auf einfache Art und Weise den Oracle-Home-Pfad der Grid Infrastructure oder Oracle-Database-Installation zu ermitteln.
Mit dem Oktober 2017 Release Update (und höher) wurde das Verhalten der oratab-Aktualisierungen im Cluster-Umfeld geändert. Nach der Installation des Release-Updates werden alle Einträge, die den Kommentar "# line added by Agent" enthalten, automatisch entfernt. Betroffen von dieser Löschroutine sind nur Datenbanken ab Oracle 12c Release 2. Daraus würde sich folgendes Bild ergeben.
-MGMTDB:/app/grid/product/12.2.0.1:N ERPDB:/app/oracle/product/12.1.0.2:N # line added by Agent
Die GIMR-Datenbank bleibt von der Löschroutine unberührt und das obwohl sie eine Oracle-12c-Release-2-Datenbank ist. Dieser Eintrag wird deswegen nicht berücksichtigt, weil Oracle absichtlich nicht den Kommentar "# line added by Agent" hinzugefügt hat.
Die Bereinigung wird in der Trace-Datei ohasd_oraagent_grid.trc protokolliert.
ConfigFile::parse mmap name:+asm1 nameWithCase:+ASM1 value:/app/grid/product/12.2.0.1:N comment:line added by Agent ConfigFile::parse mmap name:-mgmtdb nameWithCase:-MGMTDB value:/app/grid/product/12.2.0.1:N comment: sclsnInstAgent::sCleanEntry - delete alt(sid) entry AsmAgent:getOracleSidAttrib 3 getResAttrib GEN_USR_ORA_INST_NAME oracle_sid:+ASM1 AsmAgent:getOracleSidAttrib oracleSid:+ASM1 sclsnInstAgent::sCleanEntry - key = +ASM1 ConfigFile::parse parseLine name: value: comment: ConfigFile::parse mmap name:-mgmtdb nameWithCase:-MGMTDB value:/app/grid/product/12.2.0.1:N comment: ConfigFile::updateInPlace copy configfile:/etc/oratab to backup:/app/grid/product/12.2.0.1/srvm/admin/oratab.bak.kn01p3db306 ... ConfigFile::parse parseLine name: value: comment: ConfigFile::parse mmap name:-mgmtdb nameWithCase:-MGMTDB value:/app/grid/product/12.2.0.1:N comment: ConfigFile::updateInPlace file /etc/oratab is updated sclsnInstAgent::sCleanEntry - key[+ASM1] is cleaned
Wie man erkennen kann, wird die Datei zunächst vollständig eingelesen und anschließend von den nicht mehr benötigten Einträgen bereinigt. Vor der Bereinigung wird eine Sicherung der oratab unter $ORACLE_HOME/srvm/admin/oratab.bak.<Hostname> angelegt.
Ohne diese Einträge kann das oraenv-Werkzeug nicht mehr verwendet werden. Dies ist daran zu erkennen, dass nach dem Oracle-Home-Pfad gefragt wird.
$> . oraenv ORACLE_SID = [oracle] ? +ASM1 ORACLE_HOME = [/home/oracle] ? /u00/app/grid/product/18.0.0.0 The Oracle base has been set to /u00/app/oracle
Um diesem Problem vorzubeugen, gibt es mehrere Möglichkeiten:
- Vor dem Einspielen des Release-Updates müssen alle "# line added by Agent"-Kommentare aus der oratab-Datei entfernt werden.
- Nach dem Einspielen des Release-Updates müssen die entfernten oratab-Einträge manuell hinzugefügt werden (ohne Kommentar).
- Rücksicherung der oratab-Sicherung und anschließendes Entfernen der Kommentare.
- Anpassung des Verfahrens/ der Skripte, um die Abhängigkeit zur oratab-Datei zu lösen.
Für weitere Details siehe My Oracle Support Note Applying 12.2.0.1.171017 RU (patch 26737266) To 12.2 Cluster Removes Oratab Entries (Doc ID 2329359.1) [1].
Management-Tools
Dieses Kapitel widmet sich Verhaltensänderungen bei den Management Tools.
Password File Creation Utility (orapwd)
Komplexitätsregeln für Password File
Wer gerne das Passwort "manager" für das Password File einer Oracle-Datenbank verwendet, wird ab Oracle 12c Release 2 eine Enttäuschung erleben. Ab dieser Version überprüft orapwd, ob die folgenden Komplexitätsregeln erfüllt sind.
- Mindestens 8 Zeichen,
- Keine Anführungszeichen,
- Mindestens einen Buchstaben,
- Mindestens eine Zahl,
- Mindestens ein spezielles Zeichen,
- Benutzername darf nicht enthalten sein (auch nicht rückwärts geschrieben),
- Passwort darf nicht das Wort oracle enthalten und
- Passwort darf nicht gleich dem Datenbanknamen sein.
Erfüllt das Passwort nicht die erforderliche Komplexität, bricht das Anlegen des Password Files mit einem OPW-00029 ab.
$> orapwd file=$ORACLE_HOME/dbs/orapwDB01 password=manager force=y OPW-00029: Password complexity failed for SYS user : Password must contain at least 8 characters.
Im DBCA können nach wie vor weniger komplexe Passwörter verwendet werden. Dies liegt daran, dass der DBCA beim Anlegen des Password Files die FORMAT=12-Klausel verwendet – der Standardwert ist 12.2. Durch die Verwendung der älteren Version stehen die folgenden Features nicht zur Verfügung:
- Granting administrative privileges to external users.
- Enable SSL and Kerberos authentication for administrative users.
Anmerkung: Für Oracle 18c wurde kein neues Format eingeführt – der maximale Wert bleibt bei 12.2.
Um trotzdem ein weniger komplexes Passwort mit der aktuellen Version verwenden zu können, kann ein bestehendes Passwort migriert werden. Hierbei werden die Komplexitätsregeln nicht angewendet.
Zunächst muss ein Dummy Password File im 12c-Format erstellt werden. Anschließend kann dieses Dummy Password File in das neue Format migriert werden.
$> orapwd file=$ORACLE_HOME/dbs/orapwDB01.tmp password=oracle force=y format=12 $> orapwd file=$ORACLE_HOME/dbs/orapwDB01 input_file=$ORACLE_HOME/dbs/orapwDB01.tmp
Die aktuelle Version eines Password Files kann ebenfalls mit orapwd ausgelesen werden.
$> orapwd describe file=$ORACLE_HOME/dbs/orapwDB01 Password file Description : format=12.2
Generell sollte aus Sicherheitsaspekten ein komplexes Passwort verwendet werden, da die Password-File-Authentifizierung immer dann verwendet wird, wenn sich ein Benutzer mit administrativen Privilegien (z.B. SYSDBA, SYSOPER, SYSBACKUP, …) an einer lokalen oder remote-Datenbank anmelden möchte.
Anmerkung: Bei einer lokalen Datenbank erhält die Betriebssystemauthentifizierung den Vorrang, wenn der angemeldete Benutzer Mitglied der entsprechenden Betriebssystemgruppe (z. B. dba, oper, backupdba) ist.
Für weitere Details siehe My Oracle Support Note From 12.2 , orapwd enforces password complexity rules (Doc ID 2294754.1) [2].
Database Configuration Assistant (DBCA)
Auch beim DBCA gab es die eine oder andere Änderung, von denen ich gerne zwei in diesem Kapitel vorstellen möchte.
Automatische Ausführung von datapatch
Bis zur Version 12c Release 1 mussten nach dem Anlegen einer neuen Datenbank noch die SQL-Anteile der installierten Patches in die Datenbank eingespielt werden. Hierfür wurde bei Oracle 11g das catbundle.sql-Skript ausgeführt. Mit der Version 12c wurde das SQL Patching Tool (Datapatch) eingeführt.
Ab der Version 12c Release 2 wird die Installation der SQL-Anteile automatisch nach dem Anlegen einer neuen Datenbank ausgeführt. Hierfür erweitert Oracle das postDBCreation.sql-Skript um den folgenden Aufruf.
host /u00/app/oracle/product/12.2.0.1-EE/OPatch/datapatch -skip_upgrade_check -db DB01;
Dabei ist zu beachten, dass dieses Verhalten nur bei Datenbanken, die auf der "Custom Database"-Vorlage aufbauen, auftritt. Sobald eine Vorlage verwendet wird, die Datafiles enthält, wird datapatch nicht ausgeführt.
Anmerkung: Ein bestehender Prozess muss nicht angepasst werden, da ein erneuter Aufruf von datapatch keine weitere Arbeit vorfindet und sich wieder beendet.
Automatic Memory Management (AMM)
Wer gerne auf das Automatic Memory Management für die Speicherverwaltung der Datenbank zurückgreift, wird ab Oracle 12c Release 2 umdenken müssen. Denn ab dieser Version wird AMM nicht mehr unterstützt, sobald der verwendete Server mehr als 4 GB Hauptspeicher besitzt – was in der heutigen Zeit eher häufiger vorkommt. Beim Versuch AMM zu verwenden, verweigert der DBCA mit der folgenden Fehlermeldung die weitere Konfiguration. Somit bleibt neben der manuellen Speicherverwaltung nur das Automatic Shared Memory Management (kurz ASMM). Dies hat zudem den Vorteil, dass die Verwendung von HugePages ermöglicht wird.
Für weitere Details siehe My Oracle Support Note 12.2:[INS-35178] The Automatic Memory Management Option Is Not Allowed During RunInstaller or Using DBCA If Physical Memory Is Greater Than 4G. (Doc ID 2244817.1) [3].
Oracle Database
Neues Timestamp-Format für Alert-Log-Einträge
Mit Oracle 12c Release 2 wurde das Uniform Log Timestamp Format für Einträge in den Alert Logs eingeführt. Dadurch ändert sich das Format von Wochentag-Monat-Tag-Uhrzeit-Jahr- zu Jahr-Monat-Tag-Zeitstempel.
- Alt: Thu May 03 14:50:34 2018
- Neu: 2018-05-03T14:44:28.273034+02:00
Ein weiterer Vorteil des neuen Formats ist die Unabhängigkeit zu der Spracheinstellung. Durch das neue Format wird das Parsen des Alert Logs vereinfacht.
Anmerkung: Die XML-Variante des Alert Logs, die mit dem Automatic Diagnostic Repository (kurz ADR) eingeführt wurde, verwendet seit Anbeginn das standardisierte Format.
Über den Parameter UNIFORM_LOG_TIMESTAMP_FORMAT kann das geänderte Verhalten rückgängig gemacht werden. Wenn der Parameter auf FALSE gesetzt wird, wird das alte Format verwendet. Diese Änderung kann im laufenden Betrieb durchgeführt werden.
SQL> ALTER SYSTEM SET uniform_log_timestamp_format = FALSE SCOPE=BOTH;
Leider verwenden nicht alle Oracle-Komponenten das neue Format. Die Listener Logs verwenden zum Beispiel das neue Format, wobei die Clusterware Logs ein eigenes Format verwenden.
2018-05-01 23:42:16.941 [OCSSD(2707)]CRS-1719: Cluster Synchronization Service daemon (CSSD) clssnmSendingThread not scheduled for 2790 msecs. 2018-05-02 21:01:37.839 [OCSSD(2707)]CRS-1719: Cluster Synchronization Service daemon (CSSD) clssnmSendingThread not scheduled for 3090 msecs. 2018-05-02 21:01:37.840 [OCSSD(2707)]CRS-1719: Cluster Synchronization Service daemon (CSSD) clssnmPollingThread not scheduled for 3100 msecs.
Für weitere Details siehe My Oracle Support Note Oracle DB 12.2.0.1 Alert Log Date/time Format Changes (Doc ID 2270543.1) [4].
Die hier gezeigten Verhaltensänderungen sind nur ein Ausschnitt. Es wird aber ersichtlich, dass Oracle jederzeit das bekannte Verhalten ändern kann – sei es nun durch ein Major-Update oder durch das Einspielen eines viertel-jährlichen Patches. Das Hauptproblem ist hier aber die stellenweise fehlende Dokumentation.
Wenn Automatisierungswerkzeuge zum Einsatz kommen, sollten diese Prozesse ebenfalls nach Anhebung des Patchlevels der Oracle-Software auf Fehler, die sich aus Verhaltensänderungen ergeben, hin überprüft werden.
Ich wünsche Ihnen viel Erfolg!
- My Oracle Support Note: Applying 12.2.0.1.171017 RU (patch 26737266) To 12.2 Cluster Removes Oratab Entries (Doc ID 2329359.1)
- My Oracle Support Note: From 12.2 , orapwd enforces password complexity rules (Doc ID 2294754.1)
- My Oracle Support Note: 12.2:[INS-35178] The Automatic Memory Management Option Is Not Allowed During RunInstaller or Using DBCA If Physical Memory Is Greater Than 4G. (Doc ID 2244817.1)
- My Oracle Support Note: Oracle DB 12.2.0.1 Alert Log Date/time Format Changes (Doc ID 2270543.1)
Weitere Informationen:
- Behavior Changes, Deprecated and Desupported Features for Oracle Database 12c Release 2 (12.2)
- Behavior Changes, Deprecated and Desupported Features for Oracle Database 18c
