Fehlersituationen während des Betriebes

Auch wenn das BIS während der Entwicklung ausgiebig getestet wurde, kann es während des Betriebes trotzdem zu Fehlersituationen kommen. Neben übersehenen Implementierungsfehlern in den Prozessen kann es auch zu Fehlern kommen, die unabhängig von der Implementierung entstanden sind.

4.2.1. Falsche Datenlieferungen

Der Datenintegrationsprozess benötigt die Daten aus den Quellsystemen als Einga-bedaten. Eine mögliche Fehlersituation tritt dann ein, wenn die Eingabedaten nicht vorhanden sind und der Prozess somit nicht ablaufen kann.

Gerade bei einem direkten Zugriff auf operative Tabellen ist die Gefahr für einen nicht erfolgreichen Zugriff groß. So kann es passieren, dass das Quellsystem auf-grund von Wartungsarbeiten vorrübergehend abgeschaltet wurde, es überlastet ist und nur sehr langsame Zugriffe zulässt oder sich Strukturen der Tabellen geändert haben. Aber auch bei einem indirekten Zugriff über Schnittstellen kann es zu diesen Fehler kommen. Wartet der Datenintegrationsprozess etwa auf die Lieferung eines Datenabzuges als Datei in ein spezielles Verzeichnis, so kann bei einer ausbleiben-den Lieferung ebenfalls keine Verarbeitung stattfinausbleiben-den.

Eine zweite Gefahr sind falsche Eingabedaten. Beim indirekten Zugriff auf Datenab-züge als Datei kann versehentlich die vorherige Periode erneut geliefert werden.

Auch bei direkten Zugriffen auf die Quellsysteme lassen sich falsche Datenabzüge nicht verhindern. Ein Negativszenario kann sein, dass sträflicherweise im operativen System mit Testdaten gearbeitet wurde. Wenn dieser Test von den Entwicklern des operativen Systems nicht kommuniziert wurde, greift der Datenintegrationsprozess bei seinem Datenabzug Testdaten mit ab und verarbeitet diese fälschlicherweise.

Das Problem aus Sicht des Datenintegrationsprozesses ist folglich, dass dieser nicht erkennen kann, ob die Eingabedaten korrekt sind. Die einzige Stelle, an der Daten

Kapitel 4 - Testen während des Betriebes

abgewiesen werden, ist das Anwenden der Qualitätsregeln. Wenn jedoch eine dop-pelte Datenlieferung einer Periode erfolgt und die Daten gemäß der Qualitätsregeln syntaktisch und semantisch korrekt sind, werden sie auch weiterverarbeitet.

Key Name Job GueltigVon GueltigBis AnlageID AendID 1736 Mustermann Student 01.09.2003 31.08.2006 273 309 5392 Mustermann Entwickler 01.09.2006 31.05.2011 309 436 9287 Mustermann Manager 01.06.2011 31.12.9999 436 NULL 11826 Musterfrau Direktor 01.06.2011 31.12.9999 441 NULL

Tabelle 4-1: Zeitscheiben mit Prozess-ID [Eigene Darstellung]

Da jederzeit mit einer falschen Datenlieferung gerechnet werden muss, muss sich ein Entwickler überlegen, wie er die Korrektur der Lieferung schnell und einfach durchführen kann. Besonders schmerzhaft ist es, wenn aufgrund einer falschen Lie-ferung die Faktentabelle und die Dimensionstabellen komplett neu bestückt werden und alle historischen Datenstände erneut eingespielt werden müssen. Einfacher ist es, wenn lediglich die falsche Lieferung entfernt wird und anschließend nur die korri-gierten Daten neu eingespielt werden.

