APEX 3.2.1 Patchinstallation

02.
September
2009
Veröffentlicht von: Marco Patzwahl

Liebe Apex-Gemeinde, es ist mal wieder soweit. Oracle hat einen neuen Patch für APEX Version 3.2 zur Verfügung gestellt. Leider kann der Einzel-Patch nur über Metalink bezogen werden. Wer jedoch APEX komplett neu installieren möchte, kann sich die aktuelle Version von folgender Webseite herunterladen:

Liebe Apex-Gemeinde, es ist mal wieder soweit. Oracle hat einen neuen Patch für APEX Version 3.2 zur Verfügung gestellt. Leider kann der Einzel-Patch nur über Metalink bezogen werden. Wer jedoch APEX komplett neu installieren möchte, kann sich die aktuelle Version von folgender Webseite herunterladen:

Opens external link in new windowhttp://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html

Der Folgende Tipp soll Ihnen beschreiben, wie Sie den Metalink-Patch (8548651) erfolgreich installieren können:

 

1. Stellen Sie sicher, dass kein Benutzer aktuell mit APEX arbeiten kann.


1a. Wenn Sie den XML DB HTTP Server verwenden, setzen Sie den Port auf 0. Merken Sie sich aber auch den alten Port, damit dieser nach der Patchinstallation wieder eingesetzt werden kann:

COL http_port NEW_VALUE http_port
select dbms_xdb.gethttpport as http_port FROM dual;
exec dbms_xdb.sethttpport(0);

 

1b. Wenn der Apache eingesetzt wird stoppen Sie ihn.

Beispiel für Oracle 10g:

<ORACLE_BASE>\<ORACLE_HTTPSERVER_HOME>\opmn\bin\opmnctl stopproc
ias-component=HTTP_Server

Ab 11g kann Error Logging aktiviert werden. Damit werden alle Fehler, die im Skript aufgetreten sind, in einer Tabelle gespeichert:

CREATE TABLE system.apex_patch_errlog (
USERNAME        VARCHAR(256),
TIMESTAMP       
TIMESTAMP,
SCRIPT          VARCHAR(1024),
IDENTIFIER      VARCHAR(256),
MESSAGE         CLOB,
Statement       CLOB);

SET ERRORLOGGING ON TABLE system.apex_patch_errlog

Nun starten wir den Patch:

@D:\p8548651_111060_GENERIC\patch\apxpatch.sql


2. Prüfen Sie nun im Logfile oder in der Errlog Tabelle, ob Fehler aufgetreten sind:

select * from system.apex_patch_errlog; /* Nur 11g*/

SQL> host find "ORA-" D:\apex_3.2.1_p8548651_111060_GENERIC\patch\apxpatch.log

---------- D:\P8548651_111060_GENERIC\PATCH\APXPATCH.LOG

Hinweis: In Version 11.1.0.7 kann ( wird :-) ) der folgende Fehler beim Einspielen des Patches auftreten:

ORA-00600: internal error code, arguments: [kgiinb_invalid_obj]

Dafür stellt Oracle einen Patch zur Verfügung (Patch 7420394 ). Leider ist dieser nur auf folgenden Plattformen (Stand August 2009) verfügbar:

  •  Linux x86
  •  HP-UX PA-RISC (64-bit)
  •  Sun Solaris SPARC (64-bit)
  •  Linux x86-64
  •  IBM AIX on POWER Systems (64-bit)
  •  HP-UX Itanium


2a. Sie können auch im Repository nachsehen, ob Fehler aufgetreten sind:

col comp_name FORMAT a30
col version format a15
select comp_name,version,status,modified from dba_registry where comp_id='APEX';
COMP_NAME                      VERSION         STATUS      MODIFIED
------------------------------ --------------- ----------- --------------------
Oracle Application Express     3.2.1.00.10     VALID       27-AUG-2009 10:27:11

 

2b. Wer es noch genauer haben möchte kann nachsehen, ob Objekte Invalid geworden sind:

select owner,object_name,status FROM dba_objects
where (owner = 'FLOWS_FILES' or owner = 'APEX_030200')
and status<>'VALID'

 

2c. Falls Invalide Objekte auftreten, können Sie als Benutzer SYS folgendes Skript starten:

@?/rdbms/admin/utlrp


3. Nun werden neue Bilder/Dokumente auf den Server hochgeladen (bitte nur Durchführen, wenn Apache nicht eingesetzt wird).

Das Skript wird mit einem Parameter aufgerufen, der den Pfad zum Patchverzeichnis angeben sollte.
Schauen Sie sich beim Einsatz des XML DB HTTP Servers vorher die Anzahl der Dokumente im  /i[mages]/doc Ordner an, dann können Sie feststellen, ob der Uploadprozess geklappt hat:

SELECT count(*) FROM PATH_VIEW WHERE UNDER_PATH(res, '/i/doc',1)>0; /* für 10g*/
SELECT count(*) FROM PATH_VIEW WHERE UNDER_PATH(res, '/images/doc',1)>0; /* für 11g*/

COUNT(*)
              
----------------------

2567

spool d:\p8548651_111060_GENERIC\patch\apex_images_patch.log

REM Für 11g können wir wieder unsere Fehlertabelle auspacken:
SET ERRORLOGGING ON TABLE system.apex_patch_errlog

@D:\p8548651_111060_GENERIC\patch\apxldimg.sql D:\p8548651_111060_GENERIC\patch
spool off


Auch hier sollte nach Fehlern gesucht werden und ggf. das Skript neu starten (meist liegt der Fehler in einer falschen Pfadangabe).

Zum Prüfen, ob die Bilder\Dokumente richtig hochgeladen wurden können wir die Anzahl der Dateien im /images/doc /*11g*/ bzw. /i/doc /*10g*/ zählen:

SELECT count(*)
FROM PATH_VIEW
WHERE UNDER_PATH(res, '/images/doc',1)>0;
/*11g für 10g bitte /i/doc verwenden*/

COUNT(*)
         
----------------------

3015


3b. Falls Apache eingesetzt wird, werden die Bilder in das Verzeichnis auf dem Server kopiert:

  • Für Windows

    xcopy /E /I D:\p8548651_111060_GENERIC\patch\images <ORACLE_HTTPSERVER_HOME>\Apache\Apache\images

  • Für UNIX

    cp -rf /opt/oracle/p8548651_111060_GENERIC/patch/images ORACLE_HTTPSERVER_HOME/Apache/Apache


4. Nun kann der XML DB HTTP Port (falls Sie keinen Apache/IAS/OHS verwenden) wieder auf seinen Ursprungswert zurückgesetzt werden:

exec dbms_xdb.sethttpport(&http_port)


###### Happy End ###### oder bis zum nächsten Patch ....

Wenn Sie APEX nicht durch mühsames Probieren selbst erlernen wollen, kommen Sie doch in eine von unseren beiden 5 Tages Schulungen (Opens internal link in current windowGrundlagen / Fortschritt).

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.