Skalierung der Datenbankebene, insbesondere von SAP HANA
Überwachung, Monitoring SAP® – und Schnittstellensysteme
Die Einsatzfähigkeit der Datenbank aufrechtzuerhalten ist weniger eine Frage der Performanceoptimierung – vielmehr ist dies Aufgabe der Datenbankadministration; sie wird daher in diesem Buch nicht explizit behandelt. Literatur dazu finden Sie in den Handbüchern zur Datenbankadministration. Erstellen Sie aufgrund dieser Literatur einen auf Ihr Unternehmen abgestimmten Eskalationsplan, der z. B. folgende Fragen umfasst: Welche Maßnahmen stellen sicher, dass ein potenzieller Überlauf der Log-Bereiche und des Dateisystems rechtzeitig erkannt wird? Wie können Sie analysieren, welcher Datenbankfehler aufgetreten ist, wenn das SAP-System steht? Wo befindet sich die Datenbankfehlerprotokolldatei Ihrer Datenbank? Wie heißen die entscheidenden Fehlermeldungen? Was muss getan werden, wenn die Fehlersituation eingetreten ist? Muss das SAP-System bzw. die Datenbank neu gestartet werden? Kann eine solche Fehlersituation auf einem Testsystem simuliert werden?
Von Verdrängungen (Swaps) abzugrenzen sind Invalidierungen, die in der Spalte Swaps nicht enthalten sind. Bei einer Invalidierung wird ein gepuffertes Objekt (z. B. ein Programm oder eine Tabelle) für ungültig erklärt, weil es geändert wurde. Invalidierungen von gepufferten Objekten führen ebenfalls zu einer verminderten Trefferrate und zu Nachladevorgängen von der Datenbank, können aber mit diesem Monitor nicht identifiziert werden. Invalidierungen treten u. a. dann auf, wenn Programme oder Customizing-Einstellungen im produktiven Betrieb geändert oder in ein produktives System transportiert werden. Daher sollten Importe in ein produktives System zu Zeiten mit hoher Last unterbleiben, und stattdessen an ein oder zwei Terminen pro Woche zu Zeiten mit niedriger Systemlast vorgenommen werden. Tabellen, die zu groß für die Pufferung sind, können ebenfalls zu Problemen in den Tabellenpuffern führen. Diesem Thema ist Kapitel 12, »SAP-Pufferung«, gewidmet.
Fehler beheben
Mit HANA-Optimierung werden Ihre eigenen Programme erst richtig schnell. ABAP-Firewall: 92% weniger Aufwand, 98% weniger Kosten. Qualitätsstandards bei internen und externen Entwicklungen setzen. Treffsichere und Ressourcen sparende Analyse und Auswertung. Sicherheits- und Compliance-Risiken: signifikant reduziert.
Alternativ zum Sizing mit dem Quick Sizer bietet SAP häufig ein sogenanntes T-Shirt-Sizing an. Bei dieser Art von Sizing werden typische Hardwarekonfigurationen beschrieben, die Größenkategorien wie S, M, L und XL entsprechen – daher auch die Bezeichnung T-Shirt-Sizing. Für diese Konfigurationen wird angegeben, wie viele Benutzer bzw. welchen Durchsatz eine bestimmte Konfiguration tragen kann. Ein Beispiel für ein T-Shirt- Sizing ist das Sizing für SAP Enterprise Point-of-Sale (POS). Die Sizing- Guidelines finden Sie im SAP Support Portal unter http://service.sap.com/ sizing > Sizing Guidelines > Industries. Dort finden Sie u. a. die folgenden Angaben für eine mittelgroße Installation mit 100 angeschlossenen Terminals: 800 SAPS und 1 GB Hauptspeicher für den Applikationsserver, 100 SAPS und 1 GB Hauptspeicher für die Messaging-Middleware sowie 400 SAPS und 1 GB Hauptspeicher für die Datenbankinstanz. Bitte beachten Sie, dass diese Zahlen nur ein Beispiel darstellen. Sie können veralten und zeigen auch nur einen kleinen Ausschnitt der Sizing-Anleitung. Sie dürfen daher nicht als Grundlage für ein Sizing verwendet werden.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Im nächsten Schritt werden die Ausgabeparameter definiert.
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.