Latest Posts

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:

Nur mal kurz die log_archive_dest_1 geändert: ORA-16714

Ausgangslage

Bei einer bestehenden 11.2.0.4 Oracle Umgebung auf AIX wurde auf der Primary und Standby das Verzeichnis für die archivierten Redo Log Files von der Fast Recovery Area auf ein konventionelles Verzeichnis geändert:

DGMGRL Status WARNING

Die Datenbank lief problemlos weiter, das Log-Apply funktionierte weiterhin. Aber im DGMGRL war nach kurzer Zeit der Status auf WARNING:

Analyse

Die Prüfung der einzelnen Sites (show database … verbose) hat ergeben, dass der Parameter StandbyArchiveLocation nicht korrekt gesetzt war. Der Data Guard Broker hat die Änderung nicht nachgezogen, der Data Guard Parameter verwies weiterhin auf die alte Fast Recovery Area:

Lösung

Anpassen vom Parameter StandbyArchiveLocation mit den aktuellen Verzeichnissen:

Unmittelbar danach war die Statusanzeige SUCCESS:

Fazit

Der Data Guard Status ist nach Anpassungen in der Datenbankkonfiguration unbedingt zu prüfen.

Red Hat Enterprise Linux 7 – ISO als Repository einbinden

Es gibt verschiedene Möglichkeiten ein ISO einer RHEL Installation in das YUM-Repository einzubinden um die Nachinstallation von Packages zu vereinfachen

  • ISO als CDROM mounten und einbinden
  • ISO lokal kopieren und einbinden
Link – benötigt RHEL Subscription

https://access.redhat.com/solutions/9892

ISO als CDROM mounten und einbinden

Verzeichnis erstellen und mounten

Repository File rhel7.local.repo im Verzeichnis  /etc/yum.repos.d erstellen

Repository aufräumen

 Test vom Repository

ISO lokal kopieren und einbinden

Verzeichnis anlegen und mounten

ISO Inhalt kopieren

Repository aufräumen

Repository File rhel7.local.repo im Verzeichnis  /etc/yum.repos.d erstellen

Repository bauen

Hinweis: Wurde RHEL7 mit der Basic Option installiert, so ist das Binary für createrepo nicht installiert. Dies kann aber nach dem Erstellen vom repo-File mit yum nachgeholt werden:

Test vom Repository

Oracle Multitenant Self-Service Provisioning – Neue Version

Mit der Oracle Multitenant Self-Service Provisioning Applikation PDBSS hat ein DBA / Entwickler die Möglichkeit, sich mit dem mit 12c neu eingeführten Konzept von Multitenant und den Pluggable Databases (PDB) vertraut zu machen. Die auf Oracle Application Express basierende Webapplikation ist eine prima Möglichkeit, Aktionen wie Bereitstellung, cloning, plug unplug durchzuführen.

Bereits 2013 habe ich im Trivadis O-AI Blog darüber berichtet, damals war die Software noch im Beta-Status. Seit dem 20. Mai 2015 ist die finale Version als Download verfügbar. Als Neuerung wird bspw. die Apex-Applikation in CDB$ROOT installiert und der Oracle REST Data Service verwendet (vorher APEX-Listener).

Die Applikation ist nicht für den produktiven Einsatz gedacht.

Aus dem Readme:

PDBSS provides an interface to an Oracle Database 12c multitenant environment and allows for the self-service provisioning of pluggable databases (PDBs) in a multitenant container database  (CDB). Its primary goal is to encourage learning about PDBs in development and test environments. It is an easy and productive way to allow database administrators (DBAs) and application developers the opportunity to gain hands-on experience with powerful PDB features, including creating PDBs, cloning PDBs, plugging in PDBs, and unplugging PDBs.

Voraussetzungen – Software

Oracle 12.1.0.2 oder höher
Oracle Application Express 4.2.5 oder höher (4.2.5 wird mit 12.1.0.2 mitgeliefert)
Oracle REST Data Services 2.0.6 oder höher (2.0.7 wird mit 12.1.0.2 mitgeliefert)
Oracle Pluggable Database Self-Service Provisioning Application

Im ZIP-Paket der Oracle Pluggable Database Self-Service Provisioning Application ist ein README.pdf mit der detaillierten Installationsanleitung verfügbar. Dabei wird auch empfohlen die neueste Version der Oracle REST Data Services herunterzuladen.

