Optimierung der Conversion / Migration Performance

(Last Updated On: 8. Juli 2019)

In diesem Beitrag geht es um die Optimierung der Business Downtime bei einem Ugprade oder einer Migration. Dies ist ein lebender Beitrag, der hin und wieder mal aktualisiert wird. Ich habe versucht, in dieser ersten Version nun relativ viele Maßnahmen unterzubringen, um eine solide Grundlage zu bilden. Aktuell fehlen noch in diesem Beitrag vor allen Dingen Empfehlungen für die load-basierte Systemkopie, die ich später hinzufügen werde.

Sie finden in diesem Beitrag eine Sammlung von Tipps. Viele davon stammen aus offiziellen SAP Blogs und aus SAP Hinweisen, die ich entsprechend als Quelle verlinke. Dadurch ist quasi ein Nachweis der „Legitimität“ dieser Optimierungsmaßnahmen gegeben, so dass Sie hier keine Experimente eingehen und Ihr Upgrade eher verschlimmbessern.

Inhaltsverzeichnis

Approach-übergreifende Performance Maßnahmen

Die hier gelisteten Maßnahmen sind gültig, völlig unabhängig davon, ob Sie ein Upgrade, eine Systemkopie, eine DMO oder eine System Conversion vor haben. Sie helfen Ihnen in allen Lebenslagen und sollten daher in jedem Upgrade- und Migrations-Projekt angewandt werden.

sauberes Sizing von Quell- und Zielsystem

Erster Schritt für gute Performance in SAP Upgrade- und Migrations-Projekten ist ein sauberes Sizing der Systeme, auf denen die zu wartenden Systeme installiert werden bzw. wohin sie migriert werden. Ich habe sowohl grundsätzlich über den SAP Quick Sizer als auch über das Sizing unter SAP HANA bereits entsprechende Beiträge veröffentlicht. Außerdem, wenn Sie zusammen mit beispielsweise einer DMO eine Unicode Conversion durchführen, habe ich Ihnen hier aufgezeigt, welche zusätzlichen Ressourcen Sie nach einer Unicode Conversion einkalkulieren sollten.

Zusätzlich liefert die SAP hin und wieder Hinweise für bestimmte Zielreleases aus, welche aufzeigen, welchen Zuwachs an Ressourcen ein bestimmter Release bei SAP Kunden verursacht hat. Für SAP ERP 6.0 EHP 7 und 8 ist das beispielsweise die Note 1974405 – Resource requirements for SAP ERP Central Component 6.0 EHP7 and EHP8.

Für ein SAP S/4HANA Zielrelease gibt es eine solche Note derzeit noch nicht. Die Message, die sich dahinter verbirgt: Wenn ein SAP ERP Anwendungsserver bei dir läuft, läuft auch ein S/4HANA Anwendungsserver bei dir (meine Worte, nicht die offiziellen der SAP).

Datenvermeidung und Datenbereinigung

Der folgende Abschnitt schildert Maßnahmen zur Vermeidung und Berienigung von Daten. Klar ist: Je kleiner das System, desto kürzer das Upgrade bzw. die Migration. Deswegen sind diese Strategien ein wesentlicher Bestandteil der Optimierung.

Unter Oracle als Quelldatenbank gibt es den Hinweis 2388483 – How-To: Data Management for Technical Tables , der sich auch mit der Vermeidung von Datenwachstum in Basis-Tabellen beschäftigt.

Wenn Sie den CRM Marketing Segment Builder nutzen, können Sie zur Reduzierung der Downtime Zielgruppen aus dem System löschen. Daraufhin baut bei einem Upgrade oberhalb von NW 7.40 SP08 einen Sekundärindex auf die dadurch betroffene Tabelle CRMD_MKTTG_TG_I Tabelle während des Upgrades neu auf. Dieser Neuaufbau dauert natürlich seine Zeit. Dieser Schritt ist notwendig und kann daher nicht übersprungen werden. Als Daumenregel benötigt der Wiederaufbau dieses Index für 10 Millionen Einträge etwa 200 Sekunden Zeit. auf moderner Hardware. Je mehr Target Groups Sie also im Vornherein löschen können, desto niedriger die Downtime an dieser Stelle.

Housekeeping ist im SAP BW System nochmal ein ganz eigenes Thema. Zunächst sollten Sie prüfen, ob SAP Note 2026343 auf Sie zutrifft.

Transaktion DB02 – fehlende Tabellen und Indizes

Sie sollten auf jeden Fall in der DB02 den Punkt „fehlende Tabellen und Indizes“ nachziehen. Nicht nur verbessern die Indizes die Selektion der Daten, dieser Punkt verhindert auch eventuelle Abbrüche in der Vorbereitungsphase des Software Update Manager

Nutzen Sie einen aktuellen Kernel und die SPAM im Quell- und Zielrelease

Damit ist gemeint, dass Sie auf dem Quellrelease (z. B. SAP Netweaver 7.31) einen möglichst aktuellen Kernel mit hohem Patchlevel verwenden sollen. Insbesondere sind hierbei wichtig die folgenden Komponenten des Kernels

  • dbsl (Database shared Library)
  • tp
  • die sogenannten R3*Tools (R3load, R3trans, usw.)
  • Die BR*Tools (hauptsächlich, weil veraltete BR*Tools nicht mit neueren R3*Tools kompatibel sind)

Für das Zielrelease sollten Sie bei der Planung der Wartung mit dem Maintenance Planner einen möglichst aktuellen Kernel zum Download auswählen. Im Zweifel können Sie sogar während der SUM-Prozedur die dbslib und die R3*Tools noch austauschen. Bei einer Database Migration Option etwa, bei welcher Sie von einem NetWeaver 7.31 auf einer Oracle Datenbank auf ein NetWeaver 7.51 on HANA wollen, erzeugt der SUM einmal einen NetWeaver 7.45 Kernel für Oracle und einmal einen NetWeaver 7.45 Kernel für die HANA. Sie haben also zwei Kernel im Zielrelease. Ein Kernel ist für den Export von Daten aus der Oracle zuständig, der andere für den Import der Daten in die HANA. Sie können die R3*Tools beider Kernel im SUM-Verzeichnis bei der entsprechenden Phase austauschen, oder im Vornherein die aktuellen Versionen von tp, den R3*Tools und der dbsl über SAPCARin das SAR Archiv der Kernel integrieren. Aber ist das wirklich empfohlen? Der Maintenance Planner hat sich schließlich etwas dabei gedacht, als er Ihnen die entsprechenden Kernel zum Download untergeschoben hat. Und können Versionen der R3*Tools, die sehr frisch und daher kaum getestet sind, nicht zu Fehlern führen? Der grundsätzliche Menschenverstand sagt dazu ja. Die SAP empfiehlt in SAP Note aber 1616401 explizit, immer die „latest version“ von tp und R3trans zu nutzen. Da es wiederum keinen Sinn macht, R3trans getrennt von den restlichen R3*Tools zu aktualisieren, gilt für mich die Empfehlung, die R3*Tools komplett zu aktualisieren. Meiner Praxiserfahrung nach hatte ich bisher noch keine Probleme, wenn ich die Kernel Executables aktualisiert habe – aber immer Probleme, wenn ich es nicht gemacht habe.

Prüfen Sie bei der Aktualisierung, ob die einzelnen R3*Tools im Einzeldownload oder im Bundle innerhalb des EXE/EXEDB-Pakets neuer sind. Meistens sind die R3*Tools, die einzeln zum Download angeboten werden, neuer – es kam jedoch auch schonmal vor, dass die Version im EXE/EXEDB-Paket ein neueres Patch Level hat als der Einzeldownload. Dies ist in der Regel bei runden Patchlevels der Fall.

In der Vergangenheit gab es schon öfters Gegebenheiten, bei welcher eine neuere Version dieser Kernel-Komponenten die Geschwindigkeit von SUM-Prozeduren erheblich steigern konnte. SAP Note 2591334 und Note
2144285 – R3load can produce duplicates at export if bulk fetch mode is active sind beispielsweise Zeugen eines solchen Vorfalls in Verbindung mit einer near-Zero Downtime Maintenance (nZDM) auf Basis von SAP ASE, SAP Hinweis 1724496 – Latest patches for R3-tools zeigt ein Problem speziell für Systemkopien, der in einigen Quellsystemen immer noch gültig sein kann. Einzelfälle sagen Sie? Gehen Sie mal auf die SCN Seite zur Database Migration Option und schauen Sie sich unten unter „Related SAP Notes/KBAs“ an, wie häufig da ein R3*Tool vorkommt.

Um es kurz und einfach zu halten: Aktualisieren Sie Ihren Kernel. Sie können beispielsweise unter NetWeaver 7.31 im Quellrelease von Kernel 7.21 auf 7.22 mit aktuellem Patchlevel gehen. Informationen zum Patchen des SAP Kernels erhalten Sie unter SAP Note 19466 – Downloading SAP kernel patches .

Selbstverständlich sollten Sie im Laufe des Projektes für alle Systeme einer Systemlinie immer die selben Kernel Files verwenden und nicht mitten im Projekt wechseln.

Halten Sie außerdem die SPAM aktuell. Es lohnt sich, vor einer SUM-Prozedur die SPAM zu aktualisieren – unter Umständen fordert Sie sogar der SUM dazu auf.

Parametertuning im Transportprofil

Auch wenn es nicht unbedingt die Parallelität Ihrer Upgrade-Prozedur stört, lohnt es sich im Rahmen der Vor- und Nacharbeiten zu prüfen, wie im Transportprofil Ihres Systems der Parameter ACC_IMPORT gesetzt ist. Es kann sein, dass Sie in der Vergangenheit aufgrund von Problemen mit dem parallelen Import bei der Nutzung von SPAM oder SAINT diesen Parameter gesetzt haben, um die Parallelität von SPAM/SAINT Importen auszuschalten. Dies schadet natürlich der Laufzeit Ihrer Vor- und Nacharbeiten. Weitere Informationen finden Sie unter SAP Note
1223360.

Weitere Transportprofil-PArameter wie beispielsweise „parallel=n“ haben auf die SUM-Prozedur ebenfalls kaum Einfluss, weil dieser seine eigenen tp Statements generiert jedoch können Sie auch hier für den Regelbetrieb sowie für den Import von Transporten in den Vor- und Nacharbeiten die Parameter aus dieser SAP Note entsprechend berücksichtigen.

Was jedoch auch auf die SUM-Prozedur einen Einfluss haben kann ist der Transportprofil-Parameter „generation=later“ (SAP Note 1069417), der dazu führt, dass der Import Step zur Load Generierung nicht ausgeführt wird. Auf sehr alten Systemen mit wenig Arbeitsspeicher lohnt es sich mitunter, über den Parameter „tcs“ nachzudenken, der die Größe des R3trans Table Caches bestimmt (SAP note 103582). Ich habe jedoch noch keinen Kunden gehabt, bei welchem dies notwendg war – bei den R3trans Prozessen war immer zuerst die CPU der Falschenhals, und nicht der RAM.

Wenn Sie sich für eine Performanceoptimierung für Ihren Regelbetrieb im Zusammenhang mit R3trans interessieren, sind außerdem die SAP Hiwneise 1309506 und 2655872 für Sie interessant.

Anzahl an Workprozessen (Dialog und Batch)

Datenkonvertierungsarbeiten des Software Update Manager, insbesondere die aus dem Postprocessing bekannten Konvertierungsarbeiten von Methoden wie XPRAs, XCLAs oder AIMs vorgenommen werden, hängen sich in Dialog- und Batch-Prozesse an. Die meisten dieser Tätigkeiten werden durch Dialogprozesse parallelisiert. Vor Start des Upgrades empfiehlt die SAP bei großen Systemen eine kofniguration von 20 Dialog und Batch Prozessen, zumindest für eine SAP S/4HANA System Conversion (SAP note 2351294). Dies kann zur Not in einem Conversion-spezifischen Betriebsmodus durchgeführt werden. Die SAP note stellt weiter unten sogar die Anzahl der parallelen ABAP Workprozesse für die SUM phase XPRAS_AIMMRG sogar auf 32. Man könnte also überlegen, zumindest die Anzahl der Dialogprozesse auf 32 zu erhöhen.

Als absolutes minimum MÜSSEN Sie zwei Batchprozesse haben. Führen Sie den SUM auf der PASI aus, sollten es sogar mindestens 5 sein.

Aber auch für SUM Prozeduren, die nicht mit einer S/4HANA System Conversion zu tun haben, führt eine Erhöhung der Anzahl an Dialog- und Batch-Prozessen zu einer Beschleunigung der Konvertierungsarbeiten.

Das ganze bringt natürlich nur was, wenn Sie in der SUM Phase PREP_CONFIGURATION/INITSUBST auch eine entsprechende Anzahl an ABAP PROCESSES (DOWNTIME) konfigurieren. Es bringt Ihnen nichts, wenn Sie auf Instanzebene die entsprechende Anzahl an Dialog- und Batchprozessen konfigurieren, Sie dem SUM aber nicht zur Nutzung übergeben.

Einspielen von SAP Notes oder Support Package Stacks

Das Einspielen von SAP Notes oder SPs vor einem eigentlichen Upgrade kann ebenfalls in Einzelfällen zu Performancegewinnen führen. Ein historisches Beispiel ist etwa SAP Note 1986362 – Improve BW & ERP Upgrade performance by not copying content texts, welches auch heute noch die Upgradezeit für den NetWeaver Release 7.40 reduzieren konnte. Für viele Kunden imer noch relevnat ist außerdem Note 2229248 – Long runtime in background job „RSUPGRCHECK“ during SAP EHP upgrade.

Insbesondere lohnt es sich, den aktuellen Hinweis für den Note Assistant einzuspielen (1668882 und evtl. die Vorab-Note 2248091). Dies führt eventuell zu Zeitgewinnen beim Einspielen von notes im Zuge der Vor- und Nacharbeiten und kann für die Folgesysteme in einem Transport festgehalten werden.

Dateisystem NFS für den Software Update Manager und das Transportverzeichnis

Die SAP empfiehlt Ihnen in SAP Note 1616401 explizit, für das „Upgrade Directory“, also das Verzeichnis des Software Update Manager, explizit kein NFS oder ein anderes netzwerkbasiertes Dateisystem wie etwa Windows SMB, sondern ein lokales Dateisystem zu nutzen. Macht ja auch Sinn, da dieser die ganze Zeit Logs schreibt und dieser Vorgang synchron mit der Anwendungslogik passiert. Das Verzeichnis für das Download Directory (in welchem die Softwarepakete und der Upgrade Export liegen) kann aus meiner Sicht ruhig auf einem netzwerkbasierten Dateisystem liegen.

Wenn Sie einen SMB-basierten Netzwerkshare unter Windows nutzen, prüfen Sie die Relevanz von SAP Note
1823833 – Accessing shares via SMB3.0 can result in long waiting times.

Wenn Ihr Transportverzeichnis über NFS bereitgestellt wird, sollten Sie dieses zumindest über NFS4 bereitstellen und mounten. Häufig werden Transportverzeichnisse noch auf Basis von NFSv3 bereitgestellt, wenn Sie in Ihrer Organisation ein UNIX-System verwenden. Sie können aber auch unter Unix häufig schon NFSv4 mounten. Setzen Sie in diesem Zusammenhang auch im Transportprofil den PArameter lock_check_wait_time=0 (SAP Notes 1223360 und 132536). Dies beschleunigt den Import von Transporten enorm. Unter Windows sollten Sie für das Transportverzeichnis „Opportunistic Locks“ deaktivieren (SAP Note 690449).

Speziell für Systemkopie und DMO sollten Sie außerdem SAP Note 2093132 – Recommendations for NFS parameters during System Copy konsultieren

Halten Sie Ihr Transportverzeichnis außerdem sauber. Archivieren Sie veraltete Transportaufträge und nutzen Sie den Befehl „tp clearold all“ (SAP note 312843).

Sie sollten während eines SUM-Laufes beispielsweise mit dem Windows Ressourcen Monitor oder mit dem Linux-Komamndozeilentool iotop die Auslastung der Dateisysteme überprüfen und sicherstellen, dass die Storage-Ebene bei Ihnen nicht zum Flaschenhals wird. sowohl unter Linux als auch unter Unix sind ebenfalls die Tools iostat, vmstat und sar.

Betriebssystem Limits und Quotas sauber einstellen bzw. erhöhen

User Limits sind vor allem auf Unix und Linux Applikationsservern ein Thema. Für AIX konsultieren Sie SAP Note 323816 – AIX: User limit settings .

Ein Beispiel, wie falsch konfigurierte Limits Fehler in einem SUM Upgrade hervorrufen können und wie man damit umgeht, liefert SAP Note 1563583.

Performanceverbesserung der ACT_UPG

Die Phase ACT_UPG ist bekannt aus der Tätigkeit des Modification Adjustment über die SPDD. Die eigentlich lange Phase ist jedoch die Aktivierungsphase nach der Bearbeitung dieser. Um eine Vorstellung über die Laufzeit der Aktivierungsphase in der ACT_UPG zu bekommen, kann der Report RADMASDSC genutzt werden. First things first: Stellen Sie sicher, dass im Quellrelease die folgenden SAP Notes für Sie nicht relevant sind:

  • Quell-DB Oracle: SAP Note 1897538 – Long runtimes when accessing DD27S in ACT_UPG phase
  • 2105466 – Performance problem during ACT_UPG or ACT_TRANS during update to SAP_BASIS 7.40 SP8 or SP9
  • NW 7.40, Ziel-DB HANA: SAP Note 1855223 – Report RUTPOADAPT has a long runtime treffen.
  • Quelldatenbank Oracle: 556764 – Upgrade hangs in phase ACT_<REL>
  • Quelldatenbank Oracle: 1635605 – CLIENT HANGS ON INSERT INTO TABLE WITH SECUREFILE LOB
  • Quell-DB DB2/390: 545281 – DB2/390: Performance of DD activation
  • Quell-Release bis 7.31: 1614802 – Mass activation hangs during INSERT in the table DDFTX
  • Quell-Release bis 7.31: 1631790 – Mass activation during transport is started repeatedly
  • Quell-Release bis NW 7.3: 1892988 – DDIC_ACTIVATION phase takes too long in transaction SPAM/SAINT (auch für SUM)
  • Quell-Release bis 7.31: 1798059 – Improvment of performance during component upgrade

Zentrale Note für das Performance Tuning der ACT_UPG ist Note 1674812. Wie bereits weiter oben erwähnt, sollten Sie für das Upgrade-Verzeichnis ein lokales Verzeichnis wählen, keinen NFS-Share.

Die Performance der ACT_UPG wird sehr stark von den Instanzprofilparametern der Schatteninstanz beeinflusst. Wo Sie diese Profile finden und wie sie heißen, wurde in der Vergangenheit bereits hier übersichtlich zusammengetragen.

Insbesondere sollten Sie die Hauptspeicherparameter der Schatteninstanz erhöhen, sofern möglich. Möglichst ist dies dann, wenn Sie in einem Probelauf des Upgrades keine Speicherengpässe feststellen. Sie sollten bereits beim Probelauf einen „educated Guess“ machen und das Ergebnis begutachten. Die wichtigsten Paramter lauten

  • em/initial_size_MB
  • abap/heap_area_toal
  • abap/heap_area_dia
  • abap/heap_area_non_dia
  • ztta/roll_extension_dia
  • ztta/roll_extension
  • em/proc_max_size_MB = 0 (historisches Beispiel: SAP Note 2173629)
  • rdisp/wp_no_dia

Im Zweifel können die Speicherparameter temporär für die Schatteninstanz in einem Testlauf auf einen absurd hohen Wert gesetzt werden, solange man den Parameter em/initial_size_MB richtig konfiguriert. Wenn Sie das jedoch machen, wird der Swap Speicher des Betriebssystems exzessiv genutzt werden. Konkrete Werte finden Sie etwa in SAP Note 1387739. Ein Feintuning im Laufe der Sytemlinie ist notwendig. Die SAP empfiehlt in SAP note 1674812, dass Sie die Anzahl an Dialogprozessen für die Schatteninstanz (rdisp/wp_no_dia) zwischen 10 und 15 halten.

Nach Anpassung der Parameter können Sie die Schatteninstanz neu starten über

../abap/bin/SAPup stopshd

../abap/bin/SAPup startshd

Wie Sie ein memory Bottleneck in der Schatteninstanz in dieser Phase erkennen, schildert Ihnen SAP Note
1275873 – Memory bottleneck during DDIC activation during EHP import. Diese ist übrigens auch gültig für Quellrelease SAP_BASIS <= 7.10.

Es lohnt sich, während der Aktivierungsphase in ACT_UPG die SM50 zu monitoren. Dort können Sie sehen, ob ein SQL Statement besonders lange dauert. Dies könnte ein Hinweis auf ein einzelnes teures SQL Statement sein, welches Sie eventuell durch einen Index Rebuild oder eine Aktualisierung der Datenbankstatistiken beheben können.

Überspringen der Phase JOB_RASUVAR2

