Monthly Archive: July 2015

Oracle 12c – Zwei Minuten bis “Connected to an idle instance.”

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!

Nach ungefähr 2 Minuten kam dann endlich der gewünschte SQL> Prompt

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.

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:

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.

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 firewall

Solution:
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

TVD-HA – Data Guard im Schnelldurchgang

Trivadis Toolbox

Die Trivadis Toolbox – http://www.trivadis.com/de/infrastructure-toolbox – beinhaltet verschiedene Werkzeuge und Komponenten, um den täglichen Datenbankbetrieb zu vereinfachen und zu standartisieren. Jede der Toolbox-Komponenten ist eine Sammlung von Scripts, Tips und Tricks für den Betrieb, Unterhalt, Automatisierung und Monitoring von Oracle Datenbanken und Middleware.

TVD-HA und Aufbau von Oracle Data Guard

Meine Lieblingskomponente aus der Trivadis-Toolbox ist TVD-HA – http://www.trivadis.com/de/tvd-hatm – ein Paket für Setup und Monitoring von Oracle Data Guard und RAC Cluster. Ich verwende TVD-HA, um schnell und einfach Data Guard Umgebungen aufzubauen.

Um eine Data Guard Umgebung aufzubauen sind manuell viele einzelne Schritte notwendig:

  • Anpassung vom Listener
  • Erstellen der Verzeichnisstrukur für die Standby-Umgebung
  • Kopieren und Anpassen von Parameter- und Passwortfile
  • Standby Datenbank aktiv oder aus der Sicherung erstellen
  • Standby Redo Logfiles erstellen
  • Erstellen eines Read-Write Triggers für den Service
  • etc.

Mit TVD-HA reduziert sich der Aufwand auf ein Minimum und es wird sichergestellt, dass die Standby-Datenbank analog der Primary-Datenbank aufgebaut ist. Dabei wird die Standby je nach Wunsch aus dem Backup oder via Active Duplicate erstellt und Data Guard fixfertig konfiguriert.

dgadd.ksh – Erstellen einer Standby-Datenbank

Das Script dgadd.ksh – Bestandteil von TVD-HA – erstellt die Standby-Datenbank interaktiv oder mit einem Konfigurationsfile im Hintergrund. Umfangreiche Pre-Checks stellen sicher, dass keine Konfigurationsfehler übernommen werden und alle Parameter richtig gesetzt sind, bevor die Standby erstellt wird.

Ein Beispiel für den Aufbau:

  • Primary: TVD12CDA_SITE1 – solothurn.trivadistraining.com
  • Standby: TVD12CDA_SITE2 – olten.trivadistraining.com

Da hier kein Konfigurationsfile mitgegeben wurde, wird die Erstellung interaktiv durchgeführt. Ein paar Auszüge:

Das Ergebnis ist eine voll funktionsfähige Data Guard Umgebung:

Monitoring mit TVD-HA

Wer eine Enterprise Monitoring Lösung sein eigen nennt wie Oracle Enterprise Manager Cloud Control 12c, hat ein komplettes Data Guard Monitoring zur Überwachung von Log-Transport Gaps, Apply-Problemen bereits inbegriffen. Da sich EM12c Cloud Control aber nur für grössere Umgebungen lohnt, kann man seine Oracle Data Guard Umgebung mit TVD-HA überwachen. Das Script heisst dgmon.ksh, erkennt Switchover-Aktionen, Konfigurationsänderungen und Gaps aller Art. Wird ein Problem erkannt, so wird unmittelbar ein Email verschickt. Hier wurde beim Check der Switchover erkannt:

TVD-HA bietet noch mehr

Das Erstellen einer standartisierten Standby-Umgebung mit der Toolbox-Komponente TVD-HA war noch nie einfacher. Das Erstellen einer Standby-Datenbank mit dgadd.ksh und das Monitoring mit dgmon.ksh sind nur zwei der zahlreichen Möglichkeiten welche die Komponente bietet. Weitere Funktionen zur Logfile-Analyse oder Scripts zum Erstellen von RAC-Services, VIP-Adressen etc. gehören auch dazu.

Für weitere Informationen wie Preise, Verfügbarkeit etc. einfach hier klicken: