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.
Oracle ExaCCAvaloq Core BankingHelvetiaSOUG Day 2026PDB Cloning
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.