Der Variantenretter besteht aus zwei Phasen, die durch zwei verschiedene Jobs abgewickelt werden. Eine Erläuterung der Logik erhalten Sie unter SAP Note 712297. RASUVAR1 läuft vor dem eigentlichen Upgrade in der Online-Phase und speichert die Varianten in einer Tabelle. Nach dem Upgrade wird eine auf dem Zielrelease basierende Version des Jobs RASUVAR2 angestartet, welches die Varainten aus der Zwischentabelle abholt und verarbeitet.

Grundsätzlich müssen Sie jedoch nicht während der SUM-Laufzeit warten, bis der Job RASUVAR2 fertig ist. Wenn Ihnen die Phase zu lange braucht, können Sie sie im SUM überspringen und im Laufe der Nacharbeiten anstarten, während Sie parallel andere Aufgaben am System wahrnehmen.

Wie Sie den Schritt überspringen, erfahren Sie in SAP Note 1052664.

Performanceverbesserung der Phase PARCONV_UPG

In der PARCONV_UPG (Zentrale Performance Notes: 1947797 und 2100132) finden die Konvertierungen von Tabellen statt, beispielsweise wenn Felder gelöscht wurden oder sich deren Datentyp geändert hat. Das ganze braucht seine Zeit, weil man quasi jede Zeile der Tabelle einzeln beispielsweise das neue Feld an diesen einen Datensatz dranhängen muss. Wenn hingegen Felder hinzukommen, geht die Sache schneller, was das mit Hilfe eines DDL Statements geschehen kann und in diesem Fall jede Zeile etwa mit einem Standardwert belegt werden kann. DDL Statements können jedoch auch lange brauchen, und zwar wenn ein Index auf eine große Tabelle aufgebaut wird.

First things first: stellen Sie sicher, dass die folgenden SAP notes nicht auf Sie zutreffen:

  • Quellrelease bis SA_BASIS 7.11:
    1283197 – Cluster tables: Unnecessary conversion
  • Quelldatenbank DB2-z/OS:
    1386557 – DB2-z/OS: Upgrade/EHPI with external index rebuild

Wenn Sie in der Phase PARCONV_UPG die Transkation SM50 verfolgen, sehen Sie die tabelle, die gerade konvertiertwird. Alle Tabellen, die in dieser Phase involviert waren, könne Sie über SE14 -> DB Requests -> Mass Processing finden. In der SE14 prüfen Sie auch für die jeweiligen tabellen den Fortschrit des Umsetzens.

Lang laufende Indexaufbaus in dieser Phase finden Sie beispielsweise über ST04 raus. Sie können dann versuchen, den Aufbau dieser Indizes zu verhindern, indem Sie eine der drei Lösungen aus SAP Note 2100132 – upgrade phase PARCONV_UPG running for extremely long time due to large indexes creation anwenden.

Wie verbessern Sie nun die Zeiten? Nun, die aller erste Maßnahme ist es, Tabellenkonvertierungen zu vermeiden. Das bedeutet im Endeffekt: Vermeiden von Feldlöschungen bzw. Änderungen von Datentypen. Dies können Sie durch Ihre Entscheidung in der SPDD beeinflussen. Wenn Sie beispielsweise ein Z-Datenfeld zu einer Tabelle bzw. einem Datenelement hinzugefügt haben und wissen, dass Sie dieses im Zielrelease nicht mehr brauchen, liegt die Entscheidung nahe, auf Standard zurückzusetzen und das Feld somit löschen zu lassen. Vielleicht wäre es aber im Hinblick auf die Downtime klüger, die Modifikation zu übernehmen und das Feld im Nachhinein nach Freigabe des Systems zu droppen. Das lohnt sich halt vor allem dann, wenn die Tabelle bzw. die Tabellen, in welchen das Datenelement genutzt wird, sehr groß sind. SAP Note 24864 – No conversion of the table BSEG zeigt anhand der Tabelle BSEG sogar, wie Sie unter bestimmten Voraussetzungen Konvertierungsschritte in dieser Phase überspringen können, solange die Quelltabelle noch nicht verändert wurde.

Selbstverständlich reduzieren Sie jedoch auch die Laufzeit einer Konvertierung und eines Indexaufbaus, indem Sie die Größe der jeweiligen Tabelle reduzieren. Effektive Wege hierzu zeige ich Ihnen in der Sektion zur Datenreduktion auf.

In gewissem Maße spielen auch die Anzahl der ABAP Prozesse und die der SQL Prozesse eine Rolle. Hierzu gebe ich Ihnen in einer anderen Sektion in diesem Bietrag entsprechende Hinweise. Jedoch merken Sie hier nur bis zu einer maximalen Anzahl von 8 parallelen Prozessen einen Perforamncegewinn.

zu guter letzt: Speziell für SAP BW Systeme sollten Sie nach SAP Note 1420163 – Long runtimes for table conversion in Betracht ziehen.

Performanceverbesserung der Phasen SHADOW_IMPORT_INC und TABIM_UPG

Zentrale Einstiegs-Note ist 1945399. Während die SHADOW_IMPORT_INC eine Uptime Phase ist, ist die Phase TABIM_UPG eine Downtime-Phase. Diese beiden Phasen werden direkt durch die Parallelität von R3trans Prozessen beeinflusst, zu deren Sizing ich Ihnen an anderer Stelle in diesem Beitrag entsprechende Hinweise gebe.

Wie schnell die einzelnen R3trans-Importe sind, können Sie messen. In der Phase SHADOW_IMPORT_INC werden beispielsweise Logsim Format SAPKB<release>.<SID> erzeugt. Dort finden Sie Laufzeitangaben vor. Lang laufende SQL Statements in dieser Phase können Sie außedem über die Transaktion ST04 rausfinden.

Weitere Faktoren, welche die Performance dieser Phasen beeinflussen, sind:

  • I/O für Lese- und Schreibgeschwindigkeit im SUM-Verzeichnis (hierzu die Hinweise bezüglich netzwerkbasierte Dateisysteme in diesem Beitrag beachten)
  • I/O für Lese- und Schreibgeschwindigkeit auf der Datenbank. Deswegen sollten Sie in diesen Phasen explizit auf ein Full Online Backup der Datenbank verzichten.
  • Datenbank-Performance (datenbankspezifische Hinweise in diesem Beitrag beachten)
  • Die Anzahl an Support Packages, die Sie für das Upgrade mit ausgewählt haben (je mehr R3trans importieren muss, desto länger dauerts halt. Was aber nicht heißen soll, dass Sie deswegen weniger SPs in Ihre stack.xml integrieren sollten).

Sie sollten während eines SUM-Laufes beispielsweise mit dem Windows Ressourcen Monitor oder mit dem Linux-Komamndozeilentool iotop die Auslastung der Dateisysteme überprüfen und sicherstellen, dass die Storage-Ebene bei Ihnen nicht zum Flaschenhals wird. sowohl unter Linux als auch unter Unix sind ebenfalls die Tools iostat, vmstat und sar.

Performanceoptimierung der XPRAS-Phasen

Wie bereits schon an anderer Stelle erwähnt, wird die Performance der XPRAS-Phasen wie beispielsweise XPRAS_AIMMRG stark durch die Anzahl der parallelen ABAP- und SQL-Prozesse beeinflusst, und diese wiederum durch die Anzahl der Dialog- und Batch-Prozesse auf der Instanz.

First things first – prüfen Sie, ob folgende SAP Notes für Sie relevant sind:

  • Quelldatenbank MS SQL, SUM 1.0: 1780056 – SUM on MSS: Long running XPRAS phases
  • Quelldatenbank DB2, SAP_BASIS <=731: 1442150 – RUN_RSAIMMERGE_TRANSFER: Long runtime during upgrade or EHPI
  • Notes für Deadlocks, die auch in der XPRAS aufkommen können:
    1155807 – Database deadlock when executing DD_INT_UPDATE_DDFTX und
    1614802 – Mass activation hangs during INSERT in the table DDFTX
  • SAP_BW bis Release 7.31: 1722205 – Deactivate creation of pseudo D version during transport

Zentrale Note zur Performance-Analyse ist Note 1947874. Eine Performance-Analyse ist grundsätzlich über die SM50möglich. Dort sehen Sie die Workprozesse, die lange laufen. Von diesen müssen Sie sich den Namen des ausgeführten reports, die After-Import-Methode und den Namen der Tabelle, auf die zugegriffen wird, notieren.

Wenn es sich bei den Reports um BW Reports handelt, gibt es einige SAP Notes zu berückscihtigen. SAP Note
1649901 – Time-critical processes in BW upgrade/Support Package können Sie schon fast proaktiv als Vorarbeit implementieren (nicht auf BW Systemen, sondern auch auf anderen Systemen mit BI Content). Sie können die Aktivierung des BW Technical Content sogar komplett überspringen und als Nacharbeit nach dem Upgrade durchführen, siehe SAP Note 1629923 – Skip BW technical content objects activation during upgrade .

Performanceoptimierung der PARMVNT Phasen

In der Phase PARMVNT_SHD werden durch das Kommandozeilentool tp Tabellen erstellt oder geändert, was nicht zu verwechseln ist mit der PARCONV_UPG, die wir weiter oben erwähnt haben. Die PARCONV_UPG führt Änderungen auf Basis der Entscheidungen in der SPDD durch und bezieht sich daher auf Datenelemente, Strukturen und Domänen, die PARMVNT_SHD arbeitet direkt auf Datenbankebene und bezieht sich auf interne Releae Logik. Die SQL Statements für die PARMVNT_SHD werden in der Phase PARDIST_SHD generiert.

Das heißt, im Gegensatz zur PARCONV_UPG können Sie die Statements, die ausgeführt werden sollen, nicht so gut beeinflussen. Wann immer in dieser Phase ein tp Prozess aktiv ist, können Sie das teure SQL Statement über die Transkation ST04 (in der Originalinstanz, nicht in der Schatteninstanz) heraus finden.

Sie können prüfen, ob auf der Tabelle DDNTT~ ein Index auf den Primärschlüssel existiert. Falls nicht, kann dies ein Grund für lange Laufzeiten sein, weil dann ein Full Table Scan erfolgen muss. Unter Oracle können Sie prüfen, ob das DELETE Statement aus SAP Note 1960112 sehr lange braucht, um einen Hinweis darauf zu erhalten, dass es Probleme mit dem IOndexaufbau geben könnte.

Datenbankspezifische Maßnahmen

Aktualisieren / Patchen von Datenbankservern und Datenbankclients

Der Einfluss auf die Performance kann von kaum erkennbar über marginal bis hin zu extrem sein, je nachdem, welche Datenbank Sie einsetzen. Grundsätzlich empfiehlt es sich immer, nach Möglichkeit vor einem Upgrade-Projekt in einer Art „Mini-Downtime“ den Quelldatenbankserver sowie die Datenbank-Clients (sowohl auf dem Datenbankserver selbst als auch auf den Applikationsservern) zu patchen bzw. aktualisieren. Das heißt unter Oracle beispielsweise den aktuellen Bundle Patch einspielen und den Instant Client zu aktualisieren.

Besonders groß kann der Performanceunterschied bei DB6-Updates werden. Konsultieren Sie hierzu SAP Note
101809 – DB6: Supported Db2 Versions and Fix Pack Levels. Für Patches einer Oracle 12 Datenbank konsultieren Sie Note 1915316, für Oralce 11 gibt es fünf unterschiedliche Notes für 11.2.0.2-11.2.0.5. Ein historisches Beispiel, warum Sie Ihre Oracle Datenbank patchen sollten, finden Sie beispielsweise in SAP Note 1738989. Informationen zum Upgrade von SAP ASE auf Business Suite Systemen finden Sie unter 2238127 – How to upgrade ASE in a Business Suite environment – SAP ASE for Business Suite

Aktualisieren der Datenbankstatistiken

Sofern die von Ihnen eingesetzte Quelldatenbank dies nicht bereits automatisch optimiert, sollte Sie vor dem Upgrade auf den Systemen eine Aktualisierung der Datenbankstatistiken einplanen. Optimalerweise tun Sie dies ohnehin schon in einem regelmäßigen Turnus. Die Datenbankstatistiken stellen sicher, dass die Datenbank zum Erstellen des Ausführungsplans für ein SQL Statement möglichst aktuelle Datenbankstatistiken zur Ermittlung dieses optimalen Weges erhält. Je besser der Ausführungsplan, destobesser auch die Durchführung des Statements – was sich wiederum in der Performance auswirkt.

Ein Beispiel dafür, dass die Aktualisierung von Datenbankstatistiken im Zuge eines Upgrades etwas bringen kann, liefert SAP Note 1232776 – Long runtimes for accesses to D010INC or D010TAB.

Reorganisation der Datenbank

eine Reorganisation der Datenbank hat häufig einen geringeren Performanceeinfluss als gedacht, vor allem in OLTP Datenbanken. Dies wird beispielsweise in SAP Note 159316 – Reorganization of tables on SQL Server erwähnt. Ob Ihnen also eine Reorgnaisation der Datenbank vor einem Upgrade oder einer Migration wirklich einen signifikanten Vorteil verschafft, ist fraglich. In OLAP Szenarien, sprich unter SAP BW, ist dies wesentlich wahrscheinlicher als in einem OLTP Szenario.

Parametrisierung einer Oracle Datenbank

Für die verschiedenen Oracle Releases (meistens werden Sie jedoch zwangsläufig vorher auf Oracle 12c gehen müssen, wenn Sie eine bestimmte SUM-Prozedur ausführen wollen) gibt es jeweils unterschiedliche Notes zur Optimierung der Parametrisierung. Die folgende Tabelle listet die einzelnen Notes auf. Neben den Notes bringt außerdem die Vergrößerung des Tablespaces PSAPTEMP einen Performancegewinn. Sie verspüren einen Performancegewinn, indem Sie den PSAPTEMP vergörßern, bis auf maximal 20-30 % des Statements select sum(bytes) from dba_segments. Auch nützlich ist es, den Tablespace PSAPROLL auf bis zu 20 GB anzuheben.

Bevor sie ein Upgrade starten, haben Sie aeßerdem unter Oracle die Möglichkeit, die Phasen EU_CLONE_DT_SIZES und EU_CLONE_UT_SIZES zu unterdrücken. Während dieser Phasen werden normalerweise die Datenbankstatistiken über den Speicherverbrauch der Tabellena ktualisiert. Dadurch soll das Table Splitting verbessert werden. Häufig ist die Laufzeit jedoch höher als die Einsparung (insbesondere, wenn Sie die Datenbankstatistiken kurz vorher noch manuell aktualisieren), und Sie können mit den folgenden Statements diese Phasen unterdrücken.

brconnect -u / -c -f stats -t oradict_stats -p 8

brconnect -u / -c -f stats -t system_stats -p 8

brconnect -u / -c -f stats -o <schema_owner> -t all -f allsel,collect,space -p 8 -c 5 -force

brconnect -u / -c -f stats -t all -f monit -p 8

Damit die Phase wirklich auch noch übersprungen wird, müssen Sie im SUM Verzeichnis in der Datei SAPup_add.par noch den Parameter /ORA/update_spacestat = 0 setzen.

NoteBeschreibung

830576 – Parameter recommendations for Oracle 10g
Parametrisierung Oracle 10g

983548 – Long runtimes during SAP Upgrade using Oracle 10
Beheben langer Upgrade-Laufzeiten mit Quelldatenbank Oracle 10g

1431798 – Oracle 11.2.0: Database Parameter Settings
Parametrisierung von Oracle 11

2470718 – Oracle Database Parameter 12.2 / 18c
Parametrisierung Oracle 12.2 / 18c

838725 – Oracle dictionary statistics and system statistics
Oralce Dictionary und System Statistiken erstellen.

588668 – FAQ: Database statistics
Alles über Oralce Datenbankstatistiken

1918774 – Performance issues when running an SAP Installation
Einige Maßnahmen zur Optimierung einer Systemkopie bzw. DMO

1020260 – Delivery of Oracle statistics (Oracle >= 10g)
Oracle Preset Statistics ausliefern.

1609612 – FAQ: Oracle Real Application Clusters – Performance
Performance Analyse bei der Nutzung von Oracle RAC

936441 – Oracle settings for R3load based system copy
Parametertuning für Systemkopie, Unicode Conversion oder DMO

806554 – FAQ: I/O-intensive database operations
speziell für DMO und Systemkopie – Tunig des I/O Durchsatzes

1438410 – SQL script collection for Oracle
diverse Check Scripts für Oracle

771929 – FAQ: Index fragmentation
+
Note 979054 – RSORAISQN
Index Fragmentierung prüfen

619188 – FAQ: Oracle wait events
Idle und Wait Events optimieren

821687 – FAQ: Space utilization and fragmentation in Oracle
Speicher und Fragmentierungsprüfung
1269911Chained Row Optimierung
https://docs.oracle.com/cd/E18283_01/network.112/e10836/performance.htmNetzwerkparametertuning

600141 – Oracle9i: Automatic UNDO Management
erklärt am Beispiel von Oracle 9 die Berechnung der Größe des Undo Tablespace und kann auch unter Oracle 12 noch als Basis für die Berechung verwendet werden..

2007272 – Identify Duplicated Records in Oracle tables
Doppelte Einträge in Tabellen finden, um zu verhindern, dass unnötig Zeit beim Aufbau eines Index verschwendet wird sowie Fehler beim nachträglichen Setzen des Primary Keys / Primary Index auf eine tabelle entstehen.

1171650
automatischer Oracle Parameter Check

Parametrisierung einer Sybase Datenbank

NoteBeschreibung

2162183 – Important KBAs and SAP Notes – SAP ASE for Business Suite

Enthält zahlreiche Notes zur Performancediagnose und Performanceoptimierung

1722359 – SYB: Running SAP applications on SAP ASE – Best Practice
Performanteoptimierung für NetWeaver on Sybase

1749935 – SYB: Configuration Guide for SAP ASE 15.7
Parametrisierung von 15.7

1581695 – SYB: Configuration Guide for SAP ASE 16.0
Parametrisierung von 16.0

1680803 – SYB: SAP Adaptive Server Enterprise – Best Practice for SAP Business Suite and SAP BW
Optimierung von Systemkopie oder DMO auf BW oder Business Suite Systemen

Parametrisierung von MS SQL Server

NoteBeschreibung


1593183 – TCP/IP networking parameters for SQL Server
Netzwerkparametrisierung von MS SQL

1744217 – MSSQL: Improving the database performance sowie alle untergeordneten Notes

Parametertuning für MS SQL

987961 – FAQ: SQL Server I/O performance

Analyse der I/O Performance

1648817 – Disallow Page Level Locks for Microsoft SQL Server
Umgang mit Locks

484657 – Configuration Parameters for Microsoft SQL Server 2017
Parametrisierung SQL Server 2017

2312935 – Configuration Parameters for SQL Server 2016
Parametrisierung SQL Server 2016

1986775 – Configuration Parameters for SQL Server 2014
PArametrisierung SQL Server 2014

1702408 – Configuration Parameters for SQL Server 2012
Parametrisierung SQL Server 2012

1237682 – Configuration Parameters for SQL Server 2008
Parametrisierung SQL Server 2008

879941 – Configuration Parameters for SQL Server 2005
PArametrisierung SQL Server 2005

327494 – Configuration Parameters for SQL Server 2000
Parametrisierung SQL Server 2000

1660220 – Microsoft SQL Server: Common misconceptions
Verweis auf diverse Notes für die Analyse von Deadlock-Situationen.

2235057 – Performance issues during SAP Upgrade with SQL Server
Analyse von Performanceproblemen speziell bei Upgrades

1054852 – Recommendations for migrations using Microsoft SQL Server
Parametrisierung für Systemkopie, Unicode Conversion oder DMO

Parametrisierung einer MaxDB

NoteBeschreibung



819641 – FAQ: SAP MaxDB performance
Zentrale Note zur Verbesserung der MaxDB Performance

1669346 – Performance optimization for the shadow upgrade
zu implementierende Note im Quellrelease SAP_BASIS 730-731

1004886 – SAP MaxDB 7.7 database parameter recommendations
Parametrisierung von 7.7


Parametrisierung von 7.8

1346964 – SAP MaxDB 7.9 database parameter recommendations
Parametrisierung von 7.9

1112046 – Performance problems with SAP MaxDB/liveCache on Solaris 10
Performanceprobleme auf Solaris 10 beheben

1111426 – Database parameter check for SAP MaxDB/liveCache
Datenbank Parameter Checker

Parametrisierung einer DB2/DB6 Datenbank

NoteBeschreibung



1851832 – DB6: Db2 10.5 Standard Parameter Settings
Parametrisierung von DB2 10.5


1329179 – DB6: DB2 9.7 Standard Parameter Settings

PArametrisierung DB2 9.7

1692571 – DB6: Db2 10.1 Standard Parameter Settings

Parametrisierung DB2 10.1

1086130 – DB6: DB2 9.5 Standard Parameter Settings
PArametrisierung DB2 9.5


899322 – DB6: DB2 9.1 Standard Parameter Settings
Parametrisierung DB2 9.1

1730855 – DB6: Establishing a connection to DB2 is very slow
Probleme bei der Verbindung zwischen Applikationsserver und DB2

1488208 – DB2 z/OS Java Upgrade with Enterprise Portal(EP)
Probleme bei java Stack Upgrade unter DB2 z/OS proaktiv vermeiden.

Performanceoptimierung einer HANA Datenbank

NoteBeschreibung



2000000 – FAQ: SAP HANA Performance Optimization
Monolithischer Gesamt-Hinweis zur Performanceoptimierung


1669346 – Performance optimization for the shadow upgrade

einzuspielende SAP note in Quellrelease SAP_BASIS 730-731

HANA Datenbankparameter für die Downtime

Wir sprechen hier über die HANA Ziel-Datenbank. Wenn Sie eine Migration von einer HANA Datenbank in eine andere machen, müssen Sie die hier erwähnten Parameter in der Zieldatenbank tätigen. Diese Parameter sind explizit aus der Downtime. Sie verkürzen die Zeit für XPRAs, XCLAs und AIMs, welche insbesondere im Postprocessing angewandt werden, sowie die Dauer von Deltamerges, die im Rahmen des Shadow Importes und im rahmen der Datenmigrationen in den Nacharbeiten auftreten. Sie gehen hervor aus SAP Note 2351294. Ich erhebe keinen Anspruch auf Aktualität, deshalb immer wirklich die entsprechende Note konsultieren. wie in der Note erläutert, können Sie die Parameter so lange stehen lassen, bis sie in den Nacharbeiten die Datenmigrationen über die SPRO abgeschlossen haben.

KonfigurationsfileSektionParameterWert
indexserver.inimergedogload_balancing_func„LCC / 2“
indexserver.inimergedogtoken_per_table<physikalische CPU Kerne auf dem System> / 2 (aber niemals görßer als 256)
indexserver.iniindexingparallel_merge_threads
<physikalische CPU Kerne auf dem System> / 2 (aber niemals görßer als 256)
indexserver.iniindexingparallel_merge_part_threads
<physikalische CPU Kerne auf dem System> / 2 (aber niemals görßer als 256)

Deaktivieren des Log Archivings und Redo Log Mirrorings zur Downtime

Die meisten Kunden machen das ohnehin schon, daher halte ich diesen Tipp relativ kurz. Kurz vor Eintritt der Downtime werden Sie durch den Software Update Manager ohnehin aufgefordert, das Log Archiving auf der Datenbank auszuschalten. Dies sollten Sie nicht nur beim Upgrade, sondern auch bei der Migration, beispielsweise per Systemkopie machen. Voraussetzung ist natürlich, dass Sie vor Eintritt in die Downtime ein vollständiges Datenbankbackup erstellt haben.

Nicht nur das Log Archiving können Sie ausschalten, sondern gleichzeitig auch das Redo Log Mirroring. Wenn Sie beispielsweise Ihre Oracle Redo Logs auf mehrere Datenträger spiegeln, muss eine Transkation warten, bis sie auf beiden Datenträgern persistiert wird. Das beeinträchtigt natürlich die Performance.

SGEN nicht während der Downtime durchführen

Der Software Update Manager gibt Ihnen sowohl bei Upgrade als auch bei einer DMO die Möglichkeit, die „Load Generation“ während der Downtime durchzuführen. Besser ist es, Sie starten die SGEN einmal manuell nach Abschluss des Software Update Managers an und lassen sie Prozedur online als Hintergrundjob laufen. Dann müssen Sie die Dauer der SGEN nämlich nicht als technische Downtime draufschlagen und können nebenbei einige Nacharbeiten machen, was die Business Downtime verkürzt.

Warum empfiehlt Ihnen die SAP das nicht? Nun, weil es bei Business Server Pages sein kann, dass Sie die Generierung mehrfach durchführen müssen, und Sie es außerdem vermeiden sollten, die SGEN abzubrechen (insbesondere im Zusammenhang mit BSPs). Deswegen empfehle ich Ihnen, die SGEN erst anzuschalten, nachdem Sie ein Backup des fertig upgegradeten Systems gemacht haben, auf welchem nur noch die Nacharbeiten durchgeführt werden müssen.

Sollten Sie die Option zur Ausführung der SGEN während des Upgrades ausgewählt haben und diese läuft nun gerade unerwartet lange, können Sie die SGEN manuell über den Report RSUPG_SGEN_ABORT_SHADOW abbrechen und somit zum nächsten Schritt des Upgrades fortschreiten.

Übrigens: ein frischer SGEN VOR dem Upgrade kann die Laufzeit desselben reduzieren. Meistens ist der Gewinn jedoch marginal.

Rebuild bestimmter Indizes

Bei Oracle Quelldatenbanken kann es sinnvoll sein, im SAP Business Suite Umfeld bestimmte Indizes online neu aufzubauen, bevor der Export der Daten stattfindet. Diese verbessern eventuell die Performance von Tabellenkonvertierungen eines Upgrade bzw. von Exporten bei einer Systemkopie oder DMO. Die folgende Liste zeigt ein Beispiel.

alter index SAPDAT.“VBFA~M01~ REBUILD ONLINE COMPRESS PARALLEL 3;

Was ist eigentlich, wenn Sie Daten nicht aus einer Oracle Datenbank exportieren, sondern importieren, beispielsweise wenn Sie auf eine Oracle 12c Zieldatenbank migrieren, etwa im Rahmen einer Systemkopie?

In diesem Fall können Sie das ALTER Index Statement dazu nutzen, die Fortschreibung von Indizes für die Zeit des Imports auszuschalten. Wenn Sie verhindern, dass Indizes mitgeschrieben werden, hat die Oracle mehr I/O für das Schreiben der eigentlichen Produktivdaten zur Verfügung. Dadurch geht der Import schneller. Sie können die Indizes dann später in der Uptime online rebuilden. Dadurch haben Sie effektiv die Importzeit und damit die Business Downtime reduziert.

Setzen Sie zunächst vor dem Import die Indizes auf unusable. Ein Beispiel im ERP Umfeld könnte sein

alter index SAPDAT.“MSEG~M“ UNUSABLE;

alter index SAPDAT.“MSEG~R“ UNUSABLE;

alter index SAPDAT.“MSEG~S“ UNUSABLE;

alter index SAPDAT.“ACCTIT~1“ UNUSABLE;

alter index SAPDAT.“COEP~1“ UNUSABLE;

alter index SAPDAT.“EDIDS~2“ UNUSABLE;

alter index SAPDAT.“EDIDS~1“ UNUSABLE;

alter index SAPDAT.“JITIT~001“ UNUSABLE;

alter index SAPDAT.“JITIT~002“ UNUSABLE;

alter index SAPDAT.“JITIT~003“ UNUSABLE;

alter index SAPDAT.“JITIT~004“ UNUSABLE;

alter index SAPDAT.“JITIT~005“ UNUSABLE;

alter index SAPDAT.“JITHD~001“ UNUSABLE;

alter index SAPDAT.“JITCO~001“ UNUSABLE;

Starten Sie nun den Import. Nach der Downtime, wenn die Migration abgeschlossen ist und das System schon wieder läuft, rebuilden Sie die Indizes. mit dem oben erwähnten Statement.

Optimierung der Perfomrance einer S/4HANA System Conversion

Parameter in der Tabelle MFLE_PARAMS

Im Rahmen einer System Conversion nach SAP S/4HANA wird der Converison Report
MFLE_XPRA_PARALLEL_CALL ausgeführt, welcher sich um die Konvertierung aller Tabellen mit dem Datenelement MATNR auf die neue „lange Materialnummer“ (LAMA) mit 40 Zeichen kümmert. . Über das Tuning der Parameter in der tabelle MFLE_PARAMS (SAP Note 2355049) kann die Performance dieses Reports gesteigert werden. Weitere Tuning Parameter, die auch diesen Report betreffen, finden Sie in SAP Note 2351294, die der folgenden Sektion behandelt wird.

Parameter in der Tabelle SHDB_PFW_CONF

Während der SUM Phase CHECK4NOTES_TOOL_SHD2 empfiehlt es sich, zur Beschleunigung einer Reihe von Conversion Reports gemäß SAP Note 2351294 ab einem Zielrelease von SAP S/4HANA 1709 oder höher bestimmte Parameter in der Tabelle SHDB_PFW_CONF zu setzen. Hierzu sollten Sie einen Breakpoint auf die Phase CHECK4NOTES_TOOL_SHD2 setzen (SAP Note 2207944) und dann die in der note gelisteten Kommandos ausführen.

Aktuell lauten die Befhele sowohl für Zilrelease 1709 als auch 1809 wie folgt

INSERT INTO SHDB_PFW_CONF (APPL_NAME,COMPONENT,PARAM,TYPE,LENGTH,DECIMALS,VALUE,CHANGEABLE) VALUES (‚XCLA_PROCESSING‘,’RESOURCE PROVIDER‘,’ABAP_MAX_WP‘,’I‘,4,0,‘32‚,‘N‚);
INSERT INTO SHDB_PFW_CONF (APPL_NAME,COMPONENT,PARAM,TYPE,LENGTH,DECIMALS,VALUE,CHANGEABLE) VALUES (‚XCLA_PROCESSING‘,’DISPATCHER‘,’WAKEUP_INTERVAL‘,’I‘,4,0,‘1‚,‘N‚);

Diese beiden Statements wiederholen Sie nun für alle Prozeduren in den Tabellen (Spalte APPL_NAME aus Note 2351294). Beachten Sie: Die Ausführungen für den Release 1709 gelten auch für Zielrelease S/4HANA 1809.

Sie sollten dabei achten, dass die Anzahl an maximalen Prozessen nicht dazu führt, dass CPU, Storage I/O oder Arbeitsspeicherkapazität mehr als 90% beansprucht werden. Sie sollten während der jeweiligen SUM Phase (Spalte SUM Phase in der Tabelle der Note, meistens XPRAS_AIMMRG) die Utilization von CPU, Storage und Arbeitsspeicher überwachen und prüfen, ob Sie die Parameter richtig gewählt haben.

Natürlich bringt Ihnen das Einstellen mehrerer ABAP Workprozesse nur was, wenn Sie die entsprechende Anzahl an Workprozessen auch auf der Instanz zur Verfügung haben.

Parallele Ausführung von SD Reports

SAP Notes 2353814 bzw. 2351294 befassen sich mit der Parallelisierung von Datenkonvertierungsprogrammen im SD-Umfeld während einer S/4HANA System Conversion. Die Verbesserungen sind im Prinzip sehr einfach zu implementieren, da sie im Endeffekt immer nur über die SE16 einige Einträge in bestimmten Tabellen ändern müssen.

Optimierung der DMO und Systemkopie Performance

