Anforderungen an ein Überwachungs- und Optimierungskonzept
Backup/Restore und Desaster Recovery
Wenn Sie das CPU-Auslastungsprofil einer SAP-HANA- mit dem einer traditionellen Datenbank vergleichen, werden Sie charakteristische Unterschiede bemerken: Für SAP HANA werden Sie häufig kurzzeitige Lastspitzen bemerken, bei denen die CPU zu 100 % ausgelastet ist. Dieses Verhalten ergibt sich aus der Tatsache, dass SAP HANA Anfragen massiv parallelisiert und dabei kurzzeitig alle Prozessoren vollständig belegt. Kurzzeitige Lastspitzen sind also nicht automatisch als CPU-Engpass zu werten. Im Gegensatz beobachtet man bei traditionellen Datenbanken ein eher geglättetes Lastprofil, bei dem Auslastungen zu 100 % bei Normalbetrieb nicht zu beobachten sind.
Natürlich sind die Zahlen in Abbildung 1.6 als ungefähre Größenordnungen zu verstehen. Experten mögen die Zahlen nach oben oder unten korrigieren. Auch ergeben sich durch neue Technologien maßgebliche Verschiebungen, z. B. durch SD-Festplatten (Solid State), die eine viel kürzere Zugriffszeit haben als herkömmliche Festplatten. Dennoch bleibt die Kernaussage richtig, dass sich die unterschiedlichen Kommunikationen oder Prozesse auf völlig unterschiedlichen Zeitskalen abspielen.
Identifizierung eines CPU-Engpasses
Der Erweiterte Speicher enthält also vor allem Nutzerkontexte von verschiedenen Workprozessen, falls diese nicht vollständig in den Rollbereich geladen werden können. Da der Speicherbereich für alle Workprozesse erreichbar ist, können die Workprozesse also auch auf fremde Nutzerkontexte, die hier liegen zugreifen. Außerdem enthält der Erweiterte Speicher einen Globalen Bereich in dem Daten unabhängig von Nutzerkontexten abgelegt werden können. Die Größe des erweiterten Speichers wird bestimmt durch die Werte von em/initial_size_MB und em/global_area_MB. Hierbei bestimmt der erste Parameter die Größe des Speicherbereichs in dem Nutzerkontexte abgelegt werden können und der zweite die Größe des globalen Bereichs. Parameter für den Privaten Speicher Zu guter Letzt gibt es noch den privaten Speicher, welcher nur dann genutzt wird, wenn der Nutzerkontext eines Workprozesses alle anderen ihm zur Verfügung stehenden Speicherbereiche aufgebraucht hat, also seinen Anteil des erweiterten Speichers und seinen Rollbereich. In diesem Fall geht der Workprozess in den PRIV modus. Ein Workprozess im privaten Modus ist an seinen aktuellen Nutzerkontext gebunden und wird erst dann wieder frei für andere Aufgaben, wenn die aktuelle Anfrage abgeschlossen ist. Falls er dabei den ihm zugewiesenen privaten Speicher vollständig aufgebraucht hat, wird der Workprozess anschließend neu gestartet und der Speicher wieder freigegeben. Dieses verhalten wird mit dem Parameter abap/heaplimit kontrolliert. Zeitweise kann der Nutzerkontext der Wert von abap/heaplimit dabei auch überschreiten. Die Parameter abap/heap_area_total, abap/heap_area_dia und abap/heap_area_nondia bestimmen eine obere Grenze für den privaten Speicher. Der Parameter abap/heap_area_total definiert wie viel privaten Speicher alle Workprozesse insgesamt nutzen können. Die Parameter abap/heap_area_dia und abap/heap_area_nondia hingegen bestimmen, wie viel privaten Speicher ein einzelner (Nicht-)Dialog-Workprozess nutzen darf.
Dazu wird eine maximale Bearbeitungszeit festgelegt, die wiederum von der Wichtigkeit der Transaktion für den Geschäftsbetrieb abhängen kann. Als Richtwert nehmen wir 8 Stunden Arbeitszeit (d. h. Zeit innerhalb der Betriebszeit A) für geschäftskritische Transaktionen an. Schließlich wird festgelegt, dass die Anzahl der abgebrochenen Verbuchungen pro Zeitraum im Service Level Report festgehalten werden soll.
Verwenden Sie "Shortcut for SAP Systems", um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Die umfassende Analyse liefert das Schnittmuster und die Roadmap für die weiteren Schritte.
Vielmehr bietet das SAP-System die Möglichkeit, diese Daten über im Hintergrund laufende Schnittstellenprogramme in das System zu übertragen.