SAP Software Update Manager Approaches im Überblick

(Last Updated On: 2. März 2019)

Der Software Update Manager (SUM) liefert neben der klassischen Upgrade-Funktionalität mittlerweile eine Vielzahl an unterschiedlichen Approaches für die Kombination aus Upgrade und Migration bzw. die System Conversion. Ziel der verschiedenen Verfahren ist häufig die Reduzierung der Business Downtime, wobei die verschiedenen Approaches unterschiedliche Ansätze verfolgen und daher verschiedene Schwerpunkte verfolgen.

In diesem Beitrag liefere ich einen kurzen Überblick über die verschiedenen Downtime-optimierten Approaches des Software Update Manager, die Szenarien in welchen sie eingesetzt werden können und wie sie funktionieren.

SUM DMO, ZDO, nZDM und NZDT Overview

Die folgende Tabelle zeigt zunächst die verschiedenen Herangehensweisen, die Upgrade-Szenarien, für welche sie verfügbar sind, die Verfügbarkeit und die zentrale SAP Note dazu.

ApproachAbkürzungverfügbare SzenarienVerfügbarkeitSAP Hinweis
near-Zero Downtime Maintenance (für den ABAP Stack, nicht zu verwechseln mit nZDM für HANA)nZDM– Update (SPS Update für ein System basierend auf NW 7.0 EHP2 oder höher, einschließlich S/4HANA)
– Upgrade
+ (EHP Upgrade für Business Suite System basierend auf NW 7.0 EHP2 oder höher
+ Upgrade eines Legacy Systems auf einen Releasestand basierend auf NW 7.0 EHP3 oder höher, z. B. von R/3 4.6c nach ECC 6.0 EHP6)
+ Upgrade von einem älteren S/4HANA Innovation Release auf einen neueren, z. B. von 1511 nach 1809.
+ Einspielen eines S/4HANA Feature Pack Stack
+
Generally Available1678565, 1678564
Zero Downtime OptionZDOUpdate / UpgradePilot (Partnerschaft mit SAP, vielleicht später GA)2163060
downtime-optimized Database Migration Optiondo-DMOMigration auf HANA + Upgrade
Pilot (Partnerschaft mit SAP, vielleicht später GA)
2442926
Database Migration OptionDMOMigraiton auf HANA + UpgradeGenerally availableSUM-spezifisch, z. b.
2631152 (SUM 2.0 SP03)
Downtime-optimized conversionConversion to S/4HANA
Pilot (Partnerschaft mit SAP, vielleicht später GA)
2293733
normale System ConversionConversion to S/4HANA
near-Zero Downtime Maintenance (Java)nZDM JavaUpdate / Upgrade Java Stack
Pilot (Partnerschaft mit SAP, vielleicht später GA)
2422909
Near Zero Downtime TechnologyNZDTUpgrade / Update (ABAP)
Conversion to S/4HANA
Service-based (buchbar mit SAP)693168

Grundlegende Funktionsweise der SUM Schatteninstanz

Bereits die gewöhnliche Upgrade-Funktionalität des Software Update Managers besitzt die Fähigkeit, die Downtime eines Upgrades zu funktionieren. Damit wir die Benefits der anderen Approaches verstehen, ist es notwendig, die Funktionalität der Schatteninstanz im Ansatz zu verstehen.

Wenn Sie ein Upgrade ohne Schatteninstanz durchführen, bedeutet das eine längere Downtime. Denn ohne Schatteninstanz müssen alle Anteile des Upgrades auf den produktiven Tabellen erfolgen. Ich verusche die Erklärung zunächst über den Ansatz aus diesem offiziellen SAP Blog.

Ohne Schatteninstanz müssen die Renovierungsarbeiten in dem selben Haus durchgeführt werden, in dem Sie wohnen.


Wenn Sie sich hingegen für den Aufbau einer Schatteninstanz entscheiden, bauen Sie vor den eigentlichen Renovierungsarbeiten ein zweites Haus auf, während Sie immer noch in Ihrem aktuellen Haus wohnen bleiben.

Unrealistisches Szenario, sagen Sie? Nun, der Aufbau eines zweiten Hauses könnte Sie tatsächlich teurer kommen, also einfach mal für ein paar Monate bei den Eltern einzuziehen, das gebe ich zu. Gott sei Dank bezieht sich unsere Analogie aber auf ein digitales Szenario. Hierbei kopiert der Software Update Manager Tabellen und Indizes in der Datenbank. Wenn Sie die Summe der SAP Datenbanken als „Repository“ bezeichnen, kopiert sich der Software Update Manager ein „Shadow Repository zusammen“. Der Software Update Manager kopiert hierzu Tabellen und Indizes. Diese sind häufig daran zu erkennen, dass Sie hinter dem eigentlichen Namen der Original-Tabelle ein Suffix drangehängt wird (z. B. zwei Tilden ~~ oder der Zusatz .SHD am Ende des Tabellennamens). Diese Kopien sind aber in der selben Datenbank und im selben Datenbankschema wie das Originalsystem, deswegen müssen Sie auch anders heißen, damit es hier nicht zu Namenskonflikten kommen.

Selbstverständlich kostet Sie auch der Aufbau der Schatteninstanz etwas. Zum einen benötigt es einige Zeit, bis das zweite Haus gebaut ist. genau so benötigt es auch einige Zeit, bis die Schatteninstanz durch Kopien der Original-Tabellen aufgebaut ist. In erster Instanz verlängert der Aufbau Ihres Schatten-Hauses bzw. Ihrer Schatteninstanz also erst einmal die Zeit der Renovierung bzw. der Migration.

Ein weiteres Problem ist, dass der Aufbau Ihres Schattenhauses Sie nicht nur Zeit kostet, sondern auch Ressourceneinsatz (in Form von Ziegeln, Beton usw.) und damit Geld. Bei der Schatteninstanz „zahlen“ Sie diese Ressourcen in der Form der technischen Systemressourcen. Denn das System muss jetzt zusätzlich zur produktiv genutzten SAP Instanz zusätzlich eine Schatteninstanz betreuen. Das beeinträchtigt ein wenig die Performance – jedoch ist dies in der Praxis häufig nicht oder nur zu Spitzenzeiten für den Anwender spürbar. Nachdem das Schattenrepository nämlich aufgebaut ist, können Sie sch an der Schatteninstanz anmelden. Im SAP Logon geben Sie dazu die selbe System-ID, aber eine andere Instanznumer ein.

Wie Sie sehen, ist die sogenannte Schatteninstanz nicht gleichzusetzen mit einer klassischen „Dialoginstanz“. Denn wenn Sie mehrere Dialoginstanzen eines Systems haben, greifen diese trotzdem immer auf die gleichen Tabellen, also auf das gleiche Repository, zu.

die Schatteninstanz hingegen greift explizit auf die Schattentabellen im Schatten-Repository zu, ist also logisch vom Original-Repository abgetrennt. Ein zweites Haus eben, welches auf einem vollkommen anderen Fundament steht. Das Schattenrepository installiert zunächst die Standard DDIC-Objekte des Zielreleases aus dem sogenannten „Upgrade Export“ und überführt dort im Anschluss (durch Zauberei mit Hilfe der SPDD) die kundeneigenen Veränderungen an diesen Standard DDIC Objekten. Des Weiteren werden kundeneigene DDIC Objekte im Kundennamensraum überführt. Nun haben Sie ein komplettes Schatten-Repositorys Ihres Quellsystems, nur halt eben im Zielrelease, so weit wie der Upgrade Export dies möglich macht. Es kann notwendig sein, dass im Anschluss daran noch über R3trans diverse Pakete importiert werden. Das sind dann quasi alle Support Packages, die nicht im Upgrade Export enthalten waren.

So, anstatt nun die Renovierung auf Ihrem Original-Haus durchzuführen, führen Sie die Renovierungsarbeiten auf Ihrem Schatten-Haus durch. Sie haben initial Zeit und Ressourcen investiert, dieses zweite Haus aufzubauen, profitieren jetzt aber von dem Vorteil, dass Sie so lange in Ihrem alten Haus weiter wohnen können, bis die eigentlichen Renovierungsarbeiten am Schattenhaus abgeschlossen wurden. Der einzige Zeitraum, in welchem Sie nun „wohnungslos“ sind, ist der verhältnismäßig kurze Zeitraum des Umzuges, in welchem Sie Ihre Möbel und Habseligkeiten vom alten in das neue Haus verschieben. Die Abbildung illustriert das.

Sie haben außerdem einen weiteren Vorteil gewonnen: Wenn Ihnen das neue Haus nicht gefällt, können Sie sehr einfach auf den Ursprungszustandes Ihres Originalhauses zurückwechseln, indem Sie wieder zurück in das alte Haus umziehen. Natürlich nur, solange sie es noch nicht eingerissen haben.

Genau die gleichen Vorteile gewinnen Sie bei der Schatteninstanz im Software Update Manager. Dadurch, dass das Upgrade zunächst nur über die Schatteninstanz durchgeführt wird, können Sie bis zu einem gewissen Punkt jederzeit zurück gehen, ohne ein Backup machen zu müssen. Der einzige Unterschied beim Software Update Manager ist der, dass Sie grundsätzlich nicht mehr ohne ein Backup zurück können, sobald Sie in die Downtime gegangen sind, also in dem Moment, an dem Sie ausziehen. Grund: Die Datenstruktur hat sich möglicherwiese geändert. Das wäre ungefähr so, als hätten Sie für Ihr neues Haus die Couch und die Küchengarnitur ein bisschen zuschneiden müssen, damit sie in die neuen Raummaße hinein passen.

Neben der Migration der Bewegungsdaten passiert noch einiges mehr in der Downtime Phase, etwa das Einspielen von Paketen über R3trans. Denn es werden nicht nur Stamm- und Bewegungsdaten, sondern auch DDIC Objekte übertragen, die noch nicht im Ziel Repository des heruntergeladenen Upgrade Exports im Zielrelease enthalten waren. Man spricht vom sogenannten „Shadow Import“. Daher die Abbildung bitte nicht zu genau nehmen.

near-Zero Downtime Maintenace (nZDM)

Wie funktioniert nun die near-Zero Downtime Maintenance im Verlgeich zu unserem obigen Beispiel? Bei der near-Zero Downtime Maintennace ist der „Umzug der Möbel“, also im technischen Jargon der „Shadow Import“, in der Uptime, sprich im Live-Betrieb möglich. Wie dürfen wir uns das vorstellen? Nun, das wäre ungefähr so, als wenn Sie während der Renovierungsarbeiten Änderungen an Ihren Möbeln im Original-Haus vornehmen würden (Neue Möbel hinzufügen, Möbel entsorgen, Möbel zuschneiden und umstellen) und diese Änderungen gleichzeitig im Schattenhaus repliziert werden würden. Das heißt, in Ihrem alten Haus schaut ständig jemand zu, was Sie gerade machen, und ruft beim Handwerker im Schattenhaus aus, um ihm zu sagen, was er ändern soll.

Vorteil der ganzen Sache: Weil die von Ihnen gewünschten Möbel schon im neuen Haus drin sind, müssen Sie eigentlich nur noch sich selbst in das neue Haus verfrachten (alles Andere ist ja schon da) und Ihre Adresse ändern. Genau so muss es auch unser SAP System tun. Das System muss jetzt am Ende nur noch die Tabellen umbenennen, und Sie als User müssen sich danach im neuen System einloggen.

Jetzt werden Sie mir aber sagen: „Andreas, du spinnst ja.“ Wenn ein Handwerker dem anderen sagt, er soll das und das machen, sieht das doch unmöglich so aus, wie beim ersten Handwerker. Die beiden arbeiten ja ganz unterschiedlich, und wenn die nur eine Schraube oder einen Dübel anders setzen, sieht die Couch im Schattenhaus doch ganz anders aus als die im Originalhaus. Genau das war der Grund, warum im klassischen Upgrade-Verfahren diese Replikation nicht implementiert und die Downtime länger war. Hat sich im SAP System beispielsweise das Datenmodell geändert, ist das gleichzusetzen mit zwei unterschiedlichen Handwerkern.

Jetzt gibt es aber im digitalen Umfeld die Möglichkeit, Änderungen „aufzunehmen“. Das heißt die Schritte, die der erste Handwerker durchgeführt hat, werden haargenau aufgezeichnet und danach 1:1 repliziert.Im Endeffekt ersetzen wir unsere fehlerbehafteten Handwerk durch eine Produktionsstraße bestehend aus CNC-Fräse und Montagroboter, die genau das machen, was man ihnen vorher einprogrammiert hat. nZDM nennt dies „Record & Replay“. Wenn wir jetzt von unserer einfachen Skizze weg gehen und etwas technischer werden, sieht das Ganze so aus

Funktionsweise des nZDM Change Recordings

Kernbestandteil der near-Zero Downtime Maintenance ist das osgenannte Change Recording bzw. die Record & Replay Technique. Wie bei einem gewöhnlichen Upgrade mit optimierter Downtimephase wird eine Schatteninstanz aufgebaut.

Änderungen, beispielsweise an Bewegungsdaten, werden aufgezeichnet und vom Software Update Manager in einem Change Recorder festgehalten. In der Schatteninstanz werden die Änderungen dann im neuen Datenmodell wiederholt. Man kann sich das so vorstellen, als würde die Transaktion komplett neu aufgerufen und die zu übertragenen Werte neu in den Transkationsbildschirm eingegeben werden. Daher spielt das Datenmodell im Zielrelease eine untergeordnete Rolle.

Sie können die Datenübertragung auf der Schatteninstanz über die Transkation CRR_CONTROL kontrollieren, pausieren und starten. Sie können sogar, um die Migrationszeit weiter zu reduzieren, bewusst Tabellen von der Datenreplikation ausschließen. Dies führt freilich die Dateninkonsistenzen im Vergleich zum Ursprungssystem, die Sie bewusst in Kauf nehmen müssen.

In der ursprünglichen Implementierung der Record & Replay Technik war das System zwar beinahe die ganze Upgrade-Prozedur lang online, dafür hat das Übertragen von sehr großen Tabellen mit zahlreichen Änderungen mehrere Tage und teilweise Wochen gedauert. Diese Zeiten verringern sich drastisch beim Einsatz einer bestimmten dbsl Version. Hierzu muss allerdings auf dem Quellsystem folgender Kernel enthalten sein:

  • Kernel 7.45 PL 725
  • Kernel 7.49 PL 513
  • Patches für neuere Kernel, etwa den 7.53er, sind aktuell in der Entwicklung. Der aktuelle Stand der Patches wir din SAP Note 2591334 bekannt gegeben.

explizit nicht unterstützte Szenarien

Explizit nicht unterstützte Szenarien für near-Zero Downtime Maintenance (nZDM) sind:

  • ein Upgrade in Verbindung mit einer Unicode Conversion (Combined Upgrade and Unicode Conversion, CUUC) – SAP Note 928729.
  • jegliches Update / Upgrade in einem Quellsystem mit DB2 for LUW Datenbank, wenn das database partitioning feature (DPF) genutzt wird.

Database Migration Option (DMO)

Bewegen wir uns nun einmal weg vom klassischen System Upgrade und nehmen wir die Databse Migration Option (DMO) unter die Lupe. Eine DMO kombiniert eine heterogene Systemkopie (also eine Migration) von einer beliebigen AnyDB nach SAP HANA (oder alternativ für bestimmte Releases nach SAP ASE) und gleichzeitig ein Upgrade. Unter bestimmten Voraussetzungen kann zusätzlich zur Migration und zum Upgrade auch noch zeitgleich eine Unicode Conversion von statten gehen (aber nur wenn der Zielkernel 7.40 ist, für 7.50 geht das leider nicht). Mehr dazu in meinem Beitrag zum Thema Unicode Conversion.