Die hier gelisteten Aktivitäten verbessern vor allen Dingen die Performance einer Database Migration Option und der heterogenen Systemkopie. Sie sind explizit dafür vorgesehen und haben keinen oder nur einen sehr geringen Einfluss bei der Upgrade-Performance.

Die DMO auf einem leistungsstärkeren AAS laufen lassen

Bis einschließlich SUM 1.0 SP20 war es nur möglich, eine DMO auf dem eigentlichen Primary Application Server (PAS) laufen zu lassen. Häufig bedeutete dies automatisch eine hohe Einschränkung in der Performance, das die Maschine häufig schon sehr alt und mitunter nicht virtualisiert ist. Außerdem wird der PAS häufig während der technischen Uptime-Phase zusätzlich durch den Grundbetrieb belastet. Nun ist es möglich, Die DMO grundsätzlich auf einem Additional Application Server (AAS) laufen zu lassen. Dadurch wird der PAS entlastet und man profitiert eventuell auch von einem leistungsfähigeren Host. Leider funktioniert die Prozedur nur auf Quellsystemen, die bereits eine getrennte ASCS Instanz aufgebaut haben. Wenn Sie noch keinen ASCS/PAS Split durchgeführt haben, prüfen Sie, ob Sie diesen im Quellrelease durchführen können.

Netzwerkbandbreite und Jumbo Frames

Speziell im Umfeld einer Database Migration Option oder einer Systemkopie mit parallelem Export/Import ist es wichtig, dass die Netzwerkbandbreite ausreichend ist, um eine entsprechende Migrationsgeschwindigkeit zu stemmen. Ein dediziertes 10 Gbit/s Netzwerk sollte bereits genügend Bandbreite für eine Migrationsgeschwindigkeit von 3500 GB/h liefern, jedoch ist dies nicht praxianah, da häufig auch andere Komponenten im Netzwerk sind. Die SAP empfiehlt für eine DMO zwischen den Hosts auch mindestens ein Netzwerk, in welchem alle Komponenten die 10 Gbit/s liefern können. Explizit nicht unterstützt von der SAP ist eine DMO „across data centers“, also zwischen zwei Rechenzentren. Dies sollten Sie also in der Planung bereits vermeiden.

Es ist definitiv eine Überlegung wert, für den Zeitraum der Migration Quell- und Ziel-Datenbank in ein und das selbe Netzwerksegment ohne Firewalls dazwischen zu packen, um die Netzwerkbandbreite zu erhöhen. Andererseits erzeugt dies zusätzlichen Aufwand, weil Sie diese Konfiguration nach der Migration dann umstellen müssen. Besser ist es, sicherzustellen, dass die Netzwerkbandbreite nicht zum Flaschenhals wird, indem man vorher sauber architektonisch designt und sized.

Unter Umständen könnte es Ihnen auch einfallen, Jumbo Frames auf den Hosts zu konfigurieren. Seien Sie damit jedoch vorsichtig. Jumbo Frames können auch eine Fehlerursache sein, die nur sehr schwer zu finden ist. Sie hat damit gleichzeitig einen hohen Business Impact, denn damit das Ganze funktioniert, müssen

  • alle beteiligten Netzwerkkarten
  • Router und Firewalls
  • Nebengeräte (wie beispielsweise Netzwerkdrucker)

mit diesen Frames umgehen können. Auch softwareseitig kann es zu Problemen kommen. Unter SAP HANA 1.0 gab es vom Hersteller dokumentierte Fälle, in denen die Konfiguration von Jumbo Frames zu Fehlern geführt hat (z. B. SAP note 2166157).

SUM Benchmarking Tool

Wenn Sie den Software Update Manager aufrufen, können Sie das DMO Benchmarking Tool unter https://<hostname>:112[8|9]/lml/migtool/<sid>/doc/sluigui aufrufen. Dort angekommen haben Sie die Möglichkeit, den Export und Import von Daten zu prüfen.

Grundsätzlich ist die Konfiguration des Tools für eine Database Migration Option optimiert. Das heißt Sie geben die Systemdaten der Zieldatenbank ein, und der Software Update Manager führt dann probeweise die Prozedur eines parallelen Export/Imports durch. Natürlich ist dieser Benchmark aber zeitgleich auch ein Nachweis für die Performance eines parallelen Export/Imports bei einer Systemkopie.

Wählen Sie zunächst den Menüpunkt „Benchmark migration“. Als ersten Ansatz sollten Sie immer versuchen, den Export der Quelldatenbank zu optimieren. Dazu empfiehlt es sich, im Benchmark Tool zunächst den Menüpunkt „Benchmark Export (discarding data)“ zu wählen.

Starten Sie den Export auf einem kleinen Prozentsatz der Systemtabellen. SAP selbst empfiehlt mindestens 100 GB, jedoch maximal 10% der Quelldatenbankgröße. Den ersten Lauf sollten Sie komplett ohne irgendwelche Optimierungen in der Quelldatenbank durchführen. Danach führen Sie schrittweise Optimierungen durch und testen deren Auswirkungen auf die Export-Performance, indem Sie den Lauf wiederholen.

Im Feld „Size of largest table in sample“ legen Sie fest, wie große eine Tabelle maximal sein darf, um in den Benchmark mit aufgenommen zu werden. Wenn ihre Datenbank 100 GB groß ist und Sie 1% wählen, werden keine Tabellen selektiert, die größer als 1 GB sind. Das ist natürlich nicht repräsentativ. Sie wollen durchaus auch größere Tabellen benchmarken, um kein „unrealistisch positives“ Ergebnis zu bekommen. Andererseits wollen Sie aber auch keine zu großen Tabellen selektieren, da diese als „Ausreißer“ die Statistik in das negative verfälschen. Eine Tabellengröße von 100 GB als Maximum anzustreben ist auch hier ein guter Richtwert.

Setzen Sie den Haken bei „Enable Migration repetition“, um auf einfache Art und Weise den Test wiederholen zu können.

Im nächsten Fenster setzen Sie beim ersten Lauf eine hohe Anzahl an R3load Prozesse, um eine entsprechende Anzahl an Buckets für das Table Splitting zu erzeugen. Dadurch, dass Sie viele Buckets erzeugen, können Sie später besser mit mehreren R3load Prozessen hantieren und somit bestimmten, welche Anzahl bei Ihnen optimal ist. Sie können es ruhig übertreiben und die 10-fache Menge an Kernen bzw. virtuellen CPUs auf dem System nutzen.

Bevor Sie auf den Button „Execution“ klicken, reduzieren Sie wieder die Anzahl der R3loads, indem Sie den Wert auf einen empfohlenen Wert einstellen. Das geht im SUM Menü unter More -> Utilities. Ein guter Einstiegswert ist die doppelte Menge an CPU Kernen auf dem Host. Auf den meisten Systemen können sie das sowohl für Downtime als auch für die Uptime konfgurieren. Nur, wenn bei einer Testmigration im Online-Betrieb ein Impact auf die Performance auffällt, sollten Sie für die Uptime weniger wählen.

Starten Sie nun den Benchmark. Monitoren Sie während der Ausführung die Auslastung der CPU und die Auslastaung der Netzwerkbandbreite. Diese sollten, wie weiter unten nochmal beschrieben, eine Auslastung 90% nicht überschreiten. Wiederholen Sie den Schritt so oft Sie wollen und führen Sie irgendwann nicht nur einen Export, sondern auch einen Import aus. Spielen Sie mit den R3load Prozessen, bis Sie einen optimalen Wert erzielt haben, der Ihnen eine kontinuierliche CPU- oder Netzwerk-Auslastung (was auch immer der Flaschenhals bei Ihnen ist) zwischen 80 und 90% beschert. Der Arbeitsspeicher sollte ebenfalls nie komplett voll sein, um Paging zu vermeiden. Ein R3load Prozess benötigt mindestens 60 MB, jedoch auch gerne mal mehr.

Nachdem Sie den Export ausführlich optimiert hatten, sollten Sie eine komplette Migration benchmarken, also auch den Import. Hierbei macht es Sinn, den Menüpunkt „Operate on all tables“ zu wählen bzw. die DB size und die largest Table Size auf 100% zu setzen und daher keine Einschränkung über die Tabellen mehr zu machen. Für weitere Optimierungsmaßnahmen in dieser Benchmark-Phase können Sie nun im nächsten Kapitel weiter unten weiterlesen.

Nachdem Sie die komplette migration gebenchmarkt haben, können Sie sdas ergebnis über das Summary Log unter SUM/abap/log/EUMIGRATERUN*.LOG auswerten. Das Log zeigt Ihnen unter anderem den Migration Speed in GB/h an. Von einer guten Migrationsgeschwindigkeit spricht man ab 300 GB/h, erstrebenswert sind 500 GB/h. Im sogenannten Durations File unter SUM/abap/htdoc/MIGRAT*_DUR.XML findne Sie die graphische Repräsentation der Laufzeiten einzelner migrierter Tabellen. Suchen Sie hier Langläufer am Ende der Migrationsphase. Wenn Sie eine langlaufende Tabelle finden, analysiseren Sie die Datei SUM/abap/log/MIGRATE_RUN*.LOG und suchen Sie nach dem Namen der tabelle. Analysieren Sie

Zusätzlich können Sie zur Auswertung im SUM unter „DMO Migration Post Analysis -> Charts“ die Datei „MIGRATE_*PROC*“ auswählen und dadurch die Auslastung der R3load Prozesse analysieren. Sie sollten einen „tail“ im Graphen der R3load Auslastung vermeiden.

Anzahl an ABAP, SQL, R3trans und R3load Prozessen

Anzahl der R3load Prozesse

Fangen wir mit den R3load Prozessen an. Sie sind zuständig für die Kopie des Original-Repositorys auf das Schatten-Repository und bestimmen somit die Geschwindigkeit zum Aufbau der Schatteninstanz. Außerdem werden Sie in der Downtime-Phase einer Database Migration Option für den Shadow Import von der Quelldatenbank in die Ziel-Datenbank (meistens SAP HANA) verwendet. Sie bestimmen also an zwei kritischen Punkten des Upgrades die Geschwindigkeit ungemein.

Die R3load Prozesse für die UPTIME werden für folgende Tätigkeiten benutzt

  • Kopieren der Schattentabellen in das Shadow Repository der Schatteninstanz.
  • Bestimmen der Tabellen für den Export während der Downtime

Die R3load Prozesse für die DOWNTIME werden für folgendes genutzt

  • Export und Import der Tabellen während des Shadow Imports

