Startseite > APEX 5, Oracle 12c, Oracle REST Data Services > APEX 5 auf Oracle 12c installieren

APEX 5 auf Oracle 12c installieren

Betreff:

  • APEX 5.0
  • Oracle 12c R1
  • ORDS 3.0.1

Seit einiger Zeit ist die Oracle 12c Datenbank und mittlerweile auch das lang ersehnte APEX 5 verfügbar, was uns natürlich wieder vor neue Herausforderungen stellt. Die Installation einer Oracle 12c war noch recht einfach. Also sollte APEX 5 auch keine großen Probleme verursachen – dachte ich, weil in der Vergangenheit eine APEX Installation, egal ob Neuinstallation oder Upgrade, immer total easy und klappte ohne große Probleme. So ging ich sehr optimistisch und naiv an die APEX 5 Installation – APEX 4.2 war ja bereits per Default in der 12c enthalten – sollte also kein Problem darstellen.

F A L S C H !!!

Leider musste ich feststellen, dass APEX 5 und alles, was damit zu tun hat, nicht gut funktioniert. Es hat mich mehrere Tage gekostet herauszufinden, wo die einzelnen Probleme liegen und wie ich sie umgehen kann.

An dieser Stelle ein fettes Sorry für diese pauschale Aussage, aber es gibt einfach zu viele Dinge, die derzeit nicht funktionieren. Angefangen

  • mit den neuen Perl Wrapper-Skripten, die bei mir unter Windows 7 leider ständig abgebrochen sind,
  • über einen APEX 5-Bug der das Upgrade auf die 4.2 verhindert (20381781 – Error occurs when upgrading apex 4.2.5.00.08 in 12.1.0.2 DB to APEX 5.0),
  • und die APEX 4.2 Deinstallation, die leider auch nicht reibungslos funktionierte
  • bis hin zu diversen Problemen mit dem neuen APEX Listener, genannt ORDS (Oracle REST Data Services)

Aus all diesen Gründen habe ich mich entschlossen, hier eine Anleitung zu geben, wie man die bekannten Probleme umgeht und möglichst schnell zum Ziel kommt und eine lauffähige APEX 5 Umgebung auf einer 12c aufbauen kann.

Anmerkung: Mir ist sehr wohl bewusst, dass es sicherlich noch andere Wege gibt, die evtl. vielleicht sogar deutlich besser sind. Aber wenn man Tage hinter sich gebracht hat, in denen man unsinnige Fehleranalysen durchführen musste, hat man keine Lust mehr alles wieder rückgängig zu machen und nach „dem richtigen Weg“ zu suchen.

Zudem werden wohl (hoffentlich) in neueren Versionen von APEX 5 und ORDS diese Fehler beseitigt sein und somit meine Beschreibung hier überflüssig werden.

Konzept

Da wir hier über Oracle 12c, also die neue „multitenant Database“ sprechen, und es hier mehrere Möglichkeiten gibt, APEX zu installieren, möchte ich vorher kurz das Konzept erläutern, was der folgenden Installtionsanleitung zugrunde liegt.

Ich habe versucht, den „recommended way“ umzusetzen. Das beudetet, dass APEX 5 im Root Container (CDB) installiert und darüber auf alle PDBs verteilt wird.

Darüber hinaus möchte ich einen APEX Listener verwenden und diesen in einer Tomcat-Instanz bereitstellen.

 

Deinstallation APEX 4.2

Wegen des Bugs 20381781 – Error occurs when upgrading apex 4.2.5.00.08 in 12.1.0.2 DB to APEX 5.0, über den ich natürlich auch gestolpert bin, muss derzeit die per Default in Oracle 12c vorhandene APEX 4.2 deinstalliert werden. Sollte bei Ihnen kein APEX installiert sein, können Sie diesen Punkt natürlich überspringen. Prüfen können Sie das, indem die DB-User abgefragt werden.

SELECT username FROM dba_users WHERE username LIKE ‚APEX%‘ OR username LIKE ‚FLOWS%‘;

Zur Deinstallation wechseln Sie in das Verzeichnis %ORACLE_HOME%\apex, rufen SQLPLUS als SYSDBA auf und starten das Skript „apxremov.sql“, wobei wir hier unbedingt noch einen DB-Parameter umsetzen müssen, damit alles sauber funktioniert (siehe dazu auch ORA-28014: Cannot drop administrative users)

sqlplus / as sysdba

ALTER SESSION SET “_oracle_script” = TRUE;

@apxremov

Anmerkung:

Eigentlich sollte das so funktionieren. Wenn nicht, kann man APEX 4.2 auch manuell deinstallieren (siehe APEX 4.2 auf Oracle 12c manuell deinstallieren).

Neuinstallation APEX 5

Nun installieren wir APEX 5 in einer APEX-freien Oracle 12c Datenbank.

sqlplus / as sysdba (in CDB)
@apexins.sql SYSAUX SYSAUX TEMP /i/
— ACHTUNG Fehler:
—    catcon: See apexins_cdb_*.lst files for spool files, if any
—    next_proc: total processes (8) != number of live processes (7); giving up
—    Use of uninitialized value $ProcId in concatenation (.) or string at D:\Installationen\Oracle\product\12.1.0\dbhome_1/rdbms/admin/catcon.pm line 1779.
—    Use of uninitialized value $ProcId in concatenation (.) or string at D:\Installationen\Oracle\product\12.1.0\dbhome_1/rdbms/admin/catcon.pm line 1779.
—    A process terminated prior to completion.
—    Review the apexins_cdb*.log files to identify the failure
—        => Died at D:\Installationen\Oracle\product\12.1.0\dbhome_1/rdbms/admin/catcon.pm line 6149.

—    Internetsuchen deuten darauf hin, dass hier evtl. ein problem mit Perl vorhanden ist.
—    https://rt.cpan.org/Public/Bug/Display.html?id=17773

 

— Prüfen APEX-User in CDB
SELECT username
FROM dba_users
WHERE username like ‚APEX%‘ or username like ‚ORDS%‘ or username like ‚FLOWS%‘
ORDER BY username;

— Prüfen APEX-User in PDB
ALTER SESSION SET CONTAINER = pdbora12c;

SELECT username
FROM dba_users
WHERE username LIKE ‚APEX%‘ OR username like ‚ORDS%‘ OR username like ‚FLOWS%‘
ORDER BY username;

 

— Change Admin-Password (über CDB)
ALTER SESSION SET CONTAINER = cdb$root;
@apxchpwd.sql

— !!!!!!!!!!!!!!!!!!!!!!!

— !!! ACHTUNG !!!

— Das muss in PDB explizit gestartet werden.

— !!!!!!!!!!!!!!!!!!!!!!!

ALTER SESSION SET CONTAINER = pdbora12c;
@apxchpwd.sql

 

— APEX_PUPBLIC_USER vorbereiten (in CDB)
ALTER SESSION SET CONTAINER = cdb$root;
ALTER USER APEX_PUBLIC_USER ACCOUNT UNLOCK;
ALTER USER APEX_PUBLIC_USER IDENTIFIED BY oracle;

 

— Prüfen, ob Rest-User existieren
SELECT username
FROM dba_users
WHERE username in (‚APEX_LISTENER‘, ‚APEX_REST_PUBLIC_USER‘)
ORDER BY username;

Sollten die Listener-User nicht existieren, dann müssen diese installiert werden, bevor ORDS installiert wird.

 

— SQLPLUS als SYSDBA aufrufen (CDB)

sqlplus / as sysdba (in CDB)

Da auch dieses Skript: „@apex_rest_config.sql“ mit folgendem Fehler abgebrochen ist:

— ‚Enter: GetConsoleMode failed, LastError=|6| at D:/Installationen/Oracle/product/12.1.0/dbhome_1/perl/site/lib/Term/ReadKey.pm line 277.

habe ich auch das von Hand ausgeführt (naja, zumindest halb-manuell):

— SQLPLUS als SYSDBA (CDB)

sqlplus / as sysdba

— Um wieder die Fehlermeldung „ORA-65096: invalid common user or role name “ zu unterbinden, folgendes Statement absetzen:

ALTER SESSION SET „_ORACLE_SCRIPT“ = TRUE;

— nun das innerste Skript verwenden:

@apex_rest_config_core.sql

 

— und nun das Gleiche noch in der PDB machen

ALTER SESSION SET CONTAINER = pdbora12c;

@apex_rest_config_core