Grob skizziert sieht eine Database Migration Option folgendermaßen aus.

Wie funktioniert die DMO jetzt im Vergleich zum weiter oben kennen gelernten klassischen Upgrade-Prozedere mit Schatteninstanz? Bis kurz vor der Downtime läuft alles gleich. Die Schatteninstanz wird zunächst ganz normal auf der Quelldatenbank (in unserem Fall also auf der Oracle 12 Datenbank) im selben Datenbankschema aufgebaut.


Gleichzeitig wird allerdings noch während der Uptime das Schattenrepository von der Quelldatenbank (unserer Oracle 12) auf die Zieldatenbank kopiert (auf die HANA Datenbank). Dieses Kopieren geschieht über R3load. Das R3load des Oracle-Zielkernels exportiert, das R3load des HANA-Zielkernels importiert. Das heißt, das Schatten-Repository ist nun einmal auf der Quelldatenbank und einmal auf der Zieldatenbank vorhanden.

Das Schattenrepository, und somit alle DDIC Objekte aus dem Upgrade Export im Zielrelease – inklusive der Anpassungen durch die SPDD, sind nun bereits auf der HANA Datenbank vorhanden. Sie haben aktuell also einen fast nackten Zielrelease auf Ihrer HANA (in unserem Beispiel einen fast nackten SAP BW 7.5), mit einigen kundeneigenen Anpassungen in den Repository Objekten. Sie haben nun, wie bei einem normalen Upgrade, noch die Downtime-Phase vor sich, in welcher der Shadow Import durchgeführt wird. Bevor dieser Shadow Import beginnt, schwenkt das SAP System die Datenbankverbindung um auf die HANA Datenbank – die Schatteninstanz existiert zu diesem Zeitpunkt schon nicht mehr.

Sie haben vielleicht schon richtig erkannt, dass wenn nun vor dem Shadow Import schon der Schwenk auf die HANA Datenbank passiert, der Shadow Import auf der Oracle Datenbank gar nicht erst durchgeführt wird. Und Sie haben Recht. Deswegen können Sie im Fall der Fälle, wenn das Upgrade fehl, einfach den NetWeaver Kernel und dessen Profildateien von vor der Downtime zurückkopieren und zurück auf die alte Datenbank (Oracle) schwenken. Dann haben Sie automatisch wieder den Stand von vor der Downtime drin, ohne dass Sie ein Backup in der Datenbank einspielen mussten. Das heißt auch der Fallback auf den alten Release funktioniert schneller als bei der klassischen Vorgehensweise. Zwar haben Sie noch die Schattentabellen das Schatten-Repositorys in der Datenbank, die kriegen Sie aber über einen Reset des SUM wieder raus.

Wenn nun die Downtime einsetzt, wir der eigentliche Shadow Import auf der HANA Datenbank durchgeführt. Der Software Update Manager überträgt die Daten und Pakete per R3load bzw. R3trans direkt an die HANA Datenbank und führt währenddessen gleichzeitig die Konvertierung der Quelldaten vom Oracle-Quellformat in das HANA-Zielformat durch. Zum Schluss geschieht das gleiche wie beim normalen Upgrade auch: Das Shadow Repository wird umbenannt, der NetWeaver Kernel wird ausgetauscht, und das System startet im neuen Zielrelease.

Was ist jetzt der Vorteil von der DMO, ist die Downtime des Upgrades schneller? Nein, das ist wichtig zu verstehen. Die Downtime des Upgrade auf das Zielrelease ist wahrscheinlich länger als bei einem Single System Upgrade, weil Sie die Daten der Downtime nun über das Netzwerk an einen externen Host (in unserem Fall Server 2) übertragen müssen.

Der Vorteil der DMO ist, dass Sie nur eine einzige Downtime haben, weil Sie nämlich das Release Upgrade und die (davor oder danach erfolgende) Systemkopie vereinen. Ansonsten bräuchten sie nämlich eine zweite Business Downtime für die Systemkopie. Wenn Sie sogar noch eine Unicode Conversion kombinieren, sparen Sie hier noch einmal ein wenig Business Downtime.

