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.
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.
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).
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.
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
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
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.
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.
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.
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.
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.
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.
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:
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
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.
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.
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:
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.
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:
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.
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:
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 .
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.
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
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.
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.
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.
| Note | Beschreibung |
| 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 |
| 1269911 | Chained Row Optimierung |
| https://docs.oracle.com/cd/E18283_01/network.112/e10836/performance.htm | Netzwerkparametertuning |
| 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 |
| Note | Beschreibung |
| 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 |
| Note | Beschreibung |
| 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 |
| Note | Beschreibung |
| 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 |
| Note | Beschreibung |
| 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. |
| Note | Beschreibung |
| 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 |
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.
| Konfigurationsfile | Sektion | Parameter | Wert |
| indexserver.ini | mergedog | load_balancing_func | „LCC / 2“ |
| indexserver.ini | mergedog | token_per_table | <physikalische CPU Kerne auf dem System> / 2 (aber niemals görßer als 256) |
| indexserver.ini | indexing | parallel_merge_threads | <physikalische CPU Kerne auf dem System> / 2 (aber niemals görßer als 256) |
| indexserver.ini | indexing | parallel_merge_part_threads | <physikalische CPU Kerne auf dem System> / 2 (aber niemals görßer als 256) |
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.
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.
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.
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.
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.
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.
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.
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.
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
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).
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 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
Die R3load Prozesse für die DOWNTIME werden für folgendes genutzt
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)
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.
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.
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.
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:
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.
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
Für die nZDM Version des JavaStacks gibt es mitunter eine zu implementierende Note
2021818 – nZDM Java: Performance improvements
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
Optimizing DMO Performance, Increasing DMO Performance, DMO Background on Table Splitting, DMO Optimizing System Downtime
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.
In SAP Projekten gibt es häufig Probleme bei der Übersetzung von SAP-spezifischen Begrifflichkeiten in den Geschäftsmodulen. Häufig spucken die typischen…
Der Software Update Manager (SUM) liefert neben der klassischen Upgrade-Funktionalität mittlerweile eine Vielzahl an unterschiedlichen Approaches für die Kombination aus…
Im Zuge einer SAP S/4HANA System Conversion sind diverse geschäftslogische Vorbereitungen zu treffen, bevor Sie die Konvertierung durchführen. Viele dieser…
Der sogenannte Side-by-Side Ansatz bezeichnet eine architektonische Nutzung einer SAP HANA Datenbank als Beschleuniger eines klassischen SAP-Systems, welches noch auf…
Mit SAP HANA 2.0 SP01 ist der Betriebsmodus der Multi Database Containers (MDC) der einzige aktiv empfohlene Betriebsmodus, mit der…
Oft werde ich gefragt, was denn die einzelnen Sicherheitseinstellungen bei der Erstellung und Konfiguration von Web Services bedeuten, insbesondere wenn…