Oracle Tools

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:

ORA-01996: GRANT failed: password file

Für den Neuaufbau der Umgebung für das Trivadis-Training Oracle Architektur und Interna wollte ich in einer 12.1.0.2 Multitenant-Datenbank unter Oracle Linux 6 mehrere Common User anlegen. Diese sollten die CONNECT und DBA Rolle sowie das SYSDBA-Privileg erhalten. Nach den ersten 8 Benutzern brach das Skript ab mit einer ORA-01996 Fehlermeldung. Die Multitenant-Datenbank wurde mit dem Database Creation Assistant DBCA erstellt.

PL/SQL Code

Verifizierung vom Passwort-File

Ein Blick in das Passwort-File zeigt dass bereits 12 Einträge mit Privilegien drin sind. Nebst den vier Default-Benutzer SYS,SYSDG, SYSBACKUP und SYSKM wurden nur acht meiner Benutzer mit dem Prefix C##DBA0x eingetragen.

ORA-01996

Der Fehlermeldung nach hat es zuwenig Platz für neue Einträge. Gibt man beim Erstellen eines Passwort-Files keinen ENTRIES Parameter an, so ist gemäss Oracle Dokumentation die Anzahl maximaler Einträge abhängig von der  OS-Blockgrösse: http://docs.oracle.com/database/121/ADMIN/dba.htm#ADMIN11059:

For example, if your operating system block size is 512 bytes, it holds four password entries. The number of password entries allocated is always a multiple of four.

Aber: Mein OS hat eine Blockgrösse von 4096 Bytes, das heisst es müssten also 32 Einträge drin Platz haben:

 My Oracle Support

Ich habe daraufhin am 24.04.2015 einen Service Request bei Oracle eröffnet – der Fall wurde geprüft und ein Bug eröffnet:

Hello Mr. Berger,

The issue you have pointed out is easily reproducible and I have created bug 20938256 to get this clarified. Most probably you know already that you can add as many passwords to that passwordfile as you wish, if you specify a large value for the passwordfile’s ENTRIES parameter. Bug’s purpose is to clarify what would be the default number of entries on an OS having a blocksize that is different to the 512 bytes ( that was used as an example in the documentation)

Thanks

MOS Note

OERR: ORA 1996 GRANT failed: password file <name> is full (Doc ID 19282.1):

Lösung

Momentan bleibt mir nur die Neuerstellung vom Passwort-File mit Angabe von ENTRIES und dann die Neuvergabe der administrativen Privilegien. Update folgt…

 

SQL Developer 4.1 EA angetestet

Seit dem 8. Dezember ist der Oracle SQL Developer 4.1 Early Adopter als Download verfügbar. Höchste Zeit also für einen ersten Test. Hier die wichtigsten Neuerungen:

  • Verbesserter Import Data Wizard
  • Instance Viewer
  • REST Enablement von Tabellen
  • NoSQL Support
  • Verbesserter Data Modeler
  • Generelle Verbesserung beim Speichern von Files, Login, SQL Aufzeichnung von Statements etc.
  • JDK 8 Support

Die Installation geht wie bei den vorherigen Version sehr einfach, runterladen, entpacken, JDK angeben und los geht’s. Vorherige Verbindungseinstellungen können übernommen werden.

Links

Die beiden für mich als DBA interessantesten Features sind sicher der Instance Viewer und der Data Import Wizard. In der SQL Developer Version 3 konnte man das Insider Plugin von fourthelephant.com installieren um den Datenbankzustand grafisch anzuzeigen, doch das Plugin war in der SQL Developer Version 4 nicht mehr lauffähig.

Instance Viewer

Den Instance Viewer findet man im DBA-Modul – Voraussetzung für die Benutzung ist die korrekte Lizenzierung vom Oracle Diagnostic Pack.

dba_module

pack_license

Die Übersichtsseite zeigt einen generellen Zustand der Instanz. Für eine grössere Ansicht auf die Bilder klicken.

uebersicht

Einzelne Panels sind anklickbar um Details anzuzeigen. Diese sind erkennbar an einem blauen Rahmen wenn man die Maus über die Oberfläche bewegt, beispielsweise das Session Panel:

sessions

session_details

Data Import Wizard

Den verbesserten Import Wizard findet man in der Datenbank-Verbindung mit einem Rechtsklick auf Tables – Import Data. Sollen die Daten nicht in das SYS Schema importiert werden, gibt es das Import Data Menu auch auf Stufe Other Users – <User> – Tables.

import

 Schritt 1 – File auswählen

wizard_step_1

 Schritt 2 – Daten in eine neue Tabelle importieren

wizard_step_2

Schritt 3 – Spalten auswählen

wizard_step_3

Schritt 4 – Datentypen auswählen und bei Bedarf ändern

wizard_step_4

Schritt 5 – Zusammenfassung

wizard_step_5

Bestätigung

wizard_confirmation

Verbindung mit 12c Rollen

Für die Verbindungen können neu die 12c Rollen SYSKM, SYSDG etc. verwendet werden:

rollen

Zusammenfassung

Der erste Eindruck vom SQL Developer 4.1 EA: I like :-). Die grafische Oberfläche für die Statusübersicht ist gelungen, da liegt sicher noch mehr drin, beispielsweise die Anzeige vom Shared Pool Inhalt, Anzeige der Sessions mit Top SQL, Redo Log Switches pro Stunde etc. wären auch noch toll. Oder die Möglichkeit die Panel selbst auszuwählen und zu Positionieren (eigenes Dashboard). Der Import Wizard ist verbessert worden, die zu importierenden Daten werden bereits zu Beginn der Import-Aktion angezeigt und verhindert unbeliebsame Überraschungen. Dazu kommen vielen kleine aber feine Anpassungen wie die Login-Rollen oder der Speichern-Dialog.