Unser Beratungsportfolio
Folgende Maßnahmen haben eine mittlere Priorität, d. h., die entsprechenden Parameter sollten innerhalb weniger Tage angepasst werden: TTAB-, FTAB-, SNTAB- und IRDB-Puffer, Roll-Puffer, Programmpuffer und Tabellenpuffer
Mit der Workprozess-Übersicht können Sie anhand der Felder Dauer, Status, Info Hält, Aktuelle Aktion und Info zur aktuellen Aktion die Aktionen der SAP-Workprozesse überwachen. Folgende Punkte sollten Sie beachten: Sind auf jeder SAP-Instanz ausreichend freie (Status: wartet) Workprozesse jeden Typs vorhanden? Gibt es Programme, die einen Workprozess sehr lange belegen (Feld Dauer)? In diesem Fall sollten Sie die Benutzer auf dieses Programm ansprechen und klären, ob das Programm fehlerfrei arbeitet. Eventuell sollten Sie es für eine detaillierte Programmanalyse vorsehen. Prüfen Sie anhand der Felder Status, Info Hält, Aktuelle Aktion und Info zur aktuellen Aktion, ob mehr als 20 % der Workprozesse die gleiche Aktion ausführen. Die wichtigsten Probleme sind dabei: Befinden sich mehr als 20 % der Workprozesse im PRIV-Modus oder beim Roll-in oder Roll-out, deutet dies auf ein Problem mit der SAPSpeicherkonfiguration hin. Befinden sich mehr als 40 % der Workprozesse in einer Datenbankaktion wie Sequenzielles Lesen, Commit etc., deutet dies auf ein Datenbankproblem hin. Lesen mehr als 20 % der Workprozesse gleichzeitig von derselben Tabelle, deutet dies auf ein Problem mit einer teuren SQL-Anweisung, eventuell aber auch auf eine Sperrsituation in der Datenbank (Exclusive Lockwaits) hin.
Die Trefferraten für die SAP-Puffer sollten 98 % oder mehr betragen. (Ausnahme: Für den Programmpuffer, den Einzelsatzpuffer und den Export-/Importpuffer können geringere Trefferquoten toleriert werden.) In einem produktiven System sollten keine Verdrängungen in den Puffern auftreten. Ist dies dennoch der Fall, sollte die Puffergröße bzw. die maximale Anzahl der Einträge erhöht werden. Ausnahme ist auch hier der Programmpuffer, für den etwa 10.000 Verdrängungen pro Tag toleriert werden können. Es sollten sowohl ausreichend Speicherplatz als auch ausreichend freie Einträge im Puffer vorhanden sein, um Verdrängungen in Zukunft zu vermeiden.
Patching
Neue Risiken in SAP HANA: Neben den bekannten Risiken bestehen auch neue Risiken durch die Verwendung von SAP HANA. Ein sehr gutes Beispiel sind häufig verwendete Webanwendungen, die etwas neues im SAP Bereich darstellen. HANA Systeme bestehen im Gegensatz zu einem SAP ERP System hauptsächlich aus Webanwendungen, die in den vorherigen Versionen eher als optional zu betrachtet wurden. Diese Webanwendungen können durch diverse Suchmaschinen im Internet aufgefunden werden. Das gilt übrigens auch für das SAP Portal oder Netweaver. Es gibt URL-Schemata die zum Auffinden des Systems beitragen. Dies gilt auch für andere SAP Systeme, die Webanwendungen verwenden. Damit ist auch die neue Technologie für typische Webangriffe verwundbar. Zu nennen sind hier SQL Injection, ABAP Code Injection oder XSS. Alle Risiken, die für ein normales SAP System bekannt sind, gelten auch für ein SAP-HANA System. Die Daten werden unverschlüsselt im RAM abgelegt. Erst dadurch gewinnt das System diesen Geschwindigkeitsvorteil. Hieraus resultieren Risiken wie ein auslesen durch Memory-scrapingmalware. Diese greifen Daten im Arbeitsspeicher ab. Verschlüsselung kostet Performance, daher wird diese standardmäßig nicht verwendet. Gerade während einer Migration läuft HANA in einem Parallelsystem, daher kommt zu Ihrer Landschaft mindestens ein neues System dazu. Beachten Sie darüber hinaus: HANA hat eigene Tools und eigene Einstellmöglichkeiten die gekannt und konfiguriert werden müssen. Unterm Strich muss beim Betrieb des Systems einfach mehr beachtet werden. Viele Einstellmöglichkeiten resultieren nicht selten in mehr Fehlern. Drei - Punkte - Plan zur HANA Sicherheit 1) Rollen und Berechtigungen Im einem bisherigen SAP System zählen Rollen und Berechtigungen sicherlich auch zu den Hauptsäulen eines sicheren Systems. Rollen und Berechtigungen funktionieren aber anders in einem HANA System. Es gibt zwei Nutzertypen: 1) Standard (eingeschränkt): Mit diesem Nutzertyp gibt es verschiedene Zugriffsmethoden auf die Datenbank. Hier werden beispielsweise die Technologien JDBC oder HTTP verwendet, um zwei Beispiele zu nennen.
Der Performancekollektor läuft periodisch und sammelt Daten zur Performance. Dieses Programm steht oft bei der Gesamtantwortzeit weit oben in der Liste der teuren Programme. Allerdings erkennt man in den Spalten S CPUZeit und S DB-Zeit, dass dieses Programm nur sehr wenig CPU- und Datenbankzeit benötigt. Die meiste Zeit wartet es im Workprozess darauf, dass ihm Performancedaten gemeldet werden.
Tools wie z.B. "Shortcut for SAP Systems" sind bei der Basisadministration extrem nützlich.
Erst dadurch gewinnt das System diesen Geschwindigkeitsvorteil.
Beispielsweise bei unternehmenskritischen Systemen.