Grundsätzlich sollten Sie nur so viele R3load Prozesse konfigurieren, dass die CPU gemäß Betriebssystem-Monitor nie mehr als 90% ausgelastet ist. Eine 100%-ige Auslastung der CPU verschlechtert eher die Performance des R3load Vorgangs, daher sollte man sich bei etwa 90% auspendeln. Selbiges gilt für die Netzwerkbandbreite und den Storage. Sie können beispielsweise unter Linux mit „top“ die Auslastung während eines Benchmarks oder einer Migration auf einer Sandbox kontinuierlich in der Konsole verfolgen. Mit „iftop“ können Sie unter Linux den Netzwerktraffic monitoren. Mit „iotop“ überwachen Sie die Auslastung der Persistenzschicht. Unter Windows können Sie die Überwachung über den Task Manager vornehmen. Auch solten Sie mit den R3load-Prozessen nie den Arbeitsspeicher voll machen, so dass es zum Paging in den virtuellen Speicher bzw. in den Swap kommt. rechnen Sie grob pro R3load Prozess mit 60 MB RAM.

In SAP Note 1616401 heißt es, man solle als groben Richtwert die 3- bis 5-fache Menge an verfügbaren CPU-Kernen im System verwenden. Das heißt im Endeffekt die SAP gibt Ihnen hier Spielraum: 5-fache Menge, wenn Sie sicher sind, dass andere Faktoren wie beispielsweise RAM und Netzwerk nicht zum Flaschenhals werden, und die 3-fache Menge, wenn Sie auf Nummer sicher gehen wollen. In SAP Note 2643221 bzw.
2691785 (ja ich weiß, diese sind bezogen auf einen bestimmten SUM 1.0 Release) und 857081 heißt es wiederum, Sie sollen lediglich die zweifache Menge nehmen. In SAP Note 1875778 ist wiederum explizit von der dreifachen Menge die Rede. Aus meiner Sicht sind das eben nur grobe Richtwerte, und ein genaueres Sizing über das SUM Benchmark Tool, welches ich an anderer Stelle erwähne, bringt Sie näher an den optimalen Wert heran.

Monitoren Sie die Werte sowohl auf dem Applikationsserver (Export) als auch auf dem SAP HANA Host (Import).

ABAP Prozesse

Kommen wir nun zur Anzahl der ABAP Prozesse. Wie bereits weiter oben in der Überschrift Anzahl an Workprozessen (Dialog und Batch) erläutert, benötigen Sie erstmal auf dem System die notwendige Anzahl an Batch- bzw. Dialogprozessen. Es bringt Ihnen nichts, in dieses Feld 200 ABAP Prozesse einzutragen, wenn Sie die entsprechenden Workprozesse nicht auf der Instanz haben. Umgekehrt müssen Sie aber auch die Anzahl an Workprozessen, die Sie durch den Software Update Manager belegen wollen, dann auch tatsächlich in dieses Feld eingeben. Diese Option bestimmt auch die Anzahl an Hintegrundprozessen zur Aktiiverung über das Kommandozeilentool tp.

Eine möglichst hohe Anzahl an parallelen Dialogprozessne wird vor allem in der SUM Phase XPRAS_AIMMRG relevant. Eine möglichst hohe Anzahl an Batchprozessen wird vor allen Dingen während jobgesteuerter SUM Phasen wie DBCLONE, ACT_UPG, PARDIST und XPRAS relevant, auch wenn viele dieser Prozesse maximal 10 parallele Batchprozesse berhaupt bedienen können. Während der Uptime können Sie nur so viele ABAP prozesse konfigurieren wie verfügbar (wenn Sie mehr eingeben, bringt das nichts).

Die Batchprozesse bekommen Sie nur, wenn Sie die Batchprozesse nicht nur „live“ in der Betriebsart zur Verfügung haben (also während der Uptime in der SM50 bzw. RZ04 angezeigt bekommen), sondern auch der Parameter rdisp/wp_no_btc diese Nummer hergibt.

Sie sollten diesen Wert grundsätzlich so hoch stellen, wie es geht. Wenn Sie sich alle Tipps aus diesem Beitrag ansehen, kommen Sie irgendwann auf 32 Prozesse

SQL Prozesse

dieAnzahl der SQL Prozesse bestimmt die Anzahl an parallelen SQL Statements auf der Datenbank, speziell in den DDL Phasen wie MVNTAB und PARCONV, in welcher viele Statementsim Format „CREATE TABLE“, „ALTER TABLE“ und „CREATE INDEX“ abgsetzt werden. Empfohlen wird hier gemäß SAP note 1616401 die Anzahl physikalischer CPUs

R3trans Prozesse

Diese Parameterangabe wird nicht nur für die Anzahl der parallel ausführbaren R3trans, sondern auch für die tp Prozesse genutzt. Wenn Sie hier optimal treffen, beschleunigen Sie den Import von allen Softwarepaketen in das Schattenrepository, die nicht im Upgrade Export vorhanden sind. Je höher das Delta zwischen Upgrade Export und im Zielrelease enthaltenen Support Packages, desto höher der Effekt, wenn Sie hier richtig optimieren. Insbesondere beschleunigen Sie hier die Phasen DDIC_UPG, SHADOW_IMPORT* und TABIM_UPG.

die Empfehlung der SAP widerspricht sich hier an zwei Stellen. In SAP Note 1616401 sagt die SAP, man solle für die Anzahl der R3trans Prozesse die Anzahl an CPU-Kernen (erkannt durch die ST06) für die Anzahl der R3trans Prozesse nehmen. In SAP Note 2643221 heißt es, man solle genau wie bei R3load die doppelte Anzahl verwenden, dies sei „ein guter Richtwert“. Aus meiner Sicht handelt es sich hier um einen Formulierungsfehler und die Vorgabe aus 1616401 gilt. Gemäß SAP Note 2643221 bzw. 2691785 (ja ich weiß, diese sind bezogen auf einen bestimmten SUM 1.0 Release) sagt die SAP, dass gemäß ihrer Erfahrungen die Anzahl der R3trans Prozesse nie höher als 40 gesetzt werden. Ein genaueres Sizing über das SUM Benchmark Tool bringt Sie näher an die optimalen Zahlen.

Wenn Sie die Note 1616401 wirklich ausführlich lesen, finden Sie auch einen Verweis zur Note 1597414. Hierbei geht es darum, dass bei bestimmten Systemen die Parallelisierung von R3trans nicht genutzt wird, weil im Quellrelease die tabelle TRBAT3 nicht existiert. Im Endeffekt kann dieses Performanceproblem bei allen Quellsystemen mit einem Kernel unterhalb von 7.40 passieren. Es lohnt sich also, hier möglicherweise zu prüfen. Wo das Problem genau her kommt, erfahren Sie in Note 1127194.

Ausbesserung durch datenbankspezifische Hinweise

Anhand der oben geschilderten Optimierungen haben Sie nun bereits grobe Werte für die vier Prozessparameter festgelegt. Bevor Sie diese jedoch nun „einloggen“ und in die Felder des Software Update Manager eingeben, sollten Sie noch die datenbankspezifischen Restriktionen aus SAP Note 1616401 betrachten, je nach Quelldatenbank Ihres Systems. Ich versuche hier, die aktuellen Ausführungen des SAP Hinweises wiederzugeben. Dem Tuning der Datenbankparameter, was auch teilweise in der Note angesprochen wird, widmen wir eine extra Sektion in diesem Beitrag.

Für MS SQL ist im wesentlichen der MaxDOP Parameter entscheidend. In der SAP Note ist eine schöne Grafik, welche das Finden des richtigen Wertes für Sie komfortabel und einfach macht.

Für Oracle werden Sie lediglich dazu aufgefordert, die Parameter gemäß der einschlägigen SAP Hinweise zu konfigurieren. Diese SAP Hinweise nehmen wir uns in einem datenbankorienteirten Kapitel in diesem Beitrag extra zur Brust. Selbiges gilt für SAP ASE, SAP HANA und MaxDB. Für IBM DB2 hingegen gibt es ein extra IBM Dokument im PDF Format. Auch hieraus werde ich Ausschnitte in diesem Beitrag unterbringen.

Memory-optimized activation

Lassen Sie den Menüpunkt unbedingt aus, wenn Sie eine moderne Hardwarearchitektur haben, wählen Sie ihn an, wenn Sie auf 32bit (z. B. IA32 oder klassische Intel x86) unterwegs sind (SAP Note 1630256)

HANA Quellreleases: Verwenden Sie den SUM10HDB*.SAR

Wenn Sie ein HANA Quellrelease haben, lohnt es sich zu prüfen, ob für Ihre Prozedur der optimierte Software Update Manager SUM10HDB unterstützt wird. Dieser ist speziell für HANA-to-HANA Prozeduren optimiert und reduziert die Laufzeiten, auch wenn ich aktuell nicht mit konkreten Zahlen dienen kann.

Verwenden einer aktuellen Version des SUM

Wie schon an anderer Stelle beim Patchen des Kernels erwähnt, sagt der gesunde Menschenverstand eigentlich: Warum sollten wir einen anderen SUM verwenden als den, den uns der Maintenance Planner in den Download Basket gelegt hat? Der wird sich schon was dabei gedacht haben. Außerdem ist ein SUM SP, das schon länger verfügbar ist, besser durch die Gesamtheit der SAP Kunden getestet. Daher sind mehr Probleme mit diesem SUM SP bekannt. Ich habe lange Zeit auch so argumentiert.

Die historische Erfahrung meinerseits hat jedoch gezeigt, dass es viel öfter sinnvoll ist, vor dem Upgrade eine höhere SUM Version zu nehmen, wenn diese für die geplante Prozedur freigegeben ist (muss geprüft werden), als die ursprünglich durch den Maintenance Planner vorgesehene. Fraglich ist nun die Wahl, ob Sie lieber einen höheren Patchlevel für den ursprünglich geplanten SUM SP, oder geich ein höheres SUM SP (falls verfügbar) herunterladen sollen. Im Zweifel würde ich mich, wenn die Veröffentlichungstermine von Patchlevel und SUM SP nahe beieinander liegen, für das höhere Patchlevel des niedrigeren SPs entscheiden. Das ist dann quasi die Kombination aus beiden Argumentationspunkten, also der Kompromiss.

Selbstverständlich sollten Sie innerhalb der Systemlinie immer den selben SUM verwenden, auch wenn im Laufe des Projektes eine neuere Version heraus kommt.

Optimierung des Table Splittings

Unter Table Splitting versteht man die Aufteilung großer Tabellen auf dem SAP System in mehrere Pakete (Packages, auch Buckets genannt). Das heißt, eine Tabelle wird in mehrere Teile „geschnitten“, die durch mehrere R3load Prozesse parallel importiert werden können. Ihr könnt euch das so vorstellen, dass auf der Zieldatenbank SAP HANA Speicherbereiche für eine Tabelle reserviert werden. Nehmen wir an eine Tabelle ist 100 GB groß und sie wird in drei Buckets aufgeteilt. Dann ist es möglich, auf der Zieldatenbank drei Speicherbereiche zu reservieren, die der Einfachheit halber jeweils 33,33 GB groß sind.

Nun können diese drei Buckets durch drei R3load Prozesse parallel in die SAP HANA Datenbank importiert werden. Dabei werden gleichmäßig die drei Speicherbereiche gefüllt. Am Ende der Prozedur, wenn alle drei Speicherbereiche gefüllt sind – werden die drei Tabellenteile in eine große Tabelle zusammengefügt, was nur einen Bruchteil der Zeit braucht, die es für den Import benötigte. So spart man Zeit.

Sie können es aber auch übertreiben. In je mehr Teile Sie eine Tabelle zerteilen, desto langsamer wird die Lesegeschwindigkeit dieser Tabelle. Sie beschleunigen damit also den Import, verlangsamen aber den Export der Tabelle. Und da eine Migration immer aus der paarweisen Integration von Export und Import besteht, ist das nicht gut. Wie immer im Leben müssen Sie also die goldene Mitte finden.

So weit, so gut. Das Table Splitting kommt immer dann zum Einsatz, wenn große Tabellen über R3load exportiert oder importiert werden sollen – de fakot also bei jeder heterogenen Systemkopie und bei einer Database Migration Option (DMO). Durch die Technik des Table Splittings kann man Zeit sparen.

Nun kann es aber sein, dass das Table Splitting nicht sauber durchgeführt wurde. Teilt man eine große Tabelle, die beispielsweise sagen wir einfach mal 500 GB groß ist, nicht auf – müssen die gesamten 500 GB dieser einen Tabelle von einem einzigen R3load-Prozess importiert werden. Das dauert zwar ewig, ist aber OK, wenn das System ohnehin ausgelastet ist mit R3load Prozessen, weil parallel viele andere Buckets importiert werden können. Nicht OK ist es, wenn alle anderen Buckets schon fertig sind, und die Migration nur noch darauf wartet, dass dieser eine R3load Prozess fertig wird. Dann ist nämlich dieser eine R3load Prozess „das schwächste Glied“ in der Kette. Er verlangsamt die gesamte Migration und verlängert dadurch die technische Downtime.

Wie findet man solche „unsauber getrennte Tabellen“? Im Endeffekt agnz einfach. Am Ende eines DMO Benchmarks oder gar am Ende einer probeweisen Migration auf einer Sandbox gibt es die Möglichkeit einen Graphen zu betrachten. Dieser Graph zeigt, wie viele R3load Prozesse zu welchem Zeitpunkt der Migration gelaufen sind. Wenn Sie von Anfang die Anzahl der R3load Prozesse festlegen und im Laufe der Migration nicht mehr ändern, sollte die Anzahl der gleichzeitig laufenden R3load Prozesse bis kurz zum Ende hin konstant bleiben (OK, nicht ganz konstant, weil immer ein paar Prozesse etwas früher fertig werden und danach neue angestartet werden müsen, während anderenoch arbeiten).

Sie haben genau dann ein Problem, wenn gegen Ende der Migration die graphische Visualisierung der R3load Prozesse „einen Schwanz hinterher zieht“. Je länger dieses „Tail“, desto länger musste auf diese paar restlichen R3load Prozesse gewartet werden und desto schlechter ist daher das Table Splitting verlaufen.

Die Anzahl der R3load Prozesse bleibt solange konstant auf einem hohen Level, is die Auslastung der einzelnen R3load Prozesse unter 90% sinkt. Ist dies der Fall, reiht der Software Update Manager die Tabellen nicht in mehrere parallele, sondern seriell in immer weniger R3load Prozesse ein, bis diese nun eine jeweilige Auslastung von 90% aufweisen. Dadurch möchte man die Auslastung der CPU optimieren. Diese Logik kann aber nach hinten los gehen und zeigt sich dann entsprechend in einem solchen Tail.

Wie optimieren Sie nun das Table Splitting so, dass Sie eine optimale Auslastung der R3load Prozesse und damit einhergehend einen optimalen Parallelisierungsgrad der R3load Prozesse erzielen? Unter der Database Migration Option müssen Sie die Buckets nicht selbst definieren. Das einzige, was Sie beeinflussen können und müssen, ist dem SUM beizubringen, dass er die Buckets nicht nur anhand der Tabellengrößen, sondern auch anhand der Laufzeit der Tabellen optimieren soll. Wie bringen Sie das dem Software Update Manager bei? Indem Sie aus einem SUM-Lauf eines Vorgängersystems (oder eines Systems mit ähnlicher Tabellengrößenverteilung) die Dateien SUM\abap\htdoc\MIGRATE_UT_DUR.XML und SUM\abap\htdoc\MIGRATE_DT_DUR.XML aus dem Vorgänger-SUM in den Download-Ordner des neuen SUM kopieren, in welchem sich die Download-Medien befinden. Alternativ können Sie die Dateien in einen beliebigen Ordner kopieren, auf welchen der <sid>adm Leserechte hat, und dem neuen SUM in der SAPup_add.par über den Parameter /clonepar/clonedurations übergeben. Nun analysiert der SUM bei der Definition der Buckets die Laufzeiten aus diesen Dateien und verbessert dadurch sein Table Splitting.

Wenn wir schon bei der SAPup_add.par sind, können Sie auch gleich noch den Paramter /ORA/update_spacestat setzen, den ich an anderer Stelle erkläre. Die folgenden Paramter müssen Sie in der Datei nur setzen, wenn Ihr R3load des Quellkernels nicht die 7.42er Version aus SAP Note 2118195 – R3load aborts during unicode conversion and declustering erzielt (Kernel 7.42 64 Bit Patch Level 35 oder höher). In der Downtime wird ja schon der neue Kernel verwendet – aber wenn Sie die Parameter auch schon für Ihren 7.20er R3load im Quellkernel setzen, profitert davon die Kopie des Repositorys beim Aufbau der Schatteninstanz.

/clonepar/imp/procenv = HDB_MASSIMPORT=YES # setzen Sie diesen PArameter zusätzlich als Umgebungsvariable auf Betriebssystem-Ebene
/clonepar/indexcreation = after_load
/clonepar/clonedurations = <absolute_path>/MIGRATE_UT_DUR.LST,

Wie die SUM Logik zum Table Splitting genau funktioniert, erfahren Sie in diesem Blog Post der SAP.

was ist nun mit der Systemkopie? Bei einer klassischen SWPM Systemkopie können Sie manuell ein eigenes Table Splitting konfigurieren. Ob das wirklich beser ist als die SUM Logik, ist fraglich. Sie könnten beispielsweise erwägen, statt einer Systemkopie eine DMO without Upgrade zu machen – eine Prozedur, die der SUM mittlerweile anbietet – um vom automatischen Table Splitting zu profitieren.

Wenn Sie hingegen manuell splitten wollen, können Sie zunächst die Laufzeit der Pakete über den Time Analyzer auslesen (SAP note 784118) und danach ein manuelles Splitting vornehmen.

Table Comparison

Der Software Update Manager bietet Ihnen die Möglichkeit, nach Abschluss des Shadow Imports einen kompletten prüfsummenbasierten Vergleich der Tabelleninhalte von Quell- und Zieldatenbank zu vergleichen. Dies bedeutet, dass er sämtliche Datensätze sowohl auf der Quell- als auch auf der Zieldatenbank lesen muss, wenn Sie im Software Update Manager auswählen „Compare content of all tables (target vs. source DB). Dies führt im Endeffekt dazu, dass Sie die Migrationszeit verdoppeln.

Grundsätzlich ist das Feature zum Vergleichen von Tabellen sinnvoll. Schließlich wollen Sie sicherstellen, dass die Daten erfolgreich und konsistent migriert wurden. Jedoch gibt es folgendes zu beachten:

  • Auch wenn Sie die Table Comparison komplett ausschalten, prüft der Software Update Manager zumindest der Anzahl an Zeilen in allen Tabellen, er macht also im Prinzip ein select count(spalte) auf die Tabellen. Die Anzahl der Datensätze mus also so oder so gleich sein
  • Sie haben die Möglichkeit, die prüfsummenbasierte Vergleichsmethode auf geschäftskritische Tabellen, insbesondere aus dem FI-Bereich, einzugrenzen. Dadurch stellen Sie sicher, dass der Vergleich nicht auf unkritischen Tabellen ausgeführt wird, und sparen jede Menge Zeit
  • wirtschaftsprüfungsrelevante Konsistenzprüfungen können Sie auch Prüfung der Konsistenzen durch die FI-relevanten Transaktionen selbst steuern. Eine Liste finden Sie beispielsweise in diesem Bietrag von mir.

Als Kompromiss können Sie eine Full Table Comparison gerne auf einer Kopie des Produktivsystems (auf einer Sandbox oder dem Q System beispielsweise) durchführen. Wenn die Full Table Comparison auf der Sandbox keine CRC-Fehler wirft, ist die Wahrscheinlichkeit, dass bei gleicher Parametrisierung die Prüfsummen der Tabellen in der Produktion gleich sind, hoch.

Systemkopie: Verwenden des Distribution Monitors (DistMon)

Nur für die Systemkopie, nicht für die DMO verfügbar ist die Möglichkeit des Einsatz des Distribution Monitors. Der DistMon kann auf fremden Systemen installiert werden, um zusätzliche Verarbeitungskapazität für R3load-Prozesse bereitzustellen. Das heißt wenn Ihr SAP Anwendungssserver, auf welchem der R3load

Optimierung der Near-Zero Downtime Maintenance (nZDM)

Für die nZDM Version des JavaStacks gibt es mitunter eine zu implementierende Note
2021818 – nZDM Java: Performance improvements

Optimierung der SLT basierenden Replikation der Near Zero Downtime Technologie (NZDT)

Wenn Sie vom Service der NZDT Gebrauch machen, können Sie die Performance der SLT Replikation an bestimmten Stellen verbessern. Erster Schritt ist immer die Prüfung relevanter Performance-Notes für das DMIS addon, historische Beispiele sind etwa 1946402 – NZDT: Poor performance for logging table access in case of DB2/zOS source system und 1988330 – NZDT: Performance issues in logging table creation

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 …

5 Antworten

  1. Stefan R. sagt:

    Dein Blog wird mittlerweile bei Besprechungen vom Kunden als Quellenangabe verwendet. Jetzt wirst du mir langsam zu gefährlich. Gruß dein größter Fan, Stefan R.

  2. Seshagiri sagt:

    Superb document

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.