Um Datenlieferungen rückgängig machen zu können, müssen diese eindeutig identi-fizierbar sein. Es empfiehlt sich, jeden Prozess, der Daten im Data Warehouse schreibt oder manipuliert, mit einer eindeutigen ID auszustatten und Datensatzände-rungen damit zu kennzeichnen. Damit ein vorher gültiger Stand wiederhergestellt werden kann, dürfen Änderungen nicht physisch durch ein UPDATE erfolgen, sondern logisch mittels Zeitscheiben. Jeder Datensatz erhält zwei Zeitstempel, die Auskunft geben, über welchen Zeitraum (gültig-von und gültig-bis) er gültig war bzw. ist. Der gerade aktuelle Satz hat als gültig-bis-Datum den maximalen Zeitstempel (31.12.9999). Dieses Verfahren ist bereits von den Typ 2 SCD bekannt (Tabelle 3-4).

Eine Erweiterung um die Prozess-ID vereinfacht hierbei jedoch das Aufspüren der fehlerhaften Lieferung. Ein Prozess trägt seine ID beim Anlegen einer neuen Zeit-scheibe sowohl bei der aktuell gültigen ZeitZeit-scheibe als Anlage-ID ein als auch bei der vorher gültigen verkürzten Zeitscheibe als Änderungs-ID.

Kapitel 4 - Testen während des Betriebes

Wenn in dem Beispiel der Tabelle 4-1 die Lieferung des Prozesses „436“ falsch war, lautet das SQL-Statement zum Zurücknehmen der Änderungen wie folgt:

01

Listing 4-1: Korrigieren einer falschen Lieferung [Eigene Darstellung]

4.2.2. Unachtsamkeit

Automatismen und gleichartige bzw. monotone Abläufe verleiten Menschen zur Un-achtsamkeit. Hieraus ergibt sich unter Umständen das Problem, dass ein Fehler in der Verarbeitung während des Betriebes nicht wahrgenommen wird. Vornehmlich wird eine Unachtsamkeit durch eine Überflutung von Benachrichtigungen des BIS ausgelöst. Wenn jeder kleinste Verarbeitungsschritt sowohl beim erfolgreichen als auch nicht erfolgreichen Durchlaufen eine Benachrichtigungsmail versendet, so kann das Postfach des Entwicklers am Morgen schnell sehr voll werden. Wenn von 100 Mails 99 einen Erfolgsstatus melden und eine einzige Mail auf einen Fehler hinweist, so kann diese wichtige Mail leicht übersehen werden. Es ist also darauf zu achten, positiv Meldungen weitestgehend zu vermeiden und nur die tatsächlich wichtigen Informationen wie Fehler und Warnungen zu kommuniziert.

4.2.3. Infrastruktur

Wie jede Software ist auch das BIS abhängig von der Infrastruktur in der es einge-bunden ist. Problemen mit dem Betriebssystem, der Hardware oder dem Netzwerk wirken sich direkt auf das BIS aus. Entsprechend müssen Änderungen an der Infra-struktur auch getestet werden. Verändert sich beispielsweise die Adresse von einem Netzlaufwerk, so muss geprüft werden, ob ein Datenintegrationsprozess von diesem

Kapitel 4 - Testen während des Betriebes

Netzlaufwerk Dateien bezieht. Wenn ja, müssen diese Prozesse auf die neue Adres-se umgestellt werden, damit ihre Dateizugriffe nicht ins Leere laufen.

Da das DWS sehr ressourcenhungrig ist, gilt es diese stets zu überwachen. Wenn etwa die zur Verfügung stehenden Speicherkapazitäten an ihre Grenzen kommen, müssen frühzeitig Gegenmaßnahmen getroffen werden (z.B. Aufstockung der Kapa-zitäten). Selbiges gilt auch für die Ressourcen CPU und Arbeitsspeicher.

Ein grundsätzliches Problem bei BIS ergibt sich aus der Abhängigkeit von den einge-setzten Produkten und Werkzeugen. Das im Anhang A exemplarisch gezeigte BIS besteht aus fünf verschiedenen kommerziellen Produkten (Datenintegrationswerk-zeug, relationale Datenbank, OLAP-System, Analyse Front-End, Job-Steuerung).

Jedes dieser Produkte kann selber fehlerhaft sein und Bugs enthalten. Somit ergibt sich durch die eingesetzten Produkte einer weitere Fehlerquelle im Betrieb.