Willkommen zurück am Architektur-Reißbrett! Im letzten Beitrag haben wir die Zero Downtime Option (ZDO) beleuchtet. Heute betrachten wir das architektonische Puzzleteil, das extrem kurze Downtimes bei S/4HANA-Upgrades überhaupt erst ermöglicht: Das Silent Data Migration Infrastructure (SDMI) Framework.
Viele Basis-Administratoren wundern sich, dass der SUM-Prozess abgeschlossen ist, das System wieder online geht, aber im Hintergrund plötzlich massive Datenbankaktivitäten stattfinden. Was genau ist SDMI, wie verändert es den Systembetrieb nach dem Upgrade und warum ist der technische User SDM_USER unser neuer bester Freund?
Das Problem der klassischen Datenkonvertierung
In alten SAP ERP-Releases passierte die Datenumsetzung (Data Conversion) traditionell in der Execution-Phase des Upgrades – also während der harten System-Downtime (Transaktion SPDD / PARCONV). Wenn Milliarden von Datensätzen in neue S/4HANA-Zieltabellen (z.B. bei der CVI-Umstellung oder im Finance-Umfeld) geschrieben werden mussten, dauerte die Downtime mitunter mehrere Tage.
SAP erkannte, dass dieses Design für S/4HANA nicht mehr tragbar war. Die Lösung: Wir entkoppeln den Code-Upgrade vom Data-Upgrade.
Deep-Dive: So funktioniert SDMI
SDMI verlagert die physische Datenkonvertierung aus der Downtime in die reguläre Uptime, nachdem der SUM bereits fertig ist.
Die architektonische Funktionsweise:
-
Downtime-Phase: Der SUM legt die neuen Zielstrukturen (Tabellen/Felder) im DDIC an, aber er füllt sie nicht. Das System geht online.
-
Die Uptime-Maskierung: Die SAP-Applikation nutzt sogenannte "Compatibility Views". Wenn ein Endanwender auf einen alten Datensatz zugreift, der noch nicht migriert wurde, berechnet der View die neuen Werte on-the-fly.
-
Die Hintergrund-Migration (SDMI): Im Hintergrund startet der Job-Daemon des Frameworks. Der designierte technische User
SDM_USERbeginnt, die Milliarden von Datensätzen in kleinen, kontrollierten Batches aus den alten Strukturen in die neuen Strukturen umzuschreiben.
Ressourcen-Management und Basis-Monitoring
Ein solches Konzept birgt natürlich Gefahren: Was passiert, wenn SDMI die gesamten Dialog-Workprozesse blockiert und die Performance des produktiven ERP-Systems zerstört?
Hier glänzt die SDMI-Architektur: Die Hintergrundjobs sind hochgradig ressourcenschonend konfiguriert (throttling). Sie nutzen dedizierte Batch-Workprozesse und drosseln sich automatisch, wenn das System unter hoher CPU- oder Speicherlast steht.
Als Basis-Administratoren müssen wir diesen Prozess über das zentrale Dashboard Transaktion SDM_MON (Silent Data Migration Monitor) überwachen. Hier sehen wir die Migrationsklassen, den Fortschritt der Client-unabhängigen (Cross-Client) und Client-abhängigen Tabellen sowie eventuelle Fehler bei inkonsistenten Datensätzen, die eine manuelle Bereinigung erfordern.
📢 SAP BASIS NEWS-TICKER (Stand: November 2024) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔹 SDMI & ZDO Zwang: SAP macht die Regeln strenger. Ein neues S/4HANA Feature-Pack kann über den SUM (insbesondere via ZDO) erst dann installiert werden, wenn alle SDMI-Klassen des vorherigen Releases zu 100 % erfolgreich abgeschlossen wurden. Die Transaktion
SDM_MONmuss "grün" sein, sonst stoppt der SUM in der PREP-Phase!
Fazit für Basis Architekten
Die Silent Data Migration (SDMI) ist ein architektonisches Meisterstück zur Entzerrung von Upgrades. Es verschiebt die "schwere Arbeit" der Datenbankschicht geschickt in die Uptime, in Zeiten geringer Systemlast (z.B. am Wochenende nach dem Upgrade). Für uns Basis-Administratoren bedeutet das: Ein Upgrade ist am Montagmorgen nicht abgeschlossen, wenn die User sich wieder einloggen. Das Monitorung des SDM_USER und die Überwachung der Batch-Ressourcen in der Post-Upgrade-Phase werden zur neuen Kernkompetenz im Cloud-ERP-Zeitalter.