Integration von PostGreSQL als Oracle-Alternative im Gesamtbankensystem OBS – ein Projektbericht

Die Frage, ob es eine Alternative zu Datenbank-Anbietern wie Oracle und Microsoft gibt, beschäftigt die IT-Verantwortlichen in Unternehmen vielerorts. Anbieter “Die Software” (Gesamtbankensoftware), beantwortet diese Frage mit „Ja“. Denn sie bietet nun ihre Online Banken System (OBS) zusätzlich mit der Open Source Software PostGreSQL an – statt nur mit Oracle. Klaus Friese erläutert die Hintergründe.

von Klaus J. Friese, Geschäftsführer Die Software Peter Fitzon

Oracle-Datenbanken sind zwar Standard in vielen Industrien und Märkten, aber immer mehr wird nach Alternativen Ausschau gehalten – auch bei den Banken. Denn nahezu ebenso universell wie die Nutzung von Oracle sind die Klagen der IT-Manager und Geschäftsführer über die hohen Lizenzkosten des Datenbankanbieters. Oft werden deshalb auch Lösungen designed, mit denen sich die Lizenzkosten minimieren lassen, anstatt den technologisch optimalen Weg bei der Serverarchitektur zu suchen. Dieser Weg hat sich jedoch für viele Unternehmen und IT-Abteilungen als Fass ohne Boden herausgestellt. Spätestens dann, wenn auf die IT-Abteilungen Lizenzaudits zukommen, können sie ein Lied von der Komplexität der Regelungen singen, und die Personalkosten fangen an, die möglichen Lizenzkosten zu übersteigen. Darum setzen viele Unternehmen inzwischen auf OpenSource-Lösungen.

Klagen über hohe Oracle-Kosten verlangen Lösung

Die Klagen über hohe Kosten durch Oracle-Lizenzen und die vermehrten Anfragen der Kunden führten zur Zielvorgabe des Managements, dass das Gesamtbankensystem OBS (Online Banken System) möglichst komplett und als Alternative zu Oracle auf eine OpenSource-Software-Infrastruktur umzustellen – und zwar, auch wenn die Datenbank im Vordergrund stand, auch unter Berücksichtigung weiterer Komponenten wie Betriebssystem und Clients. Eine Architektur, die Betriebssystem und Datenbank von der Anwendungsschicht klar entkoppelt, war schon immer das Designparadigma für die OBS, was die Umstellung letztlich deutlich vereinfacht hat. Zuerst legte das Team die Ziele fest, die die OpenSource-Lösung erfüllen musste:

1. Eine Stabilität adäquat zur Oracle-Lösung
2. Eine starke Performance
3. Eine hohe Zukunftssicherheit
4. Vorhandensein eines verlässlichen Supports

Einige Fragen ließen sich schnell klären: CentOS (Community Enterprise Operating System auf Linux-Basis) als Betriebssystem-Alternative zu den Oracle- oder Redhat-Linux-Distributionen bereitete keinerlei Probleme. Clients in Java waren sowieso vorhanden bzw. in der Entwicklung – und die Umstellung des Druckoutputtools „ORT“ von OBS auf eine Java-Basis ein schon lange durch das entsprechende Team geplanter Schritt.

Stabilität, Zukunftsfähigkeit, Performance sind zentrale Entscheidungskriterien

Doch der größte „Knackpunkt“ war die Datenbanksoftware: Stabilität, Zukunftsfähigkeit und Performance waren zentrale Entscheidungskriterien. Die Entscheidung für PostGreSQL fiel relativ schnell. Denn diese Software ist ähnlich leistungsfähig wie Oracle, sie ist ein „echtes“ Open Source- und Community-Projekt, dessen Quellcode offenliegt und offen bleibt und die kontinuierlich von der Community gepflegt wird. Zudem steht immer das volle Produkt zur Verfügung und nicht bloß Teilversionen oder nur Module. Und nicht zuletzt gehört diese Software keinem Unternehmen, sie ist und bleibt frei verfügbar und kann daher auch nicht das Schicksal wie MySQL erleiden. Außerdem existiert ein verlässlicher Support, was gerade für den Bankbetrieb ein entscheidendes Kriterium ist: Postgres konnte nicht nur durch Funktionen, sondern auch durch die relativ weite Verbreitung und die Tatsache, dass ausreichend viele Firmen in Deutschland sich auf den Support dieser Datenbank spezialisiert haben, überzeugen.

