Vor kurzem wurde in der APEX-Community auf den Tipp Arbeiten mit external tablea der DBA Community verwiesen. In diesem Tipp erfahren Sie, wie Sie externe Tabellen praktisch einsetzen können - die Datei error_log des Oracle HTTP Server wird als APEX-Bericht verfügbar gemacht.

Wozu das gut ist? Gelegentlich stoßen Endanwender oder auch Entwickler auf das Problem, dass der Browser anstelle einer APEX-Seite einfach nur eine leere Seite oder einen HTTP-Fehlercode wie 404, 500 oder 401 anzeigt (Abbildung 1). In diesem Fall trat der Fehler schon im Webserver auf, noch bevor die APEX-Engine aktiv wurde. Beim Oracle HTTP Server (Apache) mit mod_plsql wird in diesen Fällen ein Eintrag in die Datei error_log geschrieben - diese befindet sich typischerweise im Verzeichnis $APACHE_ORACLEHOME/ohs/logs.

Abbildung 1: Der Browser zeigt anstelle einer APEX-Seite nur eine HTTP-Fehlermeldung an

Bei Problemen dieser Art muss man sich also auf dem Betriebssystem einloggen, in das Verzeichnis mit der Datei error_log navigieren, diese Datei öffnen und die Fehlermeldung am Ende der Datei nachsehen ...

Abbildung 2: Die Ursache steht im "error_log" - die HTML-Formularelemente wurden manipuliert

Diese Vorgehensweise ist natürlich recht mühsam - auf Unix- oder Linux-Systemen muss man sich per SSH einwählen und die Datei mit tail oder less ansehen; auf Windows-Systemen wird eine Remotedesktopverbindung benötigt - wenn dann noch schwache Netzwerke oder Firewalls dazukommen, kann das einfache Ansehen der Datei schon zur Herausforderung werden.

In diesem Tipp wird die Datei error_log als externe Tabelle in einem Datenbankschema verfügbar gemacht. Danach kann ein ganz gewöhnlicher APEX-Bericht erzeugt werden. Das Error-Log steht damit im Browser zur Verfügung - ein APEX-Administrator kann sie ganz bequem ansehen. Und wenn der Fehler so schwerwiegend ist, dass überhaupt keine APEX-Seite mehr funktioniert, kann die Datei immerhin noch mit SQL-Kommandos im Rahmen einer Datenbanksitzung betrachtet werden. Ein Betriebssystemzugriff ist nicht mehr erforderlich.

Abbildung 3: Apache error_log als APEX-Bericht

Abbildung 4: Apache error_log als SQL-Tabelle

Einrichtung der Externen Tabelle

Zunächst benötigt das Datenbankschema lesenden Zugriff auf das Betriebssystemverzeichnis, in dem die Datei error_log sich befindet. Am besten ist es, der DBA richtet ein Directory-Objekt ein und vergibt Leseprivilegien an das Datenbankschema, welches die externe Tabelle beinhalten soll. Natürlich kann SYS die Tabelle auch selbst erzeugen und das SELECT-Privileg weitergeben.

create directory apache_log_dir as '/oracle/u01/app/oracle/product/ohs/ohs/logs'
/

grant read on directory apache_log_dir to {apex-parsing-schema}
/

Als nächstes legen Sie die Tabelle wie folgt an - hierzu können Sie bereits den SQL Workshop verwenden ...

drop table ohs_error_log
/

CREATE TABLE ohs_error_log (
  zeitstempel date,
  schweregrad varchar2(200),
  client_ip   varchar2(200),
  error_modul varchar2(200),
  error_text  varchar2(4000)
)
ORGANIZATION EXTERNAL (
  TYPE oracle_loader
  DEFAULT DIRECTORY apache_log_dir
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE 
    nobadfile nologfile
    fields MISSING FIELD VALUES ARE NULL(
      zeitstempel date "DY MON DD HH24:MI:SS YYYY" terminated by whitespace enclosed by '[' and ']'  ,
      schweregrad char terminated by whitespace enclosed by '[' and ']',
      client_ip   char terminated by whitespace enclosed by '[client' and ']' ltrim,
      error_modul char terminated by ':',
      error_text  char (100000) ltrim
    )
   )
   LOCATION ('error_log') 
)
REJECT LIMIT UNLIMITED PARALLEL
/

Zunächst werden die Tabellenspalten, wie bei jeder anderen Tabelle, definiert; danach kommt das Besondere einer externen Tabelle: Mit SQL*Loader-Syntax wird das Format der Datei und die Abbildung auf die jeweiligen Tabellenspalten beschrieben. Wie man am Beispiel schön erkennen kann, werden nicht nur Zeilen- und Spaltenbegrenzungen definiert, sondern auch das Datumsformat oder die Tatsache, dass evtl. führende Leerzeichen entfernt werden sollen (ltrim). Eine vollständige Dokumentation der verfügbaren Kommandos finden Sie im Handbuch zum SQL*Loader.

Und dann sind Sie eigentlich auch schon fertig. Die Tabelle OHS_ERROR_LOG steht Ihnen nun wie jede andere Tabelle zur Verfügung. Da sie jedoch eine externe Tabelle ist, kann sie nur gelesen werden - INSERT-, UPDATE- oder DELETE-Kommandos sind nicht möglich. Ebensowenig können Sie einen Index auf die externe Tabelle erzeugen - das ist logisch - denn die externe Tabelle ist nicht mehr als eine Art "Zeiger" auf eine Datei. Sie können nun den APEX-Bericht direkt auf die externe Tabelle erzeugen oder deren Inhalte mit Hilfe eines Datenbank-Jobs regelmäßig in eine "normale" Taelle übernehmen.

Abbildung 5: Verwendung der externen Tabelle in einem APEX-Bericht

Natürlich ist dies nur ein Beispiel für die Verwendung externer Tabellen. Analog dazu lässt sich auf die alert.log-Datei ansprechen. Wenn Sie sich des Formates nicht ganz sicher sind oder es ihnen zu mühsam ist, die einzelnen Spalten voneinander zu trennen: Es gibt ein ganz einfache Variante, die eigentlich immer funktioniert - eine Zeile in der Datei ist dann eine Tabellenspalte vom Typ VARCHAR2(4000).

CREATE TABLE alert_log (
  zeile       varchar2(4000)
)
ORGANIZATION EXTERNAL (
  TYPE oracle_loader
  DEFAULT DIRECTORY alert_log_dir -- Directory-Objekt muss vorhanden sein
  ACCESS PARAMETERS (
    RECORDS DELIMITED BY NEWLINE 
    nobadfile nologfile
    fields MISSING FIELD VALUES ARE NULL(
      zeile char(10000)
    )
   )
   LOCATION ('alert_orcl.log') 
)
REJECT LIMIT UNLIMITED PARALLEL
/

Und das gleiche gilt auch für Logdateien des Betriebssystems oder anderer Softwareprodukte, die Sie ggfs. in einem APEX-Bericht anzeigen möchten. Mit Hilfe der externen Tabellen und APEX wird der Zugriff auf diese Dateien und das Erstellen einer Art "Cockpit-Anwendung" ein Kinderspiel.

Zurück zur Community-Seite