— Den Parameter _ORACLE_SCRIPT brauchen wir hier nicht zu setzen. Offensichtlich dürfen wir in den PDB machen, was wir wollen.

 

Installation und Konfiguration Oracle REST Data Services (ORDS 3.0.1)

Nachdem wir nun APEX 5 erfolgreich installiert haben, installieren und konfigurieren wir noch die ORDS.

Anmerkung!

Wenn wir das PLSQL Gateway verwenden möchten, brauchen wir ORDS natürlich nicht zu installieren. In diesem Fall einfach das PLSQL Gateway konfigurieren (mit @apex_epg_config.sql gegen die PDB) und dann sollte es auch schon funktionieren.

Zuerst entpacken wir das ZIP-File mit ORDS 3.0.1 und verschieben es an einen Ort, wo es dauerhaft liegen bleiben kann. Ich persönlich finde, dass das ORACLE_HOME ein guter Ort ist. Aber das ist Geschmacksache.

Nun wechseln wir in diesen ORDS-Ordner. Eigentlich reicht es aus, wenn wir einen simplen Java-Aufruf machen, den wir auch später benutzen können, um ORDS im Standalone-Modus zu starten. Aber um bewusst zu machen, dass wir explizit installieren und konfigurieren möchten, hier der vollständige Aufruf:

java -jar ords.war install advanced

Durch diesen Aufruf werden nun z.B. ein Konfig-Verzeichnis, in dem die Konfigs abgelegt werden, abgefragt und natürlich auch alle DB-Connect Infos und einiges mehr. Bitte hier sorgfältig vorgehen, da sonst eine wahrscheinlich ziemlich umfangreiche Fehlersuche ansteht. Dazu aber später noch einiges mehr.

Hinweis: Wenn man die Konfiguration einmal durchgeführt hat, aber noch mal durchführen will (weil man z.B. einen Fehler gemacht hat oder etwas ändern möchte), funktioniert es mit diesem Aufruf leider nicht mehr (liebe Oracle-Developer, was habt ihr euch dabei gedacht?). Anstatt im Konfig-Modus zu starten wird direkt der Standalone-Modus ausgeführt und eine Konfiguration ist nicht mehr möglich (hierzu bitte weiter unten unter „Weitere Tipps und Tricks zu ORDS“ nachlesen, wie man wieder in den Konfig-Modus kommt).

Hinweis: Bei mir hat die DB-seitige Installation der ORDS-Komponenten aus dem normalen Installationsprozess nicht funktioniert, da der Connect als SYSDBA schief gegangen ist. In diesem Fall können die Komponenten manuell installiert werden. Siehe dazu weiter unten „Weitere Tipps und Tricks zu ORDS“.

WICHTIG!

Bitte prüfen Sie nun unbedingt, ob im ORDS Konfig-Ordner unter „.\ords\conf“ eine Datei mit dem Namen „apex.xml“ existiert. Wenn nicht kopieren Sie bitte direkt die Datei „apex_pu.xml“ nach „apex.xml“ (ohne diese Datei läuft nichts!) (siehe auch ORDS 3 404 Error – unbedingt auch Kommentar von „krissco“, vom 14.05.2015, 10:41 beachten).

 

Jetzt müssen wir noch die APEX-Images als WAR-File bereitstellen, damit wir diese im Tomcat deployen können. Dazu:

— hier wird nun das War-file benutzt, um ein neues WAR-File für den Java-Container zu erzeugen.

— Aufruf: java -jar ords.war static <Image Context-Path> <Pfad zu dem Ort, an dem meine APEX-Images liegen.

java -jar ords.war static /i /ora01/product/db12c/apex/images

Hieraus entsteht eine Datei mit dem Namen „i.war“. Diese Datei deployen wir nun im Tomcat. Da es hierzu eine Benutzeroberfläche gibt, spare ich mir die genauen Anweisungen.

Wichtiger Hinweis:

Hier sollte nun im CATALINA_HOME des Tomcats unter „.\webapps\i“ alle APEX-Images auftauchen. Leider hat das bei mir unter Windows nicht funktioniert. 

Für den Fall, dass es bei Ihnen ebenfalls schief gelaufen ist, hier ein Workaround:

Prüfen Sie, ob im CATALINA_HOME unter „.\webapps“ order „i“ existiert. Wenn ja, kopieren Sie die APEX_Images mit allen Unterordnern einfach in diesen i-Ordner.

 