Downtime-optimized Database Migration Option (DMO)

So, jetzt kommen wir zum ersten mal an eine Stelle, an der ich relativ wenig über eine Herangehensweise des Software Update Managers sagen kann, denn dieser Approach ist derzeit in der Pilotphase und ist daher grundsätzlich erst einmal nur auf Anfrage mit der SAP selbst durchführbar. Sie müssen sich dazu als Kunde mit Ihrem Projekt bewerben. Die Details dazu entnehmen Sie der Not 2442926 – Prerequisites and Restrictions of downtime-optimized DMO .

Jedoch kann ich persönlich eine Vermutung äußern. Meiner Ansicht nach kombiniert die downtime-optimized DMO höchstwahrscheinlich den Ansatz der DMO mit dem Change Recording der near-zero Downtime Maintenance (nZDM). Die technische Umsetzung scheint jedoch auf einer trigger-basierten Replikation zu basieren, wie Sie auch beim SLT zum Einsatz kommt. Dazu habe ich in der Vergangenheit hier schon einmal etwas geschrieben. Das heißt Sie kombinieren im Endeffekt die beiden Ansätze. Das wird im Endeffekt die Magie hinter der ganzen Sache sein, was im Endeffekt bedeutet, dass Sie während des Shadow Imports Datenbewegungen sowohl auf Ihrer Oracle- als auch auf der HANA-Datenbank haben.

Dieses Szenario ist nur freigegeben für die beiden Produkte SAP ECC 6.0 und höher und SAP CRM 7.0 und höher, und Sie können die downtime-optimized DMO nicht verwenden, wenn Sie zusammen mit der DMO den Application Server auf einen anderen Host umziehen wollen (das können Sie jedoch natürlich nachträglich machen, indem Sie eine Instanz über den SWPM nachinstallieren).

Da die Option derzeit in einer Pilotphase steckt, wissen wir noch nicht, ob sie irgendwann Generally Available (GA) sein wird. Meiner Meinung nach ist dies jedoch sehr wahrscheinlich.

klassische S/4HANA System Conversion

Die klasse S/4HANA System Conversion gibt es auf zwei Arten. Mit Database Migration Option (wenn das Quellsystem noch auf AnyDB läuft und noch nicht auf SAP HANA) oder ohne DMO (wenn das Quellsystem bereits auf SAP HANA läuft). Im Endeffekt heißt das

  • wenn Ihr Quellsystem auf AnyDB ist, machen Sie eine DMO (da der Zielkernel unter S/4 aber >=7.50 ist, können Sie in der DMO keine Unicode Conversion mit machen)
  • wenn Ihr Quellsystem auf HANA ist, machen Sie ein klassisches Upgrade (wie ganz oben als erstes skizziert)

Mit einem feinen Unterschied. Die Phasen des Software Update Managers sind bei einer S/4HANA System Conversion größtenteils gleich im Vergleich zu einem klassischen Business Suite Upgrade. Im Gegensatz zu einem klassischen Business Suite Upgrade kommt bei einer S/4HANA System Conversion jedoch eine Datenkonvertierung im Postprocessing dazu. Mindestens für die Bereiche FI/CO (das ist der Schwenk auf das Universal Journal – ACDOCA) und für den Material Ledger (das ist der Switch auf die MLDOC). Informationen über die Hintergründe finden Sie in meinem Beitrag zum Universal Journal.

Ein Teil dieser Datenkonvertierung geschieht während der technischen Downtime, ein Teil als Nacharbeit während der technischen Uptime (jedoch immer noch während der Business Downtime, da Sie vor abgeschlossener Konvertierung das System nicht freigeben dürfen). Und einen nicht unerheblichen Teil müssen Sie in Form von Vorarbeiten vorbereiten, sonst funktioniert das Ganze sowieso nicht.

Downtime-optimized Conversion

