Affiliate

26. Oktober 2007

Auditdaten des Workflows ohne Störung der Ladeprozesse löschen

In der Version 10g des Oracle Warehouse Builders hat Oracle eine Möglichkeit geschaffen den neuen Scheduler der Oracle Datenbank für die Automatisierung der Workflows zu nutzen. Das funktioniert gut.

Vielleicht sollte ich sagen unter normalen Umständen gut. In einem meiner Projekte wird alle paar Minuten per Scheduler ein Workflow gestartet. Das ist ok und läuft. Dabei werden dann allerdings auch entsprechend viele Auditdaten vom Workflow erzeugt. Die Menge wächst auch im kleinsten Loglevel rasch an. Ganz auf die Auditdaten verzichten wollte man aber auch nicht. Nach einger Zeit hat man daher die Auditdaten gelöscht. Schlagartig lief kein Workflow mehr! Warum?

Oracle hat die Verbindung des Schedulers mit dem Workflow über den OWB so eingerichtet, dass sich der Schedulerjob als Parent der zu startenden Workflows in den Auditdaten einträgt. Als Gruppierungselement ist das durchaus praktisch. Aber beim löschen der Auditdaten wird auch diese Parentid mit gelöscht und damit verliert der Schedulerjob seinen Bezug zu den Auditdaten. Das führt zu dem Effekt, dass der Schedulerjob anspringt, seine Parentid nicht findet und damit die Ausführung abbricht. Hier hilft nur ein stoppen und starten bzw. ein neues Deployment der Schedulerjobs aus dem OWB Controll Center heraus. Nur dann initialisiert sich der Schedulerjob wieder neu und er erhält eine neue Parentid.
Das Ganze ist sehr unpraktisch, könnte der Schedulerjob doch bei verlorener ID sich einfach selbst neu initialisieren. Aber das hat Oracle nicht vorgesehen.

Nun wollten wir aber die Auditdaten, möglichst störungsfrei für die Ladeprozesse, löschen können. Was tun?
Eine Erinnerung an die alte Jobsteuerung der Datenbank bringt die Lösung. In Kurzform: Die Schedulerjobs erstellt man per Skript selbst. Darin enthalten ist der Aufruf einer Procedure, die wiederum den eigentlichen Workflowjob startet. That's all.

Damit steht der Schedulerjob zwar nicht mehr in den Auditdaten, aber das störte hier nicht. Der große Vorteil, ich kann nun Auditdaten löschen wie ich möchte, ohne das die Ausführung der anstehenden Ladeläufe gestört wird. Der Schedulerjob startet ohne murren einfach den nächsten Workflowjob und kümmert sich nicht mehr um die alten Auditdaten.

Hier ein Muster für einen Schedulerjob ...

BEGIN
DBMS_SCHEDULER.create_job (job_name => '',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN owbrun.p_wf_execute(''''); END;',
start_date => trunc(SYSDATE),
repeat_interval => 'FREQ = Weekly;INTERVAL = 1;BYDAY=MON,TUE,WED,THU,FRI,SAT;BYHOUR=3,9,15,21;BYMINUTE=4;',
end_date => NULL,
enabled => TRUE,
comments => NULL
);
END;

.. und die verwendete Procedure zum starten des Workflows.

create or replace procedure p_wf_execute( p_wf_name VARCHAR2)
is
exec_return_code number;
Begin
-- Initialize Return Code
exec_return_code := wb_rt_api_exec.RESULT_FAILURE;
-- Start Workflow
exec_return_code := WB_RT_API_EXEC.RUN_TASK('', 'PROCESS', p_wf_name, ',', ',', 0, 0);
END p_wf_execute;

Das alles läuft stabil, wir können nun jederzeit in Teilen oder auch komplett die Auditdaten löschen. Die laufenden Ladeprozesse werden dadurch nicht gestört.
Kommentar veröffentlichen

Anzeige