Endlich: das eigentliche Update des SAP-Systems wird nun mit SUM durchgeführt. SUM durchläuft dabei verschiedene Phasen, wie EXTRACTION, CHECKS, PREPARE, EXECUTE...
Die von SUMSTART angezeigte URL aufrufen, z.B.
https://<server>:1129/lmsl/sumabap/<sid>/slui/
Zuerst wird die Stack-XML-Datei aus dem Installationsverzeichnis angegeben. SUM findet daraufhin das Installationsverzeichnis und packt die Dateien aus.
Hier wird das Update konfiguriert. Die meisten Angaben sind bereits sinnvoll voreingestellt. Die Pfade zu den Packages sind bereits korrekt. Scrollt man in den entsprechenden Dialogen nach unten, sieht man die einzelnen Packages mit Available gekennzeichnet. Ist dies nicht der Fall, wird dort Still missing ausgegeben. Dann muss man den Pfad korrigieren.
Angaben zu Anzahl von Upgrade-Prozessen usw. kann man getrost übernehmen.
Keine Datenbank-Migration auswählen!
Am Schluß erhält man eine Übersicht über die zu aktualisierenden Komponenten.
Hier werden mehrere Prüfungen vorgenommen. Eventuell erhält man eine Liste mit Transportaufträgen, die vor dem Upgrade freigegeben werden sollen, da sie Objekte enthalten, die vom Upgrade betroffen sind.
Es kann eine Aufforderung erscheinen, fehlende Hinweise einzuspielen.
Falls inactive Objekte gefunden werden, die sich nicht aktivieren lassen, können das Relikte alter Transporte sein.
Mit Report RS_WORKING_AREA_CONSISTENCE können diese gelöscht werden.
Nun sollten alle Jobs für das Update suspendiert werden:
Transaktion SA38 - Report btctrns1
Die Datenbank-Protokollierung sollte ausgeschaltet werden, damit die Filesysteme nicht vollaufen.
Im MS SQL-Server stellt man in den Eigenschaften - Optionen der Datenbank das Recovery Model auf Simple.
In der HANA-Datenbank ändert man in den Einstellungen (HANA Studio oder Transaktion ST04) in den INI-Dateien (Administration) unter Persistent den log_mode von normal auf overwrite.
Nach dem Upgrade muss das wieder rückgängig gemacht werden.
Nun beginnt die eigentliche Downtime und das vorbereitete Update wird durchgeführt. Hier sollten außer der Bestätigung für die Sperrung der Entwicklungen und der Downtime keine weiteren Eingaben oder Handlungen mehr erforderlich sein.
Das Verhalten bei PREPROCESSING und EXECUTION, die Länge der Downtime und der Platzverbrauch auf der Datenbank sind abhängig von der Upgrade-Methode, die man gewählt hat (mit oder ohne Schatteninstanz).
Filesysteme und Datenbank werden aufgeräumt.
Die Datenbank-Protokollierung muss wieder eingeschaltet werden, die SAP-Jobs wieder eingeplant (SA38 - btctrns2), ebenso die Backup-Jobs.