Voraussetzungen – Datenbank

Es wird eine leere Datenbank mit dem Zeichensatz AL32UTF8, sollte der lokale Listener nicht auf Port 1521 laufen, so muss in der Container-Datenbank CDB$ROOT der Parameter LOCAL_LISTENER gesetzt werden:

RESTful Web Services in der Datenbank konfigurieren

Es muss für die Datenbankbenutzer APEX_LISTENER und APEX_REST_PUBLIC_USER ein Passwort gesetzt werden. Hinweis: Die Passwörter werden später für die Konfiguration der Oracle REST Data Services benötigt.

Unlock APEX_PUBLIC_USER und Passwort ändern

Hinweis: Das Passwort werden später für die Konfiguration der Oracle REST Data Services benötigt.

Oracle REST Data Services ORDS konfigurieren

Auf Grund von Konfigurationsproblemen habe ich auf eine aktuelle 3-er Version verzichtet und mir stattdessen die Version 2.0.10 runtergeladen und entpackt:

http://www.oracle.com/technetwork/developer-tools/rest-data-services/downloads/ords-downloads-2010-2528184.html

Erster Start vom ORDS

Beim ersten Start vom APEX Listener werden folgende Abfragen gemacht – diese werden dann in der Konfigurationsdatei gespeichert:

  • Pfad für die Konfiguationsdatei – bspw.  /u00/app/oracle/product/ords/config
  • Hostname
  • Port
  • Datenbank-Servicename
  • Passwort APEX_PUBLIC_USER
  • Passwörter APEX_REST_PUBLIC_USER / APEX_LISTENER

Hinweis: Die Konfiguration vom ORDS-Benutzer muss übersprungen werden (Known Issues) – der Listener wird beim ersten Mal nicht gestartet: exit [2] am Schluss.

Konfiguration vom DB-Suffix für ORDS

Die DB-Domain in die ORDS-Konfiguration eingetragen – Beispiel: trivadis.com. Ermitteln der DB-Domain als SYSDBA:

Danach wird die Domain in ein Konfigurationsfile eingtragen welches anschliessend verwendet wird.

 ORDS Konfiguration aktualisieren

Starten vom ORDS

Beim ersten Start wird nach dem /images Pfad gefragt – hier muss der Pfad vom $ORACLE_HOME/apex/images angegeben werden.Sollte Oracle Application Express in einem anderen Pfad installiert worden sein, so muss das entsprechende Verzeichnis angegeben werden.

Mit der URL http://localhost:8080/multitenant/ erreicht man die Oracle Application Express Startseite:

apex_einstiegsseite

Installation der PDBSS-Applikation

Die Applikation habe ich auf dem Server  in ein temporäres Verzeichnis entpackt, welches später dann gelöscht werden kann. Die Installation erfolgt mit einem SQL-Script aus dem entpackten Unterverzeichnis pdbss, welches als SYSDBA in der Container-Datenbank CDB$ROOT ausgeführt wird:

Das Script pdbss_ins.sql wird als SYSDBA gestartet. Die Frage nach dem Demonstration Mode, Datafiles und Port kann mit Enter beantwortet werden. Der neu angelegte ADMIN User ist dann der Verwalter der PDBSS-Applikation. Die Installation ist in kurzer Zeit durch.

Login in die Oracle Multitenant Self-Service Provisioning Applikation

Die URL muss mit dem Suffix f?p=pdbss ergänz werden:http://localhost:8080/multitenant/f?p=pdbss – danach erscheint die Startseite und es kann sich eingeloggt werden. Der Benutzer heisst ADMIN, das Passwort wurde bei der Installation mit dem pdbss_ins.sql gesetzt.

pdbss_login

pdbss_startseite

ORDS Service separat starten

Der Service läuft aktuell als Terminal-Job. Das heisst sobald das Terminalfenster zu ist, ist kein Zugriff mehr auf die Applikation möglich. Verschiedene Lösungen sind möglich:

Fazit

Die Oracle Multitenant Self-Service Provisioning Applikation hat den Beta-Status überwunden und ist nun offiziell verfügbar. Gerade für DBAs und Entwickler bietet die Apex-Applikation eine tolle Gelegenheit, sich mit Multitenant auseinanderzusetzen. Das Verständnis für die neue Architektur ist wichtig und gehört zu den technischen Grundlagen beim zukünftigen Einsatz von Oracle 12c.