Archiv

Posts Tagged ‘Oracle 12c’

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!

APEX 4.2 auf Oracle 12c manuell deinstallieren

September 4, 2015 1 Kommentar

Bei meinen ersten „Gehversuchen“ mit Oracle 12c und einer APEX 5 Installation kam ich leider in den „Genuss“, die von 12c mitgebrachte APEX 4.2 Installation deinstallieren zu müssen. Dabei lief ich leider auf diverse Schwierigkeiten, die verhinderten, dass der Aufruf von „@apxremov.sql“ durchgelaufen ist. Nach diversen Versuchen habe ich den diesen Versuch aufgegeben und APEX 4.2 von komplett manuell deinstalliert.

Tipp: Das Skript „apxremov.sql“ ruft in der 4.2 2 weitere Skripte auf. Ich habe mir einfach diese Skript angeschaut und die wichtigen Anweisungen rauskopiert und manuell ausgeführt.

Um das Ganze aber zu vereinfachen, hier eine Anleitung der manuellen Schritte.

Deinstallation in CDB

— sqlplus.exe aufrufen als SYSDBA in CDB connecten

sqlplus / as sysdba

— CURRENT_SCHEMA setzen: das sollte APEX_040200 sein

ALTER SESSION SET CURRENT_SCHEMA = APEX_040200;

begin
wwv_flow_upgrade.drop_public_synonyms;
end;

/

— speziellen undokumentierten Parameter setzen, um den Fehler ORA-28014 zu umgehen

ALTER SESSION SET „_oracle_script“ = TRUE;

DROP USER apex_040200 CASCADE;

DROP USER flows_files CASCADE;

DROP USER apex_public_user CASCADE;

DROP ROLE apex_administrator_role;

 

— Cleanup XDB

declare
cfg XMLType;
l_dad_list dbms_epg.varchar2_table;
begin

if dbms_xdb.existsresource(‚/i/‘) then
dbms_xdb.deleteresource(‚/i/‘, dbms_xdb.delete_recursive_force);
end if;

if dbms_xdb.existsresource(‚/images/‘) then
dbms_xdb.deleteresource(‚/images/‘,dbms_xdb.delete_recursive_force);
end if;

dbms_epg.get_dad_list( l_dad_list );
for i in 1..l_dad_list.count loop
if upper(l_dad_list(i)) = ‚APEX‘ then
dbms_epg.drop_dad(‚APEX‘);
end if;
end loop;

cfg := dbms_xdb.cfg_get();

if cfg.existsNode(‚/xdbconfig/sysconfig/protocolconfig/httpconfig/webappconfig/servletconfig/servlet-mappings/servlet-mapping/servlet-name[text()=“PublishedContentServlet“]‘) = 1 then
cfg := cfg.deleteXML(‚/xdbconfig/sysconfig/protocolconfig/httpconfig/webappconfig/servletconfig/servlet-mappings/servlet-mapping/servlet-name[text()=“PublishedContentServlet“]/..‘);
end if;

if cfg.existsNode(‚/xdbconfig/sysconfig/protocolconfig/httpconfig/webappconfig/servletconfig/servlet-list/servlet/servlet-name[text()=“PublishedContentServlet“]‘) = 1 then
cfg := cfg.deleteXML(‚/xdbconfig/sysconfig/protocolconfig/httpconfig/webappconfig/servletconfig/servlet-list/servlet/servlet-name[text()=“PublishedContentServlet“]/..‘);
end if;

dbms_xdb.cfg_update(cfg);
commit;
dbms_xdb.cfg_refresh;

end;

/

— SYS owned Objects:

DROP PROCEDURE validate_apex;
DROP PACKAGE wwv_flow_val;
DROP PACKAGE wwv_dbms_sql;
DROP PACKAGE wwv_flow_key;
DROP LIBRARY wwv_flow_val_lib;
DROP VIEW wwv_flow_gv$session;

Deinstallation in PDB(s)

— SQLPLUS als SYSDBA aufrufen

sqlplus / as sysdba

— connecten gegen PDB (ich habe nur eine PDB und die heißt „PDBORA12C“.

ALTER SESSION SET CONTAINER=pdbora12c;

— CURRENT_SCHEMA auf APEX_040200 setzen

ALTER SESSION SET CURRENT_SCHEMA = apex_040200;

BEGIN
wwv_flow_upgrade.drop_public_synonyms;
END;

/

DROP USER apex_040200 CASCADE;
DROP USER FLOWS_FILES CASCADE;
DROP USER APEX_PUBLIC_USER CASCADE;
DROP ROLE APEX_ADMINISTRATOR_ROLE;
DROP USER APEX_LISTENER CASCADE;
DROP USER APEX_REST_PUBLIC_USER CASCADE;

— Cleanup XDB

declare
cfg XMLType;
l_dad_list dbms_epg.varchar2_table;
begin

if dbms_xdb.existsresource(‚/i/‘) then
dbms_xdb.deleteresource(‚/i/‘, dbms_xdb.delete_recursive_force);
end if;

if dbms_xdb.existsresource(‚/images/‘) then
dbms_xdb.deleteresource(‚/images/‘,dbms_xdb.delete_recursive_force);
end if;

dbms_epg.get_dad_list( l_dad_list );
for i in 1..l_dad_list.count loop
if upper(l_dad_list(i)) = ‚APEX‘ then
dbms_epg.drop_dad(‚APEX‘);
end if;
end loop;

cfg := dbms_xdb.cfg_get();

if cfg.existsNode(‚/xdbconfig/sysconfig/protocolconfig/httpconfig/webappconfig/servletconfig/servlet-mappings/servlet-mapping/servlet-name[text()=“PublishedContentServlet“]‘) = 1 then
cfg := cfg.deleteXML(‚/xdbconfig/sysconfig/protocolconfig/httpconfig/webappconfig/servletconfig/servlet-mappings/servlet-mapping/servlet-name[text()=“PublishedContentServlet“]/..‘);
end if;

if cfg.existsNode(‚/xdbconfig/sysconfig/protocolconfig/httpconfig/webappconfig/servletconfig/servlet-list/servlet/servlet-name[text()=“PublishedContentServlet“]‘) = 1 then
cfg := cfg.deleteXML(‚/xdbconfig/sysconfig/protocolconfig/httpconfig/webappconfig/servletconfig/servlet-list/servlet/servlet-name[text()=“PublishedContentServlet“]/..‘);
end if;

dbms_xdb.cfg_update(cfg);
commit;
dbms_xdb.cfg_refresh;

end;

/

Nun können wir noch mal prüfen, ob die APEX Schemata alle entfernt wurden:

— connecten als SYSDBA gegen CDB

sqlplus / as sysdba

show con_name

— hier sollte CDB$ROOT angezeigt werden

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

— hier sollte nun nichts mehr angezeigt werden.

 

— connecten gegen PDB(s)

ALTER SESSION SET CONTAINER = pdbora12c;

show con_name

— hier sollte PDBORA12C bzw. der Name Ihrer PDB angezeigt werden.

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

— hier sollte nun auch nichts mehr angezeigt werden.

Nun sollten wir eine saubere, APEX-freie Datenbank haben.

Kategorien:APEX 4, APEX 5, Oracle 12c Schlagwörter: ,

ORA-28014: Cannot drop administrative users

September 4, 2015 2 Kommentare

Als ich versuchte ein Upgrade mit APEX 5 in einer Oracle 12c R1 auf APEX 4.2 durchzuführen musste ich feststellen, dass es wohl einen Bug bei der APEX 5 Installation gibt, der nur mit einem Patch oder durch das vorherige deinstallieren von APEX 4.2 behoben werden kann.

Also versuchte ich, APEX 4.2 in der 12c zu deinstallieren.

sqlplus / as sysdba

@apxremov

Hierbei ist dann dieser Fehler aufgetreten:

ORA-28014: Cannot drop administrative users

Abhilfe

Die Abhilfe ist ganz einfach. Durch setzen eines „undokumentierten“ Parameters in der Datenbank kann man die Fehlermeldung abschalten:

ALTER SESSION SET „_oracle_script“ = TRUE;

@apxremov

Und schon funktioniert es.

Kategorien:APEX 5, Oracle 12c Schlagwörter: , , , ,