Daten sind unsere Leidenschaft!

Data Warehouse des Risk Controllings

Projekt: Data Warehouse des Risk Controllings

Einsatzumgebung:

Das ursprüngliche System war für die Verarbeitung der Daten auf monatlicher Basis konfiguriert. Mit Beginn der Finanzkrise erhielt das Risk Controlling eine höhere Priorität im Management, daher wurde das zweite System eingeführt. Dieses verarbeitet die Daten auf täglicher Basis und führt zusätzlich eine wöchentliche Berechnung durch.

Beide Systeme beinhalten die gleichen Sourcen und führen dieselben Berechnungen durch. Der Unterschied besteht dabei im Wesentlichen in der Datenaktualität. Geplant ist das „Daily/Weekly“ – System im Laufe des Jahres 2012 zum führenden System zu machen.

Die Verarbeitungsschritte gliedern sich sehr abstrakt beschrieben wie folgt:

Gathering – Physikalischer Transport der Daten von den Quelllokation zu einer Sammelplattform, Synchronisation, Kontrolle der Vollständigkeit und Datenqualität

Conversion – Umwandlung der Datenstruktur in die Zielstruktur, entsprechend dem jeweils vorgegebenen oder derzeit gültigen Datenmodell

Content Mapping – Vereinheitlichung der Daten, sofern lokale Variationen vorliegen

Validation – Kontrolle der Formate und Inhalte

Adjustment – Tool/View für die Anpassung der gelieferten Daten, sofern diese Fehler beinhalten – führt die korrigierten Daten wieder in den Prozess

Integration – Erzeugt die Relationen zwischen Exposures, Anleihen, Kunden und Einrichtungen lokationsübergreifend, um eine globale Sicht auf die Daten zu erhalten

Reporting – Erzeugen der Stars und Datamarts für das Reporting

DV-Umfeld

Exadata, Oracle 11g, PL/SQL, SQL, SAS, Power Designer, Windows, OELinux, Shell, Perl

Meine Rolle im Projekt:

Aufgrund der Größe des Projektes wurde vor ca. 2 Jahren eine neue Architektur für die Gesamtapplikation entworfen. Dabei wurde entschieden, die Datenbank auf Exadata zu migrieren. Gleichzeitig sollten die Applikationen nicht mehr auf den gleichen Servern wie die Datenbank installiert werden, weil dies immer wieder zu Performanceproblemen geführt hatte. Die Verbindung zwischen Exadata und Applikationsserver wird durch einen NFS-Server hergestellt.

Zunächst war ich mit der Koordination der Serverumzüge und dem Aufbau der gesamten Infrastruktur beschäftigt. Die Herausforderung war, sämtliche Funktionalitäten aller Applikationen aufrecht zu erhalten, wobei alle Server physisch in zwei neue DataCenter umgezogen wurden, der Storage erweitert und die Server vollständig neu aufgebaut wurden. Gleichzeitig fand die Migration der Datenbanken auf Exadata statt.

Die Produktivnahme konnte im November 2011 wie geplant stattfinden. Der neue Name „Finance Data Warehouse“ kommt zustande, weil das zugrundeliegende Datenmodell sich ebenfalls geändert hat und nun zum neuen Standard werden soll.

Eine weitere wichtige Aufgabe ist die Planung und Durchführung des monatlichen „Clone“ der „Daily Umgebung“. Dabei werden die aktuellen Daten der „Monthly Umgebung“ und die historischen Daten der „Daily Umgebung“ „gemerged“. Der historische Tablespace der „Daily Umgebung“ wird ausgehängt (als TTS) und die Datenbank gelöscht. Aus einem Backup wird die „Monthly Umgebung“ dann zunächst vollständig aufgebaut. Danach werden die historischen Daten der „recoverten“ „Monthly Umgebung“ gelöscht und der historische Tablespace „gedropt“. Dann kann der historische Tablespace der „Daily Umgebung“ wieder eingehängt werden. Im Anschluss müssen dann eine Reihe von Steuertabellen angepasst werden und sämtliche Partitionsgruppen einmal gedreht werden.

Die gesamte Aktion dauert ca. 34 – 48 Stunden und muss in dieser Zeit vollständig abgeschlossen werden. Das hat bis auf einmal bisher auch funktioniert. Leider ist Oracle 11.2.0.2 nicht unbedingt das Datenbank-System das sich ein Kunde wünscht. Es enthält zu viele und zu gravierende Bugs, die vor allem bei dieser Aktion immer wieder entdeckt werden.

Seit Anfang Februar bin ich im Wesentlichen mit der Planung der Patches zum Fix des SCN-Bugs beschäftigt. Für die Exadatas eine echte Herausforderung, weil das Patchen selbst auf drei Leveln abläuft. CellNode Patch, Infrastruktur Patch und anschließend ein Bundle Patch für die Instanz. Zusätzlich noch diverse „one offs“, die vorher auf Konflikte mit dem Bundle Patch geprüft werden mussten.

Außerdem bin ich der Ansprechpartner für sämtliche Entwickler für administrative Probleme oder Probleme mit der Infrastruktur.

Es bleibt weiterhin spannend!

Bildnachweise: ©Fotolia_69892248_S-ci.jpg

Das könnte Sie auch interessieren

Bleiben Sie informiert:

its-people hilft Ihnen...

Weitere Blogthemen: