Ausgangslage
- Eine neue 12c Installation auf einer AIX 6.1 LPAR
- Auftrag Upgrade einer bestehenden 11.2.0.4 Datenbank mit der “Out-of-Place” Variante auf 12.1.0.2
- Die Installation der 12.1.0.2 RDBMS-Software lief sauber durch
SQL*Plus bleibt hängen
Nach der Installation der 12c Software habe ich auf dem Server versuchsweise die Variable ORACLE_HOME auf das neu erstellte Verzeichnis gesetzt, um rudimentär SQL*Plus zu testen. ORACLE_SID wurde auf einen Dummy-Wert gesetzt damit die Meldung “Connected to an idle instance” angezeigt werden sollte. Doch wie heisst es immer so schön: Erstens kommt es anders, zweitens als man denkt!
oracle@solothurn:~/ [rdbms12102] sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Tue Jul 14 12:45:57 2015 Copyright (c) 1982, 2014, Oracle. All rights reserved.
Nach ungefähr 2 Minuten kam dann endlich der gewünschte SQL> Prompt
Connected to an idle instance. SQL>
Auf einem anderen Server konnte das Verhalten mit einer Dummy-SID nicht reproduziert werden, da funktionierte der lokale Verbindungsaufbau verzögerungsfrei.
Interessant war auch, dass es keine Wartezeit gab wenn man mit dem 12c SQL*Plus auf eine laufende Datenbank zugreifen wollte. Nur wenn die Datenbank nicht verfügbar war oder eine Dummy-SID verwendet wurde, gab es mit dem 12c SQL*Plus die Verzögerung.
Mit SQL*Plus der alten 11.2.0.4 Installation gab es überhaupt keine Probleme. Weder mit einer Dummy-SID noch mit einer gestoppten Instanz.
Analyse 1 – truss -d
Als erstes habe ich es mit einem truss -d versucht um das Verhalten von sqlplus genauer zu analysieren. Und hier an dieser Stelle war die Wartezeit. Wir sehen dass ziemlich genau 120 Sekunden verstrichen sind bis es weitergeht.
0.8704: accessx("/etc/security/passwd", 04, 0) Err#13 EACCES
0.8709: close(9) = 0
0.8715: kwrite(10, "\0\002 z06\0\0\0\0\003 s".., 634) = 634
2.8724: kread(11, "\0\001 f06\0\0\0\0\004\0".., 8208) (sleeping...)
2.8724: kread(11, "\0\0\09D06\0\0\0\0\0\b\0".., 8208) = 157
121.9378: kopen("/rgsr055/appl/ora/product/12.1.0.2/rdbms/mesg/oraus.msb", O_RDONLY) = 9
121.9382: kfcntl(9, F_SETFD, 0x0000000000000001) = 0
121.9384: lseek(9, 0, 0) = 0
121.9387: kread(9, "1513 "011303\t\t\0\0\0\0".., 256) = 256
121.9391: lseek(9, 512, 0) = 512
Ein Trivadis-Kollege hat mich darauf aufmerksam gemacht, dass es für Linux einen 12c Bug gibt, wo SQL*Plus ebenfalls an der Stelle bevor das File oraus.msb gelesen wird hängen bleibt. Da hier aber AIX im Einsatz ist habe ich bei Oracle einen Service Request eröffnet.
Analyse 2 – Umgebungsvariablen
Parallel zum eröffneten Service Request habe ich nach weiteren Hinweisen gesucht. Dabei habe ich alle Umgebungsvariablen für den User oracle analysiert, deaktiviert und in einem neuen Terminalfenster Variable für Variable schrittweise neu gesetzt.
Nach einem Login auf den Server als user oracle mit nur wenigen gesetzten OS-Variablen funktionierte SQL*Plus problemlos (“Connected to an idle instance”). Es musste also an einer der Variablen liegen.
Nachdem ich bereits 50 Umgebungsvariablen durch hatte, blieb ich bei der Variable TNS_ADMIN hängen. Das hängende Verhalten trat ein, sobald diese gesetzt war.
TNS_ADMIN
Das TNS_ADMIN Verzeichnis beinhaltete vier Files:
oracle@solothurn:/ [rdbms12102] ll total 104 drwxr-x--- 2 oracle dba 4096 Jul 15 13:59 . drwxr-x--- 6 oracle dba 256 Jul 15 14:05 .. -rw-rw---- 1 oracle dba 585 Jul 05 2011 ldap.ora -rw-rw---- 1 oracle dba 1696 Jul 14 12:43 listener.ora -rw-rw---- 1 oracle dba 333 Jul 14 13:09 sqlnet.ora -rw-rw---- 1 oracle dba 651 Jul 14 12:48 tnsnames.ora
Mein Blick fiel auf das vierte File, das ldap.ora. Denn das wurde hier in diesem Umfeld eigentlich gar nicht benötigt, LDAP war in diesem Oracle-Umfeld nicht im Einsatz. Das File beinhaltete die LDAP-Verbindungsdaten wie DIRECTORY_SERVERS, DEFAULT_ADMIN_CONTEXT und DIRECTORY_SERVER_TYPE.
Test ohne ldap.ora
Ein erster Test ohne das ldap.ora File führte bereits zum gewünschten Erfolg. Sowohl die Verbindung zu einer Dummy-SID als auch zu einer Instanz welche runtergefahren war passierte verzögerungsfrei.
oracle@solothurn:~/ [ELEVEN] sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Tue Jul 14 12:45:57 2015 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to an idle instance. SQL>
Diese Info habe ich auch My Oracle Support mitgeteilt.
My Oracle Support
Mit meiner Information konnte der Herr von My Oracle Support innert Kürze was anfangen.
I found that actually there is a bug opened for this kind of issue as : Bug 20562898 – CONN / AS SYSDBA TAKES MORE THAN A MINUTE ON A NOT STARTED INSTANCE
Reason:
LDAP port is blocked by firewallSolution:
As a solution you may either apply patch or remove $ORACLE_HOME/network/admin/ldap.ora and $ORACLE_HOME/ldap/admin/ldap.ora if exists.
Fazit
Mit den angegeben Vorschlägen von My Oracle Support kann ich arbeiten. Das Entfernen vom nicht mehr benötigten ldap.ora File hat den gewünschten Effekt gebracht. Den Patch habe ich testweise einfach mal angefordert.
Noch offen ist meine Anfrage wieso
- a) das bei 11g problemlos geht
- b) wieso Oracle das File ldap.ora verwendet, selbst wenn im sqlnet.ora nur NAMES.DIRECTORY_PATH = (TNSNAMES) drin steht