Sync PDB failed with ORA-40365 while performing 'alter user sys account lock password expire' in Multitenant Datenbank
Die Fehleranalyse - oder: Wenn support.oracle.com nicht weiter hilft
Nachdem ein Kunde eine neue Oracle 19c Datenbank in seiner Umgebung aufgesetzt hatte, fand er rein zufällig den Fehler "Sync PDB failed with ORA-40365 while performing 'alter user sys account lock password expire'" in der View PDB_PLUG_IN_VIOLATIONS und wollte wissen, wo der her kommen könnte und vor allem, wie man diesen wieder weg bekommt.
Beides berechtigte Fragen, die zu einer aufwändigeren Analyse führen sollten, als zum Anfragezeitpunkt gedacht...
Erster Einstiegspunkt bei einer neuen Problematik ist erst einmal https://support.oracle.com - schließlich ist die überwiegende Mehrheit aller Probleme bereits bekannt. Tatsächlich gibt es zu dem Fehler eine Note ("Sync PDB failed with ORA-40365 while performing 'alter user sys' (Doc ID 2777162.1)") in dem steht, dass dieser Fehler beim Upgrade einer Datenbank auf eine neuere Version auftreten kann.
Allerdings kein Wort zu einer Neuinstallation und ansonsten gab es keine weiteren hilfreichen Notizen.
Spätestens zu diesem Zeitpunkt war dann klar - die ganze Sache könnte etwas größer werden und mehr Zeit in Anspruch nehmen.
Der Kunde bekam den Fehler auf einer 19.8 Datenbank-Version, auf dem Laptop zum Testen war schon eine 19.13 Version installiert, also wurde hier mit dem DBCA (Database Configuration Assistant) eine neue Datenbank erstellt. Es war nicht wirklich überraschend, dass der Sync-Fehler auch hier auftrat.
Aber die Frage ist natürlich - wo kommt das her? In der Oracle Note wurde ein solches Verhalten (bei der DB Version 12.2) ja explizit ausgeschlossen.
Es muss also einen fundamentalen Unterschied zwischen der Oracle Note des Supportes bestehen und dem, was wirklich passiert.
Loggen, analysieren, Service Request (SR) eröffnen
Das Problem schien, zumindest laut der Oracle Note, mit der Version der Passwortdatei der Datenbank zu korrelieren. Die spannende Frage war - welche Version der Passwortdatei wird wirklich erstellt? Um das zu prüfen verwendet man das Tool "orapwd" mit dem Parameter "describe".
Ok - File Version ist 12, aber sollte die nach den Informationen der Oracle Note bei einer frisch erstellten Datenbank unter/ab Version 12.2 nicht im Format 12.2 erstellt werden? Man kann die Passwort-Datei auch manuell upgraden nach 12.2, aber warum stimmt die Version überhaupt nicht? Liegt das vielleicht an der Komplexität des Passwortes, das man im DBCA für den SYS vergibt? Das wäre zumindest eine logische Erklärung, da die 12.2 Passwort Version ein deutlich komplexeres Passwort voraussetzt.
Long story short:
Auch nach der erneuten Neuerstellung einer CDB mit komplexem Passwort war die Fehlermeldung wieder da - und die Version der Passwortdatei immer noch 12 und nicht 12.2!
Da die Oracle Datenbank und auch viele Tools sehr geschwätzig sind und viele Logs und Debug Informationen hinterlassen, konnte im DBCA Logfile auch zweifelsfrei nachgewiesen werden, dass die Datei im falschen Format angelegt wird.
Die Erklärung - oder: Wenn der Oracle Support doch weiterhilft
Hurra - ein Bug! Damit der verschwindet führt kein Weg an einem Service Request vorbei. Nach einigem Hin und Her mit dem Oracle Support dann die Feststellung - es ist kein Bug. Also kein Software Bug. "It's a documentation bug".
Es gibt nun im Oracle Support Portal eine, aufgrund des SRs, neu erstellte Note: Oracle Support Document 2663482.1 (19c DB Does Not Make Password File Default Format As 12.2 - https://support.oracle.com/epmos/faces/DocumentDisplay?id=2663482.1)
In dieser Note ist nun beschrieben, dass mit dem Parameter "-skipPasswordComplexityCheck false" der DBCA dazu "gezwungen" werden kann, eine Passwortdatei in Version 12.2 anzulegen - allerdings muss dabei sichergestellt werden, dass das Passwort wirklich der Komplexität genügt. Außerdem wurde ein "Enhancement Request" durch den Support erstellt, dass 12.2 für neue/zukünftige Versionen das neue Default sein sollte.
In der Original-Note (siehe erster Abschnitt) wurde ebenfalls eine Änderung durchgeführt: Das Problem kann auch bei neu erstellten Datenbanken auftreten UND es gibt eine Erklärung, warum das Verhalten so ist, wie es ist - mit Passwortdateiversion 12.2 ändern sich auch Dinge wie "Password Lifetime" für alle privilegierten Benutzer (also SYSDBA, SYSBACKUP, SYSDG,...) und diese Änderung sollte niemandem "aufgezwungen" werden.
"Ich will das weg haben!"
war die Meinung des Kunden - irgendwelche "Pending" Fehlermeldungen für PDBs, egal ob nachvollziehbar oder nicht, sind in den Produktionsumgebungen einfach nicht zulässig. Nun - es gibt ein paar Schritte, die man tun muss, damit der Fehler wirklich verschwindet. Zuerst muss die Passwortdatei neue erstellt werden - natürlich in Version 12.2. Auch dies geht mit dem Tool "orapwd", indem man die vorhandene Datei als Input-Parameter mitgibt.
Nun kann man die Originaldatei löschen und der neuen Datei den ursprünglichen Namen geben. Wichtig ist ab diesem Zeitpunkt, dass auch die anderen Dinge wie "Password Lifetime" nun aktiv sind.
Im Anschluß muss man nur noch die "Pending" Fehlermeldung aus der PDB_PLUG_IN_VIOLATIONS entfernen. Weder ein close/open der PDB noch ein "exec dbms_pdb.sync_pdb" sorgen allerdings dafür, dass diese Meldung einen anderen Status erhält. "exec dbms_pdb.clear_plugin_violations" nützt an dieser Stelle auch nichts, da diese Funktion nur Meldungen löscht, die "resolved" sind.
Es bleibt einem leider nichts anderes übrig, als etwas zu tun, was man als Datenbankadministrator unter nahezu jeden Umständen vermeiden sollte: Das Ändern des Data Dictionaries durch eigene Datenmanipulation.
Nur mit einem "delete from pdb_plug_in_violations where error_number=40365;" lässt sich die Meldung tatsächlich aus der View entfernen. Auch wenn das in diesem Fall ein "low risk" Befehl ist - manuelle Änderungen im Data Dictionary können immer zu später auftretenden Problemen führen und es empfiehlt sich, ein Backup vor dem delete anzufertigen (und sich ggfs. die SCN zu notieren). Sicher ist sicher.
Kommentare
Keine Kommentare