Zentraler Ansatzpunkt für die Umstellung von OBS auf Postgres war der IO-Layer aus der OBS-Schichtenarchitektur: Hier wurden zunächst einige zentrale Tabellen als Prototyp ausgewählt und anschließend mit der Umstellung begonnen. Schnell kristallisierten sich einige Problempunkte heraus, die eigentlich gar nicht in der Datenbank selbst, sondern in der Integration in die Applikation lagen: Der eingesetzte PreCompiler für die Anwendung war noch nicht ausgereift – fast täglich mussten Bugs an den Hersteller berichtet werden, fast täglich trafen neue Versionen dieser Software ein. Gleichzeitig war diese Kombination Precompiler/Postgre einfach ein bisschen weniger „Fehlertolerant“ als Oracle. Es zeigten sich Schwachstellen, die im Zusammenspiel mit Oracle nie aufgefallen waren und die das Team nun beheben musste.

Nachdem die als Prototyp definierten Tabellen „endgültig“ funktionierten, begann die „Massenarbeit“: Mussten doch über 500 Tabellen und die dazugehörige IO-Schicht umgestellt werden. Hier bewährte sich die konsequente Standardisierung des Layers innerhalb von OBS. Die Attribute, Keys, Trigger und OBS-spezifischen Funktionen jeder Tabelle sind in einem XML-Meta-File abgelegt: Dadurch konnte die Abteilung „Design und Standards“ rasch einen Generator schreiben, der den IO-Layer weitgehend generieren konnte. Mit Hilfe dieses Tools war die „Massenarbeit“ in 6 Wochen erledigt – wesentlich schneller, als das Projektteam ursprünglich geplant hatte.

Eine wesentlich größere Herausforderung waren im nächsten Schritt die Regressionstests. Bei einer Applikation, die alle Bereiche des Bankgeschäfts abdeckt, kein kleines Unterfangen. Regressionstests bedeuten eine systematische Wiederholung von Tests, um zu verifizieren, dass die durchgeführten Modifikationen in bereits getesteten Teilen der Software keine neuen Fehler verursachen. Gleichzeitig führte das Team Performancetests durch und setzte diese „Schmankerl“ um:

1. Tabellen, die Besonderheiten wie die sogenannten Blobs enthielten, also Binary Large Objects, in der Praxis zum Beispiel gescannte Kundendokumente
2. Funktionen, die aus technischen Gründen außerhalb des IO-Layers abliefen, wie die Überwachung der Tagesendverarbeitung

OBS mit PostGreSQL – jetzt Teil des Produktportfolios

Auch wenn sich die „Schmankerl“ als besonders aufwändig herausstellten – seit dem 31.03.2018 ist der erste Kunde mit dem Gesamtbankensystem OBS mit PostGreSQL produktiv: Der Betrieb läuft stabil, es sind keine Fehler durch Postgres aufgetreten, und die Performance ist hervorragend. Berater haben gelegentlich kritisiert, warum die neuesten Features von Oracle nicht quer durch alle Schichten von OBS ausgenutzt werden. Jetzt erleben auch Zweifler die Vorteile der OBS-Architektur: Die Anwendung von Postgres bringt den Kunden eine signifikante Kostenersparnis und ein höheres Maß an Flexibilität. OBS mit Postgres ist nun ein neues Produkt und wird als funktionierende, verlässliche, leistungsstarke und preiswertere Alternative zur Oracle-Lösung angeboten. Aber die Architektur von OBS erlaubt es, dass die Kunden natürlich auch künftig die Oracle-Lösung wählen können bei gleichem Funktionsumfang der Anwendung.aj