Ein Ausfall des SAP HANA-Systems kann für ein Unternehmen viele unerwünschte Auswirkungen haben: Geschäftsunterbrechungen, Datenverluste und hohe Kosten für Wiederherstellungsmaßnahmen. Daher sollte das Risiko eines solchen SAP-Ausfalls so gering wie möglich gehalten werden.
In diesem Beitrag geben wir Ihnen Einblicke in unsere Projekte und zeigen, welche Rolle Eigenentwicklungen bei der Auslastung von SAP-Systemen spielen. Wir verraten Ihnen, worauf Sie achten müssen, um Ausfälle zu vermeiden und das Risiko zu minimieren, dass Ihr Geschäft beeinträchtigt wird.
Ein auf einer SAP-HANA-Datenbank basierendes SAP-System ist keine Seltenheit mehr. Doch vor, während und nach der Migration auf SAP HANA gibt es viele Details zu beachten. Mit den empfohlenen Betriebssystemeinstellungen gibt SAP in den jeweiligen SAP NOTES 2205917 und 2292690 die Anforderungen an SLES 12 und RHEL 7 auf Intel-basierter Hardware vor. Diese sind für einen reibungslosen Betrieb unbedingt einzuhalten.
Unsere Analysen bei Kunden
Nach der erfolgreichen Migration auf SAP HANA haben wir bereits viele Kunden mit objektiven Analysen zur Performance sowie anschließenden Handlungsempfehlungen zur Performance-Optimierung unterstützt. An dieser Stelle bietet es sich daher an, Ihnen zunächst einen Einblick in unsere Analysen zu geben, bevor wir auf unsere Handlungsempfehlungen eingehen.
Beispielsweise analysierten wir in einem Projekt bei einem großen deutschen Hoster dessen Cloud-Plattform. Die Rahmenbedingungen: An mehreren Standorten werden weltweit SAP-Systeme für internationale Kunden betrieben, zunehmend klagten einzelne Kunden über langsame Antwortzeiten der Systeme. Ziel des Projekts war es, zunächst zu verifizieren, ob Auffälligkeiten vorliegen, inwiefern die langsamen Antwortzeiten auf die Infrastruktur des Hosters zurückzuführen sind. Falls ja, waren dann Handlungsempfehlungen zur Optimierung zu erarbeiten.
SAP-HANA-Performance mit typischer CPU-Auslastung
In obiger Abbildung sehen Sie eine typische CPU-Auslastung einer SAP-HANA-Datenbank. Innerhalb des grünen Rechtecks steigt die Anzahl an SQL Statements (gelb) an. Zwischen 19:15 Uhr und 19:45 Uhr (blaues Rechteck) ist die CPU-Auslastung (rot) dann leicht angestiegen und die Anzahl an Waiting Threads (grün) nimmt zu. Diese Ressourcenauslastung liegt aber völlig im Rahmen, da die prozentuale CPU-Auslastung über diesen kurzen Zeitraum nicht signifikant angestiegen ist. Allerdings konnten wir auch regelmäßig signifikanten Anstieg der CPU-Auslastung messen, wie in folgender Abbildung zu sehen ist.
SAP-HANA-Performance mit hoher CPU-Auslastung
Die Abbildung zeigt die CPU-Auslastung (rot) in der Spitze zwischen 4:00 Uhr und 4:08 Uhr bei 99 Prozent. Damit korrelieren die Anzahl an Active Threads (blau) und Waiting Threads (grün). Es kommt in diesem kurzen Zeitraum zu einem Ressourcen-Engpass, sodass die Anzahl an Blocked Transactions auf 13 ansteigt. Wir haben daraufhin das SQL Statement analysiert, das zu einer CPU-Auslastung von 99 Prozent beigetragen hat. Erfahrungsgemäß kommt es häufig zu einem Ressourcen-Engpass in SAP-Systemen durch Eigenentwicklungen bzw. deren SQL Statements.
Eigenentwicklungen vs. Standardtransaktionen
Professor Doktor Mielke hat in seiner Publikation „Metriken für Eigenentwicklungen in SAP ERP Systemen“ 2011 aufgezeigt, dass Eigenentwicklungen um den Faktor 2 bis 4 langsamer sind als Standardtransaktionen. 69 Prozent der Eigenentwicklungen werden im Dialog ausgeführt. Die nachfolgende Abbildung veranschaulicht die Ergebnisse seiner Publikation.
Vgl. „Metriken für Eigenentwicklungen in SAP ERP-Systemen“, abgerufen von https://www.user.tu-berlin.de/komm/CD/paper/030632.pdf
Durch die langsame Antwortzeit des Systems geht wertvolle Arbeitszeit der Mitarbeiter verloren – im Jahr fast zwei Arbeitstage pro Mitarbeiter. Und wie kann ein Ressourcen-Engpass auf SAP HANA vermieden werden?
Dafür ist es wichtig, dass die Entwickler geschult sowie die Eigenentwicklungen bzw. SQL Statements speziell für SAP HANA optimiert sind. Nach der Migration auf SAP HANA fällt häufig auf, dass die Antwortzeiten der Eigenentwicklungen angestiegen sind, obwohl davon ausgegangen wurde, dass mit SAP HANA alles schneller wird. Genau das ist bei den meisten Eigenentwicklungen, die ohne Optimierung auf SAP HANA ausgeführt werden, nicht der Fall.
Folgende Abbildung zeigt die nach den einzelnen Modulen aufgeschlüsselten Antwortzeiten auf Oracle und nach der Migration auf HANA: Die Antwortzeit der Eigenentwicklungen (Modul ZZ) ist durchschnittlich langsamer geworden.
Antwortzeiten Oracle vs. HANA pro Modul
Wie Sie die SQL Statements analysieren
Zur Analyse kann beispielsweise im SAP HANA Studio ein „Expensive Statements Trace“ aktiviert werden. Diesen finden Sie nach dem „Log On“ auf das jeweilige System in der Administration Console unter dem Tab „Trace Configuration“. Zur Aktivierung setzen Sie den Status auf „Active“.
Auf Grundlage der fortan gesammelten Daten können die SQL Statements analysiert werden. Entweder im SAP HANA Studio unter dem Tab „Performance“ und dann „Expensive Statements Trace“ oder direkt über SQL Statements. Eine nützliche Sammlung an SQL Statements stellt SAP in der SAP NOTE 1969700 zum Download bereit. Darunter befinden sich Textfiles mit SQL Statements, beispielsweise HANA_SQL_ExpensiveStatements.txt.
Eine weitere Möglichkeit zur speziellen Analyse Ihrer Eigenentwicklungen ist das Custom Development Management Cockpit (CDMC) im SAP Solution Manager. Das CDMC können Sie über die Transaction CNV_CDMC aufrufen.
Darüber hinaus gibt es mit dem SAP HANA Workload Management ab SPS 08 die Möglichkeit, die Ressourcenauslastung zu verwalten. SAP HANA Workload Management ist eine mögliche Maßnahme zur Realisierung eines Quality of Service. Durch Implementierung des Quality of Service können Ressourcen so verwaltet werden, dass allen Systemen die Leistung in einer bestimmten Qualität durchgängig bereitgestellt und garantiert werden kann. Wenn beispielsweise mehrere Systeme die gemeinsame Datenbank SAP HANA nutzen, kann es vorkommen, dass ein System die Ressourcen der SAP HANA so stark auslastet, dass ein anderes System aufgrund der nur noch sehr begrenzten Ressourcen sehr langsame Antwortzeiten zeigt. In obigem Beispiel zur hohen CPU-Auslastung kann durch das SAP HANA Workload Management die CPU-Auslastung des einen Systems mit der nicht-performanten Eigenentwicklung reglementiert werden. Wie Sie das Workload Management in SAP HANA konfigurieren, können Sie in SAP NOTE 2222250 nachlesen.
Warum ist Quality of Service bzw. Workload Management wichtig?
Es ist entscheidend, dass jeder Kunde – sei es ein intern oder extern – seine zugesicherte Leistung erhält. Dafür existieren OLAs bzw. SLAs. Aufgrund der natürlichen Begrenzung verfügbarer Ressourcen muss bei allen Kunden die Leistung reglementiert werden, um auch allen Kunden die zugesicherte Leistung erbringen zu können. Wenn es kein Quality of Service gibt, tritt der am Anfang beschriebene Fall ein, dass Kunden über langsame Antwortzeiten des Systems klagen.
Die simple Ursache hierfür war in dem oben beschriebenen Fall, dass jeder Kunde auf der geteilten Infrastruktur des Hosters beliebig viel Leistung abrufen konnte und ein Kunde die gesamte Infrastruktur so stark in Anspruch nahm, dass für die anderen Kunden nicht mehr ausreichend Ressourcen verfügbar waren, was sich als Ressourcen-Engpass in der Antwortzeit der Systeme bemerkbar machte. Im schlimmsten Fall droht in so einem Fall gar der Systemausfall. Zu dadurch verursachten Systemausfallkosten gibt es eine Studie, durchgeführt von Techconsult im Auftrag von HP:
Darstellung angelehnt an die Techconsult-Studie „Deutscher Mittelstand braucht bessere IT-Support-Services“ im Auftrag von HP
Die Abbildung fasst die Ergebnisse der Studie zusammen: Im Durchschnitt betragen die Systemausfallkosten in einem mittelständischen Unternehmen 380.000 Euro pro Jahr. Zugrunde liegt dabei ein Durchschnitt von 4 Ausfällen mit jeweils 3,8 Stunden und 25.000 Euro Systemausfallkosten pro Stunde. Zu berücksichtigen ist, dass laut Studie die Höhe des Schadens je nach Unternehmensgröße variiere. Zudem sei 39 Prozent der Unternehmen gar nicht bekannt, wie hoch ihr Schaden bei einem Systemausfall von einer Stunde ist.
Fazit: In Anbetracht der Schadenssumme ist es also durchaus empfehlenswert, über die Einführung eines auf OLAs bzw. SLA beruhenden Quality of Service nachzudenken.
Entdecken Sie, wie REALTECH Sie dabei unterstützen kann. Mit unseren Managed Services stellen wir den zuverlässigen Betrieb Ihrer SAP-Systeme sicher.