Im sechsten Teil der Reihe Objekttypen fahren wir mit „J“ wie Job fort. Dazu erläutern wir weitere Job-bezogene Objekttypen außerhalb der alphabetischen Reihenfolge. Anschließend geht es mit „L“ und dem Objekttyp Library und dessen Verwendung als Brücke zwischen PL/SQL und den Betriebssystemfunktionen weiter.

Der DBMS_SCHEDULER

BEGIN
  SYS.DBMS_SCHEDULER.CREATE_JOB
   (
       job_name       => 'Jobtest1'
      ,schedule_name  => 'Schedule1'
      ,program_name   => 'Program1'
      ,job_class      => 'ORDIX_JOB_CLASS'
   );
  SYS.DBMS_SCHEDULER.ENABLE
   ( NAME             => 'DH.Jobtest');
END;
/

SYS.DBMS_SCHEDULER.CREATE_JOB_CLASS
   (
       job_class_name           => 'ORDIX_JOB_CLASS'
      ,resource_consumer_group  => 'LOW_GROUP'
      ,service                  => NULL
      ,logging_level            => SYS.DBMS_SCHEDULER.LOGGING_FULL
      ,log_history              => 30
      ,comments                 => NULL
   );

CREATE OR REPLACE FUNCTION W2KWRAPP (
  lpCmdLine IN VARCHAR2,
  uCmdShow IN PLS_INTEGER := 1 )
RETURN PLS_INTEGER
IS
  EXTERNAL LIBRARY kernel32 NAME "WinExec"
  LANGUAGE C CALLING STANDARD PASCAL
  PARAMETERS (
    lpCmdLine STRING,
    uCmdShow LONG,
    RETURN LONG
  );
/

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = C:\oracle\product\10.2.0\db_1)
      (PROGRAM = extproc)
      (ENVS = "EXTPROC_DLLS=ANY")
    )
  )

EXTPROC_CONNECTION_DATA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    )
    (CONNECT_DATA =
      (SID = PLSExtProc)
      (PRESENTATION = RO)
    )
  )

SET SERVEROUTPUT ON
DECLARE
  v_ret NUMBER;
BEGIN
  v_ret := W2KWRAPP ('cmd /q /c mkdir c:\temp\test');
  DBMS_OUTPUT.PUT_LINE ('1st command: v_ret=' || v_ret);

END;
/

Der Objekttyp Job und sieben weitere Objekttypen sind im Zusammenhang mit der Job-Verwaltung und dem Paket DBMS_SCHEDULER in Oracle 10g eingeführt worden. Ein Job kombiniert die Metadaten eines Programms mit einer Zeitdefinition. Sowohl das Datum der Ausführung als auch die damit verbundene Aktion kann direkt im Job oder auch indirekt über ein Schedule bzw. Programm erfolgen.

Neben den Basiskomponenten des Pakets DBMS_SCHEDULER existieren weitere, optionale Komponenten. Den Schedule erweitert ein Zeitfenster (Window) um eine Laufzeit und eine optionale Verknüpfung mit einem Ressourcenplan. Mit einem Window Group lassen sich mehrere Zeitfenster zusammenfassen.

Jobs können in Klassen gruppiert werden. Jobklassen sind die Verbindung zum Resource Manager der Datenbank. Mittels der Konsumentengruppen können Ressourcenzusagen für die jeweiligen Jobklassen gegeben werden. Oracle erstellt automatisch eine Jobklasse mit dem Namen AUTO_TASKS_JOB_CLASS und eine Konsumentengruppe mit dem Namen AUTO_TASKS_CONSUMER_GROUP.

Die automatisch angelegten Komponenten werden von Oracle zur Aktualisierung der Tabellenstatistiken genutzt. Aus einer Abfolge von Programmen lassen sich zudem Ablaufketten (Chain) definieren. Ein Job kann eine solche Abfolge von Programmen anstoßen.

Alle zuvor genannten Scheduler-Komponenten sind mit einem gleichnamigen Objekttyp verbunden. In Abbildung 1 sind sämtliche Objekttypen, die im Zusammenhang mit der Jobverwaltung stehen, aufgeführt.

Eine ausführliche Betrachtung des Themas DBMS_SCHEDULER finden Sie in der ORDIX News 1/2005 [1].

Beispiele

Eine Job-Definition besteht, wie das Beispiel in der Abbildung 2 zeigt, mindestens aus einem Job, der Ausführungszeit, hier eine Referenz auf ein Schedule („Schedule1“), und einer Referenz auf ein auszuführendes Programm („Program1“). Ein Beispiel für die Definition eines Job Clas Objektes ist in Abbildung 3 aufgelistet.

Ausnahmen

Folgende Scheduler-Komponenten erzeugen keine Objekte im Sinne von DBA_OBJECTS:

• ANYDATA_ARGUMENT
• CHAIN_EVENT_STEP
• CHAIN_RULE
• CHAIN_STEP
• RUNNING_CHAINS
• METADATA_ARGUMENT
• PROGRAM_ARGUMENT
• GLOBAL_ATTRIBUTES
• JOB_LOG

Bei der Scheduler-Komponente mit dem Namen AGENT_REGISTRATION_PASSWORD handelt es sich um ein Objekt im Sinne von DBA_OBJECTS, dessen Objekttyp aber nicht namentlich in der View DBA_OBJECTS definiert ist, sondern als Objekttyp UNDEFINED aufgeführt wird. Es handelt sich hierbei um das Passwort zur Anmeldung des Agenten zur Remote-Jobausführung, welcher mit der Version 11g eingeführt wird.

Library Objekte

Eine Library ist eine Sammlung von Funktionen, die über eine Schnittstelle der PL/SQL-Engine zur Verfügung gestellt wird. Libraries können statisch oder dynamisch eingebunden werden. Eine statische Library liegt in Form von C-Byte Code in der Datenbank vor. Ein statisches Library-Objekt wird wie folgt definiert:

CREATE OR REPLACE LIBRARY ORDIX_LIB TRUSTED AS STATIC

Eine dynamische Library ist ein mit einer Datei verknüpftes Schemaobjekt. Über ein dynamisches Library-Objekt wird aus PL/SQL heraus auf externe Funktionen zugegriffen, die in einer externen Library-Datei implementiert sind. Seit Oracle 8 stehen diese Aufrufe (Callouts) aus PL/SQL heraus zur Verfügung.

Eine typische Anwendung ist der Zugriff auf eine betriebssystemnahe Funktion. Diese liegt in der Form von Shared-Library-Dateien vor. Das folgende Beispiel erstellt ein Library-Objekt auf die Betriebssystem-Shared-Library-Datei „Kernel32.dll“ unter Windows, die sich im System32-Verzeichnis befindet.

CREATE OR REPLACE LIBRARY kernel32 as 'C:\windows\system32\kernel32.dll';

Der Status VALID des Objektes in der View User_libraries besagt nicht unbedingt, dass die angegebene Datei im lokalen Filesystem tatsächlich existiert. Ein Library-Objekt kann natürlich auch auf einen Remote-Rechner verweisen. Sollte sich die Library-Datei nicht im angegebenen Pfad befinden, kommt es erst bei der Ausführung der Funktion zu einem Fehler: ORA-06520: PL/SQL: Fehler beim Laden der externen Bibliothek.

Die Library kommt zum Einsatz

Um eine externe Funktion aufrufen zu können, muss die aufrufende PL/SQL-Prozedur (siehe Abbildung 4) wissen, in welcher Datei sich diese Funktion befindet. Dazu wird in der Alias Library nach dem Dateinamen gesucht und anschließend via SQL-NET der Listener kontaktiert. Dieser startet den Oracle Agent EXTPROC-Prozess. Hierfür wird ein Eintrag, wie in den Abbildungen 5 und 6 gezeigt, in der Listener.ora und der Tnsnames.ora benötigt.

Von nun an kommunizieren der EXTPROCProzess und die PL/SQL-Engine direkt miteinander. Der Prozess EXTPROC besteht für die Dauer der aufrufenden Session. Nach Beendigung der Session wird auch EXTPROC beendet.

Für jede Session, die externe Funktionen verwendet, startet ein eigener EXTPROC-Prozess. Die PL/SQL-Engine übergibt den Namen der Shared Library-Datei an den EXTPROC-Prozess mit Hilfe des Library-Objektes und der PL/SQL Wrapper Function. Dieser bringt die Shared-Library-Funktion zur Ausführung und übergibt das Resultat der PL/SQL-Engine. Die erfolgreiche Ausführung der externen Funktion kann über den Rückgabewert (siehe Abbildung 7) kontrolliert werden.

Ausblick

In einer der nächsten ORDIX News setzen wir die Artikelreihe dann wieder alphabetisch fort.

Dirk Hansmeier (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen