Sizing-Schritte bei Versionswechsel
Support Packages in weitere Systeme einspielen
Im weiteren Verlauf des Projekts holen Sie ein oder mehrere Angebote von Hardwarepartnern ein. Die Hardwarepartner erstellen das Hardware-Sizing, da nur sie die Leistungsfähigkeit ihrer Hardware bewerten können. Sofern nötig, greifen die Hardwarepartner über ihre SAP Competence Center auf die entsprechenden Sizing-Experten der SAP zurück. Um den Sizing-Prozess zu vereinfachen, hat SAP folgendes Standardverfahren definiert: Legen Sie zu Ihrem Einführungsprojekt ein Sizing-Projekt im Quick Sizer im SAP Support Portal an. Dort legen Sie die für das Sizing notwendigen Daten ab. Unterstützt der Quick Sizer das Sizing für die ausgewählten Prozesse nicht, verwenden Sie die entsprechenden Sizing-Guidelines. Anschließend gewähren Sie den Hardwarepartnern, von denen Sie ein Sizing-Angebot wünschen, Zugriff auf dieses Sizing-Projekt im SAP Support Portal, indem Sie ihnen das Kennwort für das entsprechende Projekt mitteilen. Die Links zu den jeweiligen Internetseiten der Hardwarepartner finden Sie ebenfalls im Quick Sizer. Die Hardwarepartner erstellen nun aufgrund der von Ihnen hinterlegten Daten ein konkretes Hardwareangebot.
Um Innovation im Unternehmen voranzutreiben, ist es notwendig, ein eigenes Team oder einige Experten zu etablieren, deren anerkannte Aufgabe es ist, Forschungsprojekte und PoCs voranzutreiben, sich diesbezüglich permanent weiterzubilden, Innovationsvorschläge zu erarbeiten und diese in die Gremien einzubringen. Sie sind daher vom operativen Betrieb weitestgehend ausgenommen. AUFBAU EINES TESTLABORATORIUMS Fortführend ist es notwendig, neben den Ressourcen auch die Rahmenbedingungen zur Durchführung der Forschungs- und Pilotprojekte zu schaffen. Hierzu wird empfohlen, ein Testlaboratorium mit möglichst wenigen Einschränkungen hinsichtlich Unternehmensstandards einzurichten. Diese sind oftmals so massiv, dass ein schnelles und brauchbares Umsetzen von Pilotprojekten stark behindert oder komplett unterbunden wird.
Vergrößerung der Last bei geändertem Applikationsprofil
Um eine optimale Performance zu erreichen, sollte das Kopieren der Daten beim Kontextwechsel auf ein Minimum beschränkt bleiben, mit anderen Worten, es soll möglichst wenig SAP Roll Memory benutzt werden. Daher wird für alle Betriebssysteme empfohlen, ztta/roll_first = 1 zu setzen. Was passiert nun, wenn der SAP Extended Memory voll belegt ist? In diesem Fall sind zwei Szenarien möglich, die beide nicht performanceoptimal sind: Da der SAP Extended Memory voll belegt ist, werden Benutzerkontexte bis zu einer Größe von ztta/roll_area im lokalen Roll-Bereich abgelegt. Bei jedem Kontextwechsel müssen damit unter Umständen mehrmals Daten in der Größe von mehreren Megabyte kopiert (gerollt) werden; dies führt typischerweise zu Wartesituationen in der Roll-Verwaltung, insbesondere wenn der Roll-Puffer voll ist und Daten in die Roll-Datei geschrieben werden müssen. Erfahrungen zeigen, dass bei großen Applikationsservern mit mehr als 100 Benutzern die Performance in diesen Fällen schlagartig und drastisch einbricht. Um in dieser Situation Abhilfe zu schaffen, kann man den lokalen RollBereich (ztta/roll_area) reduzieren. Wenn der SAP Extended Memory voll belegt ist, wird nur noch wenig Roll Memory verwendet, und die Menge der beim Kontextwechsel zu kopierenden Daten reduziert sich. Stattdessen werden die Kontextdaten im SAP Heap Memory abgelegt – dies hat zur Folge, dass die Workprozesse gar nicht mehr rollen, sondern in den PRIV-Modus gehen, d. h. einem Benutzer zwischen den Transaktionsschritten exklusiv zugeordnet bleiben. Befinden sich zu viele Workprozesse gleichzeitig im PRIV-Modus, stehen dem Dispatcher nicht genügend freie Workprozesse zur Verfügung. Es kann daher zu hohen Dispatcher-Wartezeiten und damit ebenfalls zum Einbruch der Performance kommen.
Falls Sie die Hintergründe überspringen wollen und eine direkte Schritt-für-Schritt-Anleitung bevorzugen, können Sie direkt in den letzten Abschnitt springen. Vorbereitung Für diesen Workaround benötigen Sie vor allem Zugänge auf sowohl das Quellsystem als auch das BW-System. Zusätzlich müssen sie berechtigungstechnisch die Möglichkeit haben, die SE37 aufzurufen und dort Funktionsbausteine auszuführen. Gerade in Produktivsystemen ist dies allerdings eine sehr kritische Berechtigung. Gehen Sie also davon aus, dass sie eventuell einen Firefighter-Nutzer für diese Aktion benötigen. Arbeiten im BW-System Nun, da die Vorbereitungen abgeschlossen sind müssen Sie jeweils auf dem BW-System und auf dem Quellsystem einen FuBa aufrufen, welcher auf der jeweiligen Seite die Verbindung löst. Beginnend auf dem BW-System begeben Sie sich nun in die Transaktion SE37 und rufen den Funktionsbaustein "RSAR_LOGICAL_SYSTEM_DELETE" auf: RSAR_LOGICAL_SYSTEM_DELETE Hier geben Sie nun die benötigten Werte ein. Folgende Tabelle hilft ihnen bei der Ausfüllung: Feld Beschreibung I_LOGSYS Der Logische Name des Quellsystems. Hier wird der Name des Quellsystems eingetragen werden, wie er in der RSA1 zu finden ist. Zusätzlich kann dieser Name auch in der DB-Tabelle TBDLT gesucht werden. I_FORCE_DELETE Boolean, X = Löschen trotz Fehlermeldungen I_NO_TRANSPORT Boolean, X = Diese Änderung soll nicht in nachfolgende Systeme transportiert werden I_NO_AUTHORITY Boolean, X = Ignorieren von Berechtigungsprüfungen Arbeiten im Quellsystem In dem Quellsystem begeben Sie sich nun auch in die Transaktion SE37 und rufen hier den Funktionsbaustein "RSAP_BIW_DISCONNECT" auf: Folgendes sind die Beschreibungen zu den jeweiligen Feldern. Diese können in der Quellsystem- Verbindungstabelle RSBASIDOC entnommen werden Feld Beschreibung I_BIW_LOGSYS Der logische Name des BW-Systems. In der Tabelle RSBASIDOC ist der richtige Wert in der Spalte "RLOGSYS" zu finden. I_OLTP_LOGSYS Der logische Name des Quellsystems. Die Spalte "SLOGSYS" in der Tabelle RSBASIDOC. I_FORCE_DELETE Der logische Name des BW-Systems. In der Tabelle RSBASIDOC ist der richtige Wert in der Spalte "RLOGSYS" zu finden. Abschluss Im Endeffekt müssen Sie also jeweils im BW- und Quellsystem den jeweiligen Funktionsbaustein aufrufen, die Parameter ausfüllen und den Funktionsbaustein ausführen.
Tools wie "Shortcut for SAP Systems" ergänzen fehlende Funktionen im Bereich der SAP Basis.
Eine Verkleidung, die ihm alle notwendigen Berechtigungen gibt, die er für seinen Schwindel benötigt.
Die Notwendigkeit der Rezertifizierung - Szenarien: Beispiel 1: Das „Azubi Problem“ Stellen Sie sich folgendes Szenario vor: Ein neuer Mitarbeiter (beispielsweise ein Azubi oder Trainee) durchläuft im Rahmen seiner Einarbeitung verschiedene Abteilungen und arbeitet in verschiedenen Projekten mit.