So, nun sollte alles funktionieren. Also Browser öffnen, URL eingeben (ACHTUNG, der virtuelle Pfad heißt nun „ords“, nicht mehr „apex“) und testen. Wenn man „locahost“ als Servernamen eingibt und es klappt nicht, unbedingt auch mal mit dem Rechnernamen versuchen. Mit Localhost hatte ich auch meine Probleme!!!

Wenn es trotzdem nicht funktionieren sollte, hier noch einige Tipps und (hoffentlich) nützliche Anmerkungen.

Weitere Tipps und Tricks zu ORDS

 

Hilfe bzw. Parameterliste aufrufen

Um eine Liste aller möglichen Aufrufparameter zu bekommen, einfach folgenden Befehl in Kommandozeile absetzen:

java -jar ords.war help

und benötigt man weitere Informationen zu den Aufrufparametern kann man den Hilfebefehl erweitern. Z.B.:

java -jar ords.war help standalone

java -jar ords.war help setup

 

ORDS-Skripte fehlen bzw. wo finde ich die ORDS-Skripte

Die ORDS-Skripte können ganz einfach aus dem mitgelieferten WAR-File extrahiert werden.

java -jar ords.war ords-scripts

Durch diesen Befehl werden alle notwendigen DB-Skripte des ORDS extrahiert und in einem Unterordner „ords_scripts“ abgelegt.

Debugging

Im ORDS kann das Debugging aktiviert werden, wodurch zusätzliche Meldungen im Startfenster des Tomcat bzw. des Standalone-Listeners ausgegeben werden. Dazu:

In den ords-3.0.1 Konfig-Ordner wechseln und und die Datei .\ords\defaults.xml öffnen.

Nach folgenden Einträgen suchen und die Werte auf „true“ setzen:

<entry key=“debug.debugger“>false</entry>
<entry key=“debug.printDebugToScreen“>false</entry>

Anmerkung: In den Produktions-Instanzen das Debugging unbedingt wieder ausschalten, da die Performance dadurch deutlich verschlechtert wird.

 

Manuelle Installation der ORDS DB-Komponenten

Wenn die Installation der DB-seitigen ORDS-Komponenten schief geht, gibt es die Möglichkeit, diese manuell zu installieren. Aber Vorsicht! Diese Komponenten müssen nun in der/den PDB(s) installiert werden.

cd ords_scripts\scripts\install\core

sqlplus / as sysdba

ALTER SESSION SET CONTAINER = pdbora12c;

— Aufruf: ords_manual_install.sql <Inst-Tablespace> <Temp-Tablespace> <log-Verzeichnis>

@ords_manual_install.sql SYSAUX TEMP d:\…\ords-3.0.1\log

 

Erneute Konfiguration des ORDS durchführen

Wenn während der Installation oder Konfiguration des ORDS etwas schief gelaufen ist, kann es notwendig werden, die Aktion erneut auszuführen. Leider führt ein erneuter Aufruf von

java -jar ords.war install advanced

nicht zur Konfiguration, sondern startet den ORDS im Standalone-Modus mit der vorhandenen Konfiguration.

Sollte der Fehler an der DB-seitigen Installation liegen, bitte einfach die manuelle Installation der DB-Komponenten durchführen, wie oben beschrieben. Ist allerdings etwas bei der System-seitigen Installation schief gelaufen, haben wir 2 Möglichkeiten.

  1. Konfiguration vorher löschen
    • Tomcat oder Standalone Instanz stoppen
    • ORDS-Konfigurations-Verzeichnis löschen
    • Aufruf: java -jar ords.war install
  2. Konfiguration explizit aufrufen (empfohlen)
    • Tomcat oder Standalone Instanz stoppen
    • Aufruf: java -jar ords.war setup
    • => Durch diesen Aufruf wird eine erneute Konfiguration ohne Installation erzwungen.

 

Quellen

Danksagung

An dieser Stelle und nach diesen ganzen Problemen muss ich mich noch mal ganz herzlichen bei der APEX Community bedanken, ohne die es noch viel länger gedauert hätte.

Liebe APEX Gemeinde, danke, danke, danke!

  1. Es gibt noch keine Kommentare.
  1. No trackbacks yet.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: