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.

25. Oktober 2007

Oracle 11g für Windows verfügbar

Nachdem Oracle die Version 11g seiner Datenbank erst nur für Linux veröffentlicht hat, gibt es nun auch die 64-Bit Version für Linux und die Windows Version der 11g Datenbank.
Die Version 11g des Oracle Warehouse Builders (OWB) gibt es dagegen weiterhin nur für 32-Bit Linux. Aber nun kann ich, über den Umweg der 11g Datenbank, doch unter Windows den neusten OWB testen....

Frage dabei an Oracle: Wo bleibt der OWB Patch 10.2.03 für 64-Bit Linux ?
Der wird dringend in meinen Projekten gebraucht.
Was für ein Service seinen Kunden gegenüber, wo dieser Patch doch bereits Anfang August für Windows und 32-Bit Linux erschienen ist. Aber das ist ja erst drei Monate her und ein Ende ist nicht in Sicht.
Wenn das so weiter geht, dann kommt wahrscheinlich erst die 64-Bit Linux Version der 11g Datenbank heraus. Die enthält dann den OWB 11g. Nur ist der dann gleich der aktuellsten, gepatchten Version 10.2.03 ???
Infos willkommen.

23. Oktober 2007

Virtual columns

Im AMIS Technology Blog bin ich erst jetzt über den Artikel zu virtuellen Columns in der Oracle 11g gestoßen. Vom Prinzip wird eine Spalte mit einer Berechnung definiert (z. B. Spalten_name AS (Spalte_A + Spalte_B) ). Die Datenbank merkt sich dann nur diese Formel.
Dieses Feature hätte ich so manches Mal gut einsetzen können, statt zusätzliche 'reale' Spalten mit Berechnungen zu füllen oder Views mit den Berechnungen anzulegen.
Sehr nützliche Funktionalität im BI Umfeld. Merken!

16. Oktober 2007

OWB Objekttransport ...

Das Problem kennt jeder der mit dem Oracle Warehouse Builder (OWB) arbeitet. Wie in größeren Projekten üblich habe ich eine Entwicklungs-, eine Test- und eine Produktionsumgebung. Und damit habe ich auch drei OWB Repositorys.
Der Weg ist immer aus der Entwicklung über Test zur Produktionsumgebung hin. Abweichend kann es vorkommen, dass z. B. auf Test ein Fehler der Produktion behoben wird, während auf Entwicklung bereits das nächste Release in Arbeit ist. Dann ist der Entwickler aber auch gefordert die Änderung von Test auf der Entwicklung nachzuziehen!
Um nun die OWB Objekte von einer Umgebung in die nächste zu transportieren erzeugt man sogenannte Exportdateien (MDL). Diese Dateien können dann auf der Zielumgebung entsprechend wieder importiert werden.
Nun transportiert man ja nicht immer alles aus einem Repository in das nächste. Was ist z. B. bei kleineren Bugfixen oder Erweiterungen in Teilen des Systems?
Bewährt haben sich dafür die 'Collections' im OWB. Hier kann ich bereits während der Entwicklung alle bearbeiteten Objekte eintragen. Beim späteren Export wird dann keines vergessen. Denn eine Collection kann exportiert werden und, da hier nur Referenzen auf die OWB Objekte hinterlegt werden, exportiere ich über die Collection alle eingetragenen Objekte! Klasse Sache, vorallem wenn das dann noch per OMB Skript automatisiert wird.
Aber das ist ein anderes Thema...

8. Oktober 2007

Fünf Oracle BI Trends für die nähere Zukunft

Mark Rittman hat in seinem Blog über die 'Five Oracle BI Trends for the Future' referiert.
Eine sehr interessante Aufstellung und wie immer gut geschrieben, lesenswert!

SAP plant Business Objects zu übernehmen

Nun kommt die Konsolidierung bei den Herstellern von BI Produkten richtig in Fahrt.
Nachdem bereits Oracle einige Übernahmen, ich denke da an Siebel und Hyperion, gemacht hat, scheint SAP im Zug zwang gewesen zu sein. Vor allem da wichtige Frontend Produkte für das SAP-BW beim Mitbewerber gelandet sind.
Nun kommt mit Business Objects ein weiterer Hersteller bei einer der großen Firmen unter. Fragt sich, ob das für die Kunden von BO von nutzen ist? Besonders die die kein SAP und/oder SAP-BW im Einsatz haben?
Der Markt der unabhängigen Hersteller lichtet sich. Bleibt abzuwarten, ob Microsoft oder IBM sich nicht bei den übriggebliebenen Anbietern bedienen werden. Die Konsolidierung geht sicher noch weiter.
Für die Kunden wird damit die Auswahl an unabhängigen Produkten immer kleiner. Die Käufer werden beweisen müssen, ob sie ihre 'Bauchläden' an BI-Produkten vereinen können und damit ihren Kunden (neuen wie alten) eine Perspektive anzubieten haben.
Die Kunden von BO werden eine klare Antwort dazu erwarten.

Anzeige