Softwareinstallation
SM02 Systemnachricht erstellen
Das Mandantenkonzept von SAP ermöglicht es, ein SAP-System in mehrere logische Subsysteme - Mandanten - zu unterteilen. Diese Subsysteme können wie eigene Systeme betriebswirtschaftlich voneinander unabhängig und isoliert genutzt werden. Aber wie sind mandantenunabhängige Transaktionen zu behandeln? Wie können Sie verhindern, dass ein Mandant auf den anderen zugreifen kann und warum sollten Sie das verhindern wollen? In diesem Blog-Beitrag werde ich Ihnen diese Fragen beantworten und dabei einige Negativ-Beispiele diskutieren. Warum ist es wichtig mandantenunabhängige Transaktionen gesondert zu betrachten? Stellen Sie sich vor, dass jeder Ihrer Mitarbeiter einen Mandanten im Produktivsystem anlegen oder ändern darf, oder noch schlimmer - beides. Das Anlegen und Ändern eines Mandanten im Produktivsystem erfolgt autorisiert und dokumentiert – Sie fragen sich, was dabei schon schiefgehen könnte? Das Risiko in diesem Fall ist ein Verlust der Integrität von System und Daten, der Verlust der Vertraulichkeit: Mit jedem neu angelegten Mandanten lebt der Superuser SAP* mit seinen umfassenden, auch mandantenübergreifenden Rechten und dem vergebenen Standardpasswort auf.
Die Ebene der SAP-Applikationsplattform setzt auf der IT-Infrastruktur (1) auf. Diese ist nicht mit der eigentlichen Anwendungslösung oder Fachanwendung zu verwechseln. Im Autobeispiel ist das der Bereich, um den sich der KFZ-Mechaniker kümmert, nämlich Ölwechsel, Bremsen, Reifen, Elektrik und vieles mehr. Damit ist sowohl die Straßeninfrastruktur (Ebene 1), als auch die Nutzung der Annehmlichkeiten für die Fahrer und Mitfahrer (Ebene 3) sichergestellt.
Lösung: Benutzerabgleich durchführen
Im Rahmen der SAP-HANA-Migration spielt der SQL-Monitor eine wichtige Rolle bei der Optimierung von kundeneigenem Coding. Da der Monitor datenbankunabhängig ist, kann er im System vor der SAP-HANA-Migration verwendet werden. Der Monitor verknüpft die tatsächliche Last mit Checks des Code Inspectors (siehe Abschnitt 5.4, »Code Inspector«) und der Bewertung, welche Programmoptimierungen auf einer SAP-HANA-Datenbank besonders wichtig sind, und stellt daraufhin eine priorisierte Liste mit Optimierungsempfehlungen auf. Die Liste, in der die SQLM-Daten mit den Ergebnissen des Code Inspectors verknüpft werden können, ist in einer eigenen Transaktion (Transaktionscode SWLT) implementiert. Weitere Informationen finden Sie in SAP-Hinweis 1912445.
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.
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
Beachten Sie, dass auch betriebssystemspezifische Beschränkungen (z. B. die maximale Größe des allokierbaren Shared Memorys bzw. der maximale Adressraum) die Größe des allokierbaren Speichers limitieren.
Die aggregierten Daten werden in der Datenbank gespeichert.