Oracle Application Express für DBAs

Application Express ist eine Entwicklungsumgebung zur Erstellung datenbankzentrischer Webapplikationen. APEX steht in allen Oracle Datenbank-Editionen auf allen gängigen Plattformen automatisch zur Verfügung. Da die browserbasierte Entwicklungsumgebung umfassend und intuitiv ist, können Entwickler mit SQL- und PL/SQL- Kenntnissen schnell zum Ziel kommen. Ein wichtiges Merkmal von APEX ist dabei, dass kein ausführbarer Code erzeugt wird, sondern die Anfragen im Browser direkt in PL/SQL-Aufrufe umgesetzt werden. Dabei werden die Webapplikationen, die in Datenbanktabellen gespeichert sind, in Echtzeit aus Metadaten "ge-rendert".

Je nach Datenbank-Release stehen unterschiedliche Architekturen zur Verfügung: Vor 11g ist eine 3 Tier Architektur mit Web Browser, Oracle HTTP Server (Apache) und mod PL/SQL oder der Einsatz des APEX Listeners möglich. Der Vorteil dieser Methode ist die Trennung des Database von der Middle Tier. Ab 11g kann stattdessen das embedded PL/SQL Gateway (kurz EPG) in der Datenbank genutzt werden. Dies stellt die einfachste Installationsvariante dar.

Die Installation

Schaut man sich die Installation der aktuellen Datenbank-Software an, wird man feststellen, dass - ähnlich wie bei dem Werkzeug SQL*Developer - eine ältere Version von APEX (bei 11.2 zum Beispiel APEX 3.2) ausgeliefert wird. Auch hier wird empfohlen, die aktuelle Version zu nutzen; das bedeutet, APEX 4.0 von OTN zu laden und zu installieren. Möchte man mehr über die neuen Features lesen, kann man sich über folgenden Link informieren. Im Folgenden wird in vier Schritten demonstriert, wie APEX 4.0.2 mit embedded PL/SQL Gateway installiert werden kann. Diese Installation stellt dabei nur eine Beispielinstallation dar. Weitere Installationsvarianten finden sich im APEX Installation Guide (siehe Informationen und Links).

Die Minimal-Voraussetzung für eine APEX-Installation ist denkbar gering: mindestens 100 MB Shared Pool Size, zwischen 450 und maximal 800 MB Plattenplatz für die Software (je nach Wahl der Sprache), 100 MB freien Platz im SYSTEM und 185 MB im Application Express Tablespace (für jede weitere Sprache weitere 75 MB). APEX ist in verschiedenen Sprachen wie z.B. Deutsch, Spanisch, Chinesisch übersetzt, so dass jeder Web Browser zur Laufzeit die gewünschte Sprache anzeigen kann.

1) Download der aktuellen APEX Software
Im ersten Schritt erfolgt der Download der APEX Software von http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html und das Auspacken der Datei. Im Verzeichnis apex finden sich dann alle Skripte zur Installation und Konfiguration von APEX. Diese werden im Folgenden, wenn nicht anders vermerkt, mit SYSDBA-Privilegien ausgeführt.

2) Installation
Die Basisinstallation wird mit Ausführung eines SQL-Skripts durchgeführt. Dazu muss entschieden werden, ob eine volle Development (Skript apexins.sql) oder nur eine Runtime Version (Skript apxrtins.sql) installiert werden soll. Folgendes Beispiel zeigt einen Aufruf zur Installation einer vollen Development Umgebung. Die ersten drei Argumente stehen für den Tablespace des APEX Users bzw. für den APEX Files User und den temporären Tablespace. Das virtuelle Verzeichnis für die APEX Bilder wird mit /i/ angegeben.

SQL> @apexins SYSAUX SYSAUX TEMP /i/
....
Thank you for installing Oracle Application Express.
Oracle Application Express is installed in the APEX_040000 schema.

The structure of the link to the Application Express administration services is as follows:
http://host:port/pls/apex/apex_admin (Oracle HTTP Server with mod_plsql)
http://host:port/apex/apex_admin     (Oracle XML DB HTTP listener with the embedded PL/SQL gateway)
...
JOB_QUEUE_PROCESSES: 1000
...

Nach ca. 15-20 Minuten ist das Skript beendet, und das APEX-Repository mit den entsprechenden Tabellen, Views, Synonymen und Triggern steht zur Verfügung. Zusätzlich sind die APEX-Datenbankuser APEX_040000 ("040000" steht für die APEX Version), APEX_PUBLIC_USER und FLOWS_FILES erzeugt worden. APEX_040000 ist der Repository User, der die Metadaten-Informationen enthält, der FLOWS_FILES User enthält die Upload-Dateien. Der APEX_PUBLIC_USER User wird hingegen für die Oracle HTTP Server oder Oracle Application Express Listener-Konfiguration benötigt und sollte nicht gesperrt sein.

Application Express ist ein metadatengetriebenes Werkzeug. Das bedeutet, dass alle Details einer APEX-Anwendung in den Repository-Tabellen abgespeichert werden. Wenn also beispielsweise eine Applikation gestartet wird, liest Application Express die Definitionen aus und generiert die entsprechende Webseite. Das Repository kann somit auch zur Analyse bestehender APEX-Applikationen genutzt werden. Möchte man einen Überblick über das APEX-Repository erhalten, kann man die View APEX_DICTIONARY abfragen.

SQL> SELECT apex_view_name, parent_view,comments FROM apex_dictionary WHERE column_name is null;

APEX_VIEW_NAME                 PARENT_VIEW
------------------------------ ----------------------------------
COMMENTS
--------------------------------------------------------------------------------
APEX_APPL_PLUGINS              APEX_APPLICATIONS
Stores the meta data for the plug-ins of an application.

APEX_WORKSPACES
Available Application Express (APEX) workspaces

APEX_APPLICATIONS              APEX_WORKSPACES
Applications defined in the current workspace or database user.

APEX_APPLICATION_ALL_AUTH      APEX_APPLICATIONS
All authorization schemes for all components by Application.
...

Weitere Informationen zum Repository finden sich im Tipp Mehr als Metadaten: Das Application Express-Repository und wie man es nutzen kann .

3) Passwort der ADMIN Users
Mit dem Skript apxchpwd wird nun das Passwort des ADMIN Users gesetzt bzw. verändert.

SQL> @apxchpwd
Enter a value below for the password for the Application Express ADMIN user.
...

Der ADMIN User ist der sogenannte Instance Administrator; ein Superuser, der die gesamte APEX Umgebung über die administrative Seite in APEX (siehe Screenshot unten) verwalten kann.

4) Konfiguration des Embedded PL/SQL Gateway
Das Skript apex_epg_config lädt nun automatisch die notwendigen Bilder (auch images) in die Datenbank und konfiguriert den DAD (kurz für Database Access Descriptor) für die Verwendung von APEX mit dem embedded PL/SQL Gateway.

SQL> @apex_epg_config.sql /home/oracle

Um eine korrekte Funktionsweise zu garantieren, muss noch der User ANONYMOUS entsperrt werden.

SQL> ALTER USER anonymous ACCOUNT UNLOCK;

Falls die XML DB noch nicht verwendet wurde, ist keine Konfiguration des HTTP Ports für den Listener erfolgt. Folgende Aktionen überprüft bzw. konfiguriert den HTTP Port. Dazu muss der Listener weder gestoppt noch erneut gestartet werden.

SQL> SELECT DBMS_XDB.GETHTTPPORT FROM dual;
GETHTTPPORT
-----------
          0
SQL> EXEC DBMS_XDB.SETHTTPPORT(8080);
PL/SQL procedure successfully completed.

SQL> SELECT DBMS_XDB.GETHTTPPORT FROM dual;
GETHTTPPORT
-----------
       8080

Ab 11g sind aus Sicherheitsgründen die Network Services ausgeschaltet. Dies bedeutet, dass Dienste wie Web Services, Mails usw. über APEX nicht nutzbar sind. Daher können die CONNECT Privilegien zu allen Hosts für den APEX_040000 mit dem Package DBMS_NETWORK_ACL_ADMIN erzeugt werden. Ein einfaches PL/SQL Beispiel zum Einschalten der Funktionalität findet sich hier . Möchte man mehr zu ACLs wissen, kann man sich über den Tipp Access Control Lists: Schutz vor Missbrauch mächtiger Datenbank-Packages informieren. Werden diese Dienste nicht verwendet, kann dieser Schritt auch weggelassen werden.