Wie schon die Downtime-optimized DMO ist auch die Downtime-optimized Conversion ein Pilotprojekt der SAP. Auch hier müssen Sie sich mit Ihrem Projekt zuerst bewerben. Mehr dazu erfahren Sie in der SAP Note
2293733 – Prerequisites and Restrictions of downtime-optimized conversion to SAP S/4HANA. Meine Vermutung ist, dass es sich hier im Endeffekt um eine S/4HANA System Conversion in Verbindung mit einer downtime-optimized DMO handelt. Erneut werden hier also bereits gegebene Strukturen miteinander verknüpft.

Zero Downtime Option (ZDO)

Auch die ZDO ist derzeit nicht Generally Available, sondern nur über einen Piloten in Zusammenarbeit mit der SAP verfügbar. Für Restriktionen und Informationen zur Anmeldung konsultieren Sie SAP Note 2707731. Die Zero Downtime Option heißt Zero Downtime Option, weil es keine technische Downtime gibt. Eine Business Downtime, in welcher das System isoliert, nachbearbeitet und getestet werden muss, gibt es allerdings immer noch.

Die Zero Downtime Option funktioniert ganz anders als wir es bisher kennen gelernt haben. Ich erkläre es wieder mit unserer bisherigen Analoge. Anstatt unser Haus zu klonen und auf dem Klon die Renovierungsarbeiten durchzuführen, erstellen wir stattdessen einen minimalen Klon unseres Hauses (auf dem nur die notwendigsten Räume existieren, also z. B. Wohnzimmer, Küche, Schlafzimmer und Bad. Die restlichen Räume werden „nicht kopiert). Und während in unserem Original-Haus die eigentlichen Wartungsarbeiten durchgeführt werden, ziehen wir in unser „Mini-Haus“ um und wohnen derweil dort.

Und genau das passiert bei der Zero Downtime Option. Anstatt das Original-Repository vollständig in ein Shadow Repository zu klonen und auf dem Shadow Repository das Update durchzuführen, werden nur die wichtigsten Tabellen in ein komplett neues Datenbankschema kopiert. Auf diesem zweiten Datenbankschema (genannt „Bridge“) sind alle Tabellen, die gebraucht werden, um die wichtigsten Business- und Schnittstellen-Funktionalitäten zu halten. Ab dem Punkt, wo auf dem Original-Datenbankschema die Downtime initiiert wird, werden die User (ohne es zu merken) auf das kopierte Schatten-Datenbankschema umgeleitet und arbeiten auf diesem weiter.

Am Ende der Downtime auf dem Haupt-Datenbankschema werden die erzeugten Daten auf der Bridge dort hin übertragen, und die User arbeiten irgendwann wieder (ohne es wirklich zu merken) auf dem ursprünglichen Schema.

Aufgrund dieser technischen Funktionsweise der ZDO ist diese jedoch nicht für alle Upgrade-Vorhaben verfügbar. Ein Quellrelease von SAP S/4HANA 1709 FPS02 oder höher und eine SAP HANA 2.0 Datenbank mit SPS02 oder höher wird benötigt. Die ZDO wird sehr gerne für SAP S/4HANA Support Package Stack Updates verwendet.

Near-Zero Downtime Technology (NZDT) bzw. Minimzed Downtime Service (MDS)

Bei diesem Approach handelt es sich um ein Paket aus Beratungsdienstleistungen der SAP, welche für zahlreiche Upgrades verwendet werden knnen. Hierbei bekommen Sie im Endeffekt ein Paket, dessen Bestandteil auch die Optimierung der Downtime beinhaltet.

Möglich ist, dass zum einen die weiter oben vorgestellten Approaches angeboten und durch technische Optimierung ergänzt werden, zum anderen aber beispielsweise auch Services wie ein Upgrade mit einem geklonten System angeboten werden könnten. Das heißt das eigentliche Upgrade machen Sie auf einem Klon des Produktivsystems (während dieses wiederum weiterhin produktiv verwendet wird), und nach dem Upgrade holen Sie sich das Delta vom Originalsystem über eine transformationsfähige Replikationstechnologie. Das ist jedoch wieder nur eine Vermutung meinerseits, eine wirkliche Bestätigung bekommen Sie nur vom Hersteller selbst.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.