SOUG Day Bern · 11. März 2026 · Speaker Report
Migration Mission: How Avaloq Conquered Exadata Cloud@Customer
Ein Rückblick auf meinen Vortrag beim Swiss Oracle User Group Day in Bern – von der Legacy-Infrastruktur zur modernen Cloud-Plattform.
Am 11. März 2026 durfte ich am SOUG Day in Bern einen Vortrag halten – einer der technisch spannendsten Präsentationen, die ich bisher vorbereitet habe. Das Thema: Wie wir bei Helvetia die Avaloq Core Banking-Workloads erfolgreich auf Oracle Exadata Cloud@Customer (ExaCC) migriert haben. Ein Projekt mit echten Herausforderungen, unerwarteten Erkenntnissen – und einem erfolgreichen Abschluss.
„Das Ziel war klar: alle Oracle-Workloads aus dem Legacy-Rechenzentrum konsolidieren – Avaloq als letztes und anspruchsvollstes Kapitel.»
01 — Mission
Das letzte Kapitel der Konsolidierung
Helvetia hatte sich zum Ziel gesetzt, sämtliche Oracle-Workloads vom Legacy-Rechenzentrum auf Exadata Cloud@Customer zu verlagern. Die Migration des Avaloq Core Banking Systems war dabei das finale und komplexeste Teilprojekt – ein System, das höchste Anforderungen an Stabilität, Compliance und Performance stellt.
02 — Target Architecture
Trennung von Datenbank und Applikation
Die Zielarchitektur setzt konsequent auf die Trennung von Datenbank- und Applikationsschicht. Durch klare Rollen und Zugriffskontrollen sowie die Anbindung externer Services über den Oracle Connection Manager (OCM) – beispielsweise Swisscom MQ und TwintSafe – entstand eine robuste, wartbare Plattform.
- DB / App Separation
- Klare Trennung für bessere Stabilität und einfachere Wartbarkeit.
- Access Control
- Definierte Rollen und Berechtigungen via Oracle Connection Manager.
- Externe Services
- Swisscom MQ und TwintSafe nahtlos über OCM eingebunden.
03 — Key Challenges
Die entscheidende Architektur-Frage: RAC vs. Single Node
Eine der zentralen Diskussionen im Projekt drehte sich um die Oracle-Architekturentscheidung: Multi-Node RAC oder Single Node? Nach sorgfältiger Abwägung fiel die Entscheidung auf Single Node RAC – mit überzeugenden Gründen:
- Zertifizierung
- Volle Compliance mit Avaloq-Zertifizierungsanforderungen.
- Stabilität
- Keine RAC-typischen Konflikte (TAC), einfacherer Betrieb.
- Kosteneffizienz
- Kein ungleichmässiger Node-Einsatz, dynamisches Scaling möglich.
Beim Thema Wartung und Failover stellte sich heraus, dass ein DR-Switchover nicht nur die Datenbankschicht, sondern auch die Avaloq-Applikationsschicht betrifft. Aufgrund dieser cross-layer dependency ist der Prozess noch nicht automatisiert – das ist jedoch geplant, sobald die End-to-End-Orchestrierung vollständig validiert ist.
04 — Cloning Concept
Dynamic PDB-Cloning Carousel
Besonders stolz bin ich auf das entwickelte Cloning-Konzept für die effiziente Bereitstellung von Test-Datenbankumgebungen. Das Modell basiert auf einem dynamischen Karussell aus mindestens drei TMR-Umgebungen (Test/Migration/Refresh):
- Sparse Clones für minimalen Storage-Verbrauch – Pre-EOD, Post-EOD, wöchentlich, monatlich und ad-hoc.
- Zeitkritische Zyklen: Pre- und Post-EOD-Klone werden innerhalb enger Zeitfenster erstellt.
- Refreshable Clone: Mindestens eine TMR-Umgebung hält immer einen aktuellen Stand für zeitnahes Testing bereit.
- Seconds-Fast Clones mit minimalem Storage-Verbrauch und Continuous Operation als klare Vorteile.
05 — Performance Insights
Was nach dem Go-live auffiel
Nach dem Go-live zeigte sich eine spürbar verbesserte Anwendungsreaktionszeit. Gleichzeitig traten einige interessante Beobachtungen zutage, die wertvolles Optimierungspotenzial offenbarten:
- Policy-Konflikte
- Avaloq-Listener vs. Cloud-Security-Policies erforderten Abstimmungsaufwand.
- NFS-Latenz
- RUP-Performance-Engpass durch NFS-Storage-Latenz – lokaler Disk vs. DR-Prinzipien.
- Exadata-Stärken
- NFS-intensive Prozesse nutzen Exadatas Low-Latency-I/O nicht optimal aus.
06 — Lessons Learned
Was ich mitnehme
- Die Migration war erfolgreich: Avaloq läuft auf Exadata Cloud@Customer.
- Kritische Applikationskomponenten müssen von ExaCC ausgelagert werden.
- Eine feste Mindest-CPU-Allokation schränkt Elastizität und Kostenoptimierung ein.
- Patch-Koordination (z. B. dom0) erfordert deutlich mehr Aufwand als erwartet.
- NFS-lastige Prozesse können Exadatas Low-Latency-Vorteile nicht voll ausschöpfen.
Für die Zukunft stehen auf meiner Liste: Clone-Strategie verfeinern (Flashback Database nutzen), Hybrid-Caching für kompilierte Dateien erkunden, Automatisierung der TMR-Karussell-Abläufe – und eine optimierte CPU-Allokation für bessere Kosteneffizienz.
Danke
Ein Teamerfolg
Dieses Projekt war definitiv kein Einzel-Sprint. Mein herzlicher Dank gilt allen Beteiligten: dbi Services (Jérôme Witt, Clemens Bleile, Marc Wagner) für die technische Exzellenz, Oracle CSS für den kontinuierlichen Support, Avaloq für das aktive Engagement, Tradeware für tiefes ExaCC-Know-how und HCL für den zuverlässigen Betrieb der Plattform.
Interesse am Thema?
Fragen zur Migration, zur PDB-Cloning-Strategie oder zu den Architekturentscheidungen? Ich freue mich über den Austausch – schreib mir gerne oder kommentiere diesen Beitrag.