Nun ist die Installation beendet! Wer möchte, löscht zusätzlich noch den überflüssigen Datenbank-User APEX_030200. Der DBA kann sich nun mit dem APEX Instance Administrator Account ADMIN in die administrative Seite, wie folgt, einloggen:

http://hostname:8080/apex/apex_admin

Für eine größere Ansicht auf das Bild klicken.

Möchte man mehr über die Installation und das Konfigurieren des PL/SQL Gateways lesen, eignet sich der Tipp Einrichtung und Nutzung des PL/SQL Embedded Gateways .

Die ersten Schritte: Workspaces, APEX User und Security

Neu mit APEX ist das Konzept des Workspace. Ein Workspace ist ein Bereich in einer Application Express Installation, die mehreren Usern erlaubt, ihre Applikation und Daten in einem gemeinsamen privaten Bereich - dem Workspace - zusammenzufassen. So können sich mehrere APEX User einen Workspace teilen oder auch einem dedizierten Workspace angehören.

Datenbankseitig ist der Workspace ein logischer Bereich, der aus Tabellen, Views, Stored Procedures usw. besteht. Ein einzelnes Datenbankschema kann dabei mit einem oder mehreren Workspaces verknüpft sein. Die Administration erfolgt hauptsächlich über die APEX Seite für administrative Services (siehe Screenshot oben) und nicht über SQL*PLUS oder dem Werkzeug Enterprise Manager.

Zusätzlich zum Workspace stehen unterschiedliche APEX User Rollen zur Verfügung:

Instance Administrator ist der Superuser.
Workspace Administrator hat weniger Rechte als der Instance Administrator. Workspace Administratoren können allerdings einige administrative Aufgaben erledigen wie Workspaces verwalten und User Accounts managen.
Developer erzeugt Applikationen und besitzen oder teilen einen Workspace.
End User kann nur auf Applikationen zugreifen.

Im ersten Schritt wird ein Workspace erzeugt, der einem existierenden Schema zugeordnet ist. Da aus Sicherheitsgründen nicht automatisch alle Schemas - speziell die Oracle Default Schemas - freigeschaltet sind, schalten wir in unserem Beispiel das Schema SCOTT frei. Der Workspace kann auch mit einem neuen nicht existierenden Schema verbunden werden. In diesem Fall wird automatisch ein neues Datenbankschema und ein neuer Tablespace angelegt.

-- Freischalten des SCOTT Schemas
SQL> EXEC APEX_040000.APEX_SITE_ADMIN_PRIVS.UNRESTRICT_SCHEMA(p_schema => 'SCOTT');
SQL> COMMIT;

Nun kann mit einem einfachen Workflow in APEX ein Workspace angelegt werden. Ebenso einfach lassen sich im Bereich "Manage Workspaces" APEX User als Developer oder Workspace Administrator anlegen.

Für eine größere Ansicht auf das Bild klicken.

Die Workflows und Wizards in APEX sind intuitiv zu nutzen. Tauchen trotzdem Fragen auf, sollte man einen Blick ins APEX Administrator Handbuch (siehe Informationen und Links) werfen.

Häufig stellt sich die Frage nach den Usern und den zugehörigen Rechten in APEX. APEX verwendet ein ganz bestimmtes Sicherheitsmodell. Wenn eine APEX-Seite aufgerufen wird, so wird die zugrundeliegende Datenbanksitzung aufbaut und stets mit einem einzigen bestimmten, niedrig privilegierten Datenbank-User aufgebaut. Beim Embedded PL/SQL Gateway ist das der User ANONYMOUS, beim mod Pl/SQL typischerweise der APEX_PUBLIC_USER. Diese User haben außer einem CREATE SESSION-Privileg keinerlei Rechte. Dennoch können Tabellen des APEX Workspace selektiert und die PL/SQL-Funktionen, -Prozeduren und Packages im Schema ausgeführt werden. Das liegt daran, dass die SQL-Kommandos und PL/SQL-Aufrufe nicht direkt ausgeführt werden, sondern innerhalb der Application Express-Engine. Die APEX-Engine setzt dazu intern die Privilegien des entsprechenden Workspace Schemas, damit immer mit den Privilegien des APEX Schemas gearbeitet werden kann.

Nun kann der Entwickler loslegen und sich mit dem entsprechenden Workspacenamen, Usernamen und Passwort in die Entwicklerumgebung einloggen. Folgende URL ermöglicht dies:

http://hostname:8080/apex

Auch hier ist nur ein Web Browser nötig; keine zusätzliche Installation auf den Client Rechnern ist erforderlich. Der Tipp geht an dieser Stelle nicht weiter auf die Möglichkeiten der Entwicklung mit APEX ein. Für Anfänger sei allerdings der Hinweis auf einige Tutorials der APEX Community zum Einstieg in APEX genannt - hiermit bekommt man recht schnell einen Eindruck von der Art und Weise, wie Anwendungen mit APEX gebaut werden.

Zusätzlich gibt es von der MT AG aus Ratingen Einsteigertutorials auf YouTube. Darin lässt sich "live" verfolgen, wie einfach sich Anwendungen mit APEX erstellen lassen.

Administrative Aufgaben: Monitoren, Tunen und Ressourcen verwalten

Nach der Einführung in das Workspace Konzept ist es sicherlich gut vorstellbar, dass Application Express als Hosting-Umgebung eingesetzt werden kann. Unterschiedliche Entwickler können dabei unabhängig in verschiedenen Workspaces arbeiten, und den Eindruck gewinnen, die Datenbank alleine vollständig auslasten zu können. Wenn der Server allerdings unter Last steht, sollten bestimmte Anwendungen bevorzugt werden. Zu diesem Zweck eignet sich der Database Resource Manager, der schon in einem anderen DBA Tipp behandelt worden ist. Die einzige Frage, die man sich im Zusammenhang mit APEX stellen muss, ist, wie die Ressource Consumer Gruppen definiert werden können. Eine Abfrage auf V$SESSION bestätigt, dass APEX nur mit einem Datenbank User arbeitet, je nach Architektur mit dem ANONYMOUS oder APEX_PUBLIC_USER User.

SQL> SELECT username, action, module, client_info FROM v$session 
     WHERE username is not null AND action is not null ORDER BY 1;

USERNAME        ACTION               MODULE                 CLIENT_INFO
--------------- -------------------- ---------------------- --------------------
ANONYMOUS       PAGE 1               APEX:APPLICATION 103   USCHWINN
ANONYMOUS       PAGE 4150            APEX:APPLICATION 4000  USCHWINN
...

Allerdings nutzt APEX das Package DBMS_APPLICATION_INFO und listet daher die angemeldeten APEX-Nutzernamen in der Spalte CLIENT_INFO und beim aktiven Page Rendering sogar die Application und die Page ID in den Spalten MODUL und ACTION. Mit dieser Information kann eine Ressource Consumer Gruppe in Abhängigkeit von einer Applikation oder Seite (auch Page) definiert werden und somit ein Ressource Plan wie gewohnt erstellt werden. Folgende Tipps geben Anleitungen dazu, wie man mit dem Database Resource Manager arbeiten kann:

Der Oracle Enterprise Manager bietet, wie oben schon erwähnt, keine spezielle Unterstützung für APEX; nach einer Installation werden APEX-Anwendungen also nicht überwacht. Kennt man das APEX-Repository, lässt sich allerdings eine zusätzliche Überwachung über benutzerdefinerte Metriken (auch user defined metrics) im Enterprise Manager einrichten. Dabei wird die View APEX_ACTIVITY_LOG in der SQL-Abfrage verwendet, da diese jeden Seitenabruf und die verbrauchte (elapsed) Zeit aufzeichnet. Folgende Abfrage zeigt die Verwendung:

SQL> SELECT ac.flow_id || ' (' || a.application_name ||') - PAGE '|| step_id as identifier,
  1  max(elap) as value
  2  FROM apex_040000.wwv_flow_activity_log ac, apex_applications a
  3  WHERE a.application_id = ac.flow_id
  4* GROUP BY ac.flow_id, a.application_name, ac.step_id;

IDENTIFIER                                                        VALUE
------------------------------------------------------------ ----------
103 (USCHWINN 03) - PAGE 101                                    .114737
4050 (Oracle APEX Internal Administration) - PAGE 60            .330307
4050 (Oracle APEX Internal Administration) - PAGE 20            .446418
4550 (Oracle APEX Login) - PAGE 10                             2.966482
103 (USCHWINN 03) - PAGE 1                                      .099926
101 (USCHWINN 02) - PAGE 1                                      .063462
4000 (Oracle APEX AppBuilder) - PAGE 1000                     .00138915

Formuliert man diese Abfrage als benutzerdefinierte Metrik so um, dass eine bestimmte Applikationen (hier: 103) über ein bestimmtes abgelaufenes Zeitintervall (hier: 5 Minuten elapsed time) überprüft wird, sieht die Metrik im Enterprise Manager zum Beispiel folgendermassen aus:

Für eine größere Ansicht auf das Bild klicken.

Eine genaue Anleitung zum Definieren einer benutzerdefinierten Metrik bzw. weitere Informationen zum APEX Repository findet sich in:

Benutzerdefinierte Metriken in Grid Control

APEX-Anwendungen mit dem Enterprise Manager überwachen

Wie in der Einleitung schon erwähnt, handelt es sich bei einer APEX-Applikation hauptsächlich um SQL- und PL/SQL- Abfragen. Ein Tuning ist also mit den Standard-Werkzeugen wie EXPLAN PLAN, DBMS_XPLAN, SQL Tracing oder SQL Monitoring im Enterprise Manager möglich. APEX liefert darüberhinaus auch Page spezifisches Tuning an. So können zum Beispiel im Footer jeder Region zusätzliche Informationen zum Zeitverbrauch und den abgerufenen Zeilen mit Parametern wie #TIMING#, #ROWS_FETCHED#, #TOTAL_ROWS# ausgegeben werden. Folgender Screenshot zeigt die Einstellungen im Region Footer.

Für eine größere Ansicht auf das Bild klicken.

Page-Debugging ist ebenfalls recht einfach möglich. Voraussetzung ist das Einschalten des Debuggings für die Applikation. Auf der Hauptseite der Applikation klickt man dazu auf den Button "Edit Application Properties" und stellt die Eigenschaft "Debugging" auf "Yes". Danach kann mit dem Link "Debug" in der Developer Toolbar unterhalb der Anwendungsseite das Debugging ausgeführt werden. Folgender Screenshot zeigt die Developer Toolbar mit den entsprechenden Links.

Ein interaktiver Bericht über den Link "View Debug" zeigt die einzelnen Ausführungsschritte und die verbrauchte Zeit, so dass Langläufer leicht identifiziert werden können. Reicht dies immer noch nicht aus, kann ein SQL Trace eingeschaltet werden. Dazu fügt man der URL der Anwendungsseite einfach den Ausdruck &p_trace=YES hinzu, wie das folgende Beispiel zeigt.

Das Kommando, das APEX im Hintergrund absetzt ist, geht über ein Setzen von SQL_TRACE=YES hinaus und lautet:

ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12'

Es wird eine Trace-Datei erzeugt, die sich, wie gewohnt, im Trace Verzeichnis der Datenbank befindet und mit tkprof in lesbare Form gebracht werden kann. Möchten Sie mehr zu dem Thema Tuning erfahren, finden Sie einige Anregungen und Tipps in:

Ausführungspläne mit DBMS_XPLAN

Langlaufende Operationen, SQL Monitoring (auch Real-time Monitoring) und Active Reports

Mehr Performance! Tuning von APEX-Anwendungen - Teil 1: Tracing, Analyse und Diagnose

Informationen und Links

Folgende Links bieten einen guten Überblick und Einstiegspunkt für das Arbeiten mit APEX:

Dokumentation

Zurück zur Übersicht

Zurück zur Community-Seite