DSAG-Vortrag zum Thema SUM

Im März fand ein Vortrag der DSAG zum Thema Software Update Manager (SUM) statt – speziell zur Downtime-Optimierung. Wir fassen kurz zusammen:

Mit dem Support Package 10 für den SUM 2.0 hat die downtime-optimierte S4-Conversion die Pilotphase verlassen und ist jetzt in die General Availability übergegangen. Neben den technischen Voraussetzungen, ist eine weitere, dass am Projekt mindestens eine beteiligte Person für die Conversion zertifiziert ist und zusätzlich den Kurs ADM329 besucht hat.

Die Zero-Downtime-Option ist weiterhin nur auf Anfrage, in Zusammenarbeit mit SAP, erhältlich. Grob kann man sagen, je kürzer die Downtime werden soll, desto größer der Aufwand des Projekts. In vielen Fällen kann die SAP über ZDO die Downtime auf einen Reboot des Systems beschränken. Dafür sind komplexe Analysen des Systems erforderlich, die dann im Vorfeld aber bereits den Speicherbedarf für das Upgrade ermitteln, sowie mögliche Einschränkungen, die während des Upgrades entstehen können.
Das Vorgehen unterscheidet sich vom bekannten Aufbau einer Schatteninstanz. Es wird eine sogenannte Bridge aufgebaut. Das heißt, die für das Business wichtigsten Tabellen werden unter temporärem Namen kopiert und darauf werden die Benutzer im Rollover umgeleitet. Der SUM arbeitet währenddessen auf den Originalen. Hierbei kann es nun drei Konstellationen von Änderungen geben:

1. Der SUM muss eine Tabelle nicht ändern. Dann verwendet die Bridge die Originaltabelle des SUM für Lese- und Schreiboperationen.
2. Der SUM muss eine Tabelle ändern. Es gibt eine Clone-Tabelle für die Bridge. Via DB trigger werden Bridge und Original synchronisiert.
3. Der SUM muss die Tabelle exklusiv ändern. Die Bridge kann nur lesend zugreifen.

Der letzte Punkt wird in der Analyse aufgezeigt und kann, je nach Tabelle, zum Problem für das Business werden.
Es gibt aktuell keine ZDO-Varianten (Zero Downtime Option), die ein Release überspringen, es geht immer nur das nächsthöhere Release.

HANA 1.0 kann problematisch werden für ZDO, da sie Singleton-Schemas enthalten kann (z. B. _SYS_BIC), die können in einer Datenbank immer nur einmalig vorhanden sein. Die müssten vorab in HDI-Container umgezogen werden. Auch das wäre ein Ergebnis der anfänglichen Analyse.

Fazit:

Wir sehen also, es ist einiges in Bewegung im Bereich Software Lifecycle Management und die SAP bemüht sich auch Kunden mit sehr zeitkritischen Systemen eine realistische Möglichkeit zu geben, von Korrekturen und Neuerungen zu profitieren.