SM66 Workprozesse aller Instanzen
Queue einspielen
Das Hauptspeicher-Sizing für eine SAP-HANA-Datenbank unterscheidet sich grundlegend vom Sizing für eine traditionelle Datenbank. Beim traditionellen Sizing geht man von der Anzahl der Benutzer oder Transaktionen aus, multipliziert diese mit einem Gewichtungsfaktor und errechnet daraus (über den CPU-Bedarf) den Hauptspeicherbedarf. Diese Methode des Sizings geht also davon aus, dass ein Benutzer oder eine Transaktion eine gewisse Hauptspeichergröße benötigt, um die Daten, auf die er/sie häufig zugreift, im Hauptspeicher zu halten. Die absolute Größe der Datenbank spielt beim Hauptspeicher-Sizing-Ansatz für einen traditionellen Datenbankserver nur eine untergeordnete Rolle. Im Gegensatz dazu berechnet sich das Hauptspeicher-Sizing für eine SAP-HANA-Datenbank primär aus der Größe der Datenbank, denn diese soll ja im Hauptspeicher gehalten werden. Das SAP-HANA-Sizing für eine Neuinstallation können Sie im Quick Sizer analog zu einem Projekt für eine traditionelle Datenbank durchführen.
SAP bietet allen Kunden im Rahmen ihres Softwarewartungsvertrags einen SAP GoingLive Check an. Dieser Service besteht aus mehreren Terminen (Sessions), bei denen sich Mitarbeiter von SAP oder ihrer Servicepartner remote an Ihrem System anmelden und dieses durchchecken. Der Service findet im Zeitraum von zwei Monaten vor Produktivstart statt. Ein Sizing- Plausibilitätscheck ist im SAP GoingLive Check enthalten. Dabei wird kein neues Sizing erstellt, sondern man vergibt lediglich eine Bewertung bezüglich der Aussage, ob die bereits installierte bzw. geplante Hardware die prognostizierte Last bewältigen wird.
Besuch des Kurses "SAP HANA - Einführung
Prüfen Sie, ob die Datendatei erzeugt wurde. Wenn sie nicht erzeugt wurde, dann stellen Sie sicher, daß in den SPAM-Einstellungen [Seite 10] Datenfile neu erzeugen eingeschaltet ist. Weitere Informationen finden Sie in Hinweis 70752. ADD_TO_BUFFER In diesem Schritt wird die Queue in den Transportpuffer Ihres Systems gestellt.
Das sogenannte Service Level Management (SLM) dient der langfristigen Überwachung und Optimierung. Es wird bereits von vielen IT-Organisationen zum Management der Beziehungen zwischen den einzelnen Service-providern und dem Geschäftsprozessinhaber eingesetzt. Als Service Level Management bezeichnet man eine strukturierte, proaktive Methode, die das Ziel hat, den Benutzern einer IT-Anwendung ein adäquates Serviceniveau zu garantieren – in Übereinstimmung mit den betriebswirtschaftlichen Zielen des Auftraggebers und bei optimalen Kosten. Diese Methode beinhaltet klar definierte, überprüfbare Ziele und eine klare Kommunikation zwischen den Geschäftsprozessinhabern und den Betreibern einer Lösung (dies können für Server, Datenbanken, Netzwerke etc. mehrere interne oder externe Betreiber sein). Das Service Level Management besteht zunächst aus einem Service Level Agreement, in dem die oben zu erreichenden Ziele im Hinblick auf Verfügbarkeit, Performance, Korrektheit und Sicherheit definiert werden und auch festgelegt wird, wie das Erreichen dieser Ziele gemessen und kommuniziert werden soll. Das Service Level Reporting berichtet über die Zielerreichung in einem festgelegten Zeitraum. Primäres Ziel des Service Level Reportings ist es also, festzustellen, ob die festgelegten Betriebsziele erreicht wurden, und mögliches Optimierungspotenzial aufzuzeigen.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Der Standardwert der SAP sollte nicht unterschritten werden; auf einzelnen Instanzen sollte es auch möglich sein, länger laufende Programme auszuführen.
Physische Lesezugriffe - Anzahl der Lesezugriffe auf die Festplatte.