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.

SOUG Day Bern 2026: Avaloq live auf Exadata Cloud@Customer