Suchen...
Generic filters
Exact matches only
Search in title
Search in excerpt
Search in content

Erweitern von DeltaMaster Modeler - Monitoring

DeltaMaster Modeler begleitet den ganzen Weg der Daten von den Rohdaten aus der Quelle über die Aufbereitung der Daten bis hin zum Laden der Daten in die multidimensionale Datenbank. Ein großer Vorteil von Modeler ist dabei das automatisch erstellte Logbuch, in dem jeder Schritt von Modeler protokolliert wird, wann dieser ausgeführt wurde, wie lange er gedauert hat und ob er erfolgreich war.

DeltaMaster Modeler

Für die Standard-Aufgaben „Füllen der DIM- und FACT-Tabellen“ gibt er im Fehlerfall sogar sehr konkrete Hinweise, welche Datensätze den Fehler verursacht haben. Das ist ein großer Vorteil von Modeler, der die entsprechende Fehlersuche stark verkürzen kann.

In den meisten Fällen geht der ETL-Prozess aber über diese Standard-Aufgaben hinaus. Es müssen Daten aus den Quellsystemen geladen werden, es werden Zwischenberechnungen in ‚materialisierten’ Views erstellt, vielleicht werden auch noch Daten für andere Zwecke als der Erstellung der OLAP-Datenbank aufbereitet. Um dann noch ein aussagekräftiges Logbuch zu haben, sind ein paar Schritte notwendig. Diese sollen hier kurz erläutert werden.

Allgemeine Aspekte

Jeder ETL-Prozess, also z.B. das nächtliche Laden des aktuellen Datenstandes nennt Modeler eine Transformation. Alles, was von Modeler protokolliert werden soll, sollte also definiert in einer solchen Transformation ablaufen. Deshalb steht am Anfang des ETL-Prozesses immer die Prozedur ‚P_SYSLOG_StartTransformation’ und am Ende die Prozedur ‚P_SYSLOG_StopTransformation’. Standardmäßig werden beide Prozeduren in der P_Transform_All aufgerufen. Soll aber z.B. der gesamte Ablauf eines SSIS-Paketes protokolliert werden, empfiehlt es sich, diese beiden Prozeduren in der Transform-All-Prozedur zu deaktivieren und diese dafür am Anfang und am Ende des SSIS-Paketes aufzurufen.

Solange eine Transformation aktiv ist (StartTransformation ist ausgeführt, aber noch kein StopTrans-formation), werden alle Log-Einträge dieser Transformation zugeordnet. Einzelne Log-Einträge beginnen mit Aufrufen der Prozedur P_SYSLOG_StartLog und enden mit der entsprechenden Prozedur P_SYSLOG_StopLog. Beiden Prozeduren wird der Text des Log-Eintrages als Parameter übergeben. P_SYSLOG_StopLog wird zusätzlich noch eine Fehlernummer (bei Erfolg 0) und die Anzahl der verarbeiteten Zeilen übergeben. Je mehr Log-Einträge erstellt werden, umso ‚gesprächiger’ ist nachher das Logbuch.

Für das erfolgreiche Abarbeiten einer Transformation endet damit auch schon die Arbeit. Viel interessanter ist es jedoch, Fehlerfälle dokumentieren zu können. Im Fehlerfall wird die Prozedur P_SYSLOG_StopLog mit einer negativen (meist -6 oder -9) Fehler-Nummer aufgerufen. Ein Fehlertext kann noch mit einem Update-Befehl hinzugefügt werden:

HTML1

Im SSIS werden Fehlerfälle mit der roten Verknüpfung aufgerufen. In SQL-Prozeduren kann der Quellcode, der zu einem Fehler führen kann mit einer Try-Catch-Konstruktion abgefangen werden. Danach kann er im Catch-Teil in DeltaMaster Modeler Logbuch eingetragen werden.

Soll der Fehler zum Abbruch der gesamten Transformation führen, muss er wiederum durch raiserror ausgelöst werden, da er ja durch das Try-Catch-Konstrukt abgefangen wurde. Dies eröffnet dem Modelierer eines ETL-Prozesses die Möglichkeit zwischen systemrelevanten Fehlern und systemunkritischen Fehlern zu unterscheiden.

<2>Einsatz in SQL-Code

Beispielhaft wird nun eine Prozedur vorgestellt, die für die Dokumentation einzelner SQL-Statements eines Projektes geschrieben wurde und welche die Prozess-Dokumentation von Modeler nutzt:

HTML2x

Der Prozedur werden ein SQL-Statement und der Name des SQL-Statements übergeben. Sie be-steht nur aus einem Try-Catch-Block. Im Try-Teil wird P_SYSLOG_StartLog, das SQL-Statement und, bei Erfolg, P_SYSLOG_StopLog ausgeführt. Kommt es im Try-Teil nun zu einem Fehler, wird der Catch-Teil ausgeführt, indem die Fehlernummer und der Fehlertext von SQL-Server abgerufen werden (Funkionen error_number() und error_message()) und mit P_SYSLOG_StopLog und dem oben beschriebenen Update-Statement ins Modeler-Logbuch eingetragen werden.

Für SQL-Code, der in Prozeduren gekapselt ist, besitzt jede Modeler-Datenbank die Prozedur ‚P_SYSLOG_Exec_ErrorHandler’. Wenn die Prozeduren über diese Prozedur aufgerufen werden, werden diese auch im Modeler-Logbuch protokoliert. Diese Prozedur löst den Fehler nach der Dokumentation wieder aus, so dass er immer zum Anhalten des ETL-Prozesses führt.

Einsatz in SSIS-Paketen

In SSIS-Paketen können die vorgestellten Prozeduren für das Modeler-Error-Handling in „SQL ausführen“-Tasks aufgerufen werden. Der Wirkungsweise ist dieselbe, deshalb verzichten wir hier auf ein weiteres Beispiel.

Sehr wertvoll kann es sein, wenn z.B. Fehler, die bereits beim Importieren der Daten aus den Quellen entstehen, genau so detailliert in der Modeler-DAS angezeigt werden können, wie die Fehler im Standard-Modeler Prozess (Erstelllung DIM- und FACT-Tables). Leicht möglich ist das, weil SSIS-Pakete solche Fehler abfangen können und in einer Error-Tabelle speichern können: