Exklusive Datenbanksperren
Sehr gute Informatikkenntnisse – speziell SAP-Lösungen
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.
Einerseits sollen die Sachbearbeiter im Personal (oder andere Personal-Funktionsträger) ihre wichtige Arbeit erledigen können. Auf der anderen Seite ist der Schutz der persönlichen Daten der eigenen Mitarbeiter eine der wichtigsten Aufgaben des Berechtigungswesens. Jeder Fehler in diesem Bereich kann dafür sorgen, dass die Datenschutzbeauftragten des Unternehmens sich die Hände über dem Kopf zusammenschlagen. Aus diesem Grund werden zur Zeit Tools entwickelt, welche im Bereich HR-Berechtigungen Absicherung und Übersicht verschaffen sollen. Die Grundidee ist eine klare Übersicht, aus der ersichtlich wird, auf welche Daten bestimmte User im SAP-System zugreifen dürfen. Darauf aufbauend können automatische Prüfungen entwickelt werden, welche im Hintergrund ablaufen und regelmäßig überprüfen, ob durch Änderungen an den Berechtigungen im HR-Bereich kritische Lücken entstanden sind. Durch die Verwendung eines solchen Tools kann gerade im HR-Berechtigungsumfeld mehr Sicherheit geschaffen werden. Zudem ist insbesondere die Möglichkeit der Überblickfunktion für alle Beteiligten sehr angenehm und entlastend. Weitere Lektüre Dieser Blogbeitrag ist dazu gedacht aufzuzeigen, was bereits jetzt im Bereich der Security Automation möglich ist. Das Thema wird uns im SAP-Bereich in den nächsten Jahren immer mehr begleiten. Daher ist es empfehlenswert, sich bereits jetzt Gedanken zu machen, wie das eigene Unternehmen in Bezug auf Security Automation vorbereitet ist. Falls Sie sich für die Aufstellung und Vorbereitung eines Unternehmens auch außerhalb des Security-Bereichs interessieren, kann ich Ihnen das Buch 'Consulting Y' von Ferdinando Piumelli (Geschäftsführer der mindsquare GmbH) empfehlen. Als Strategieberater von führenden DAX30-Unternehmen beschreibt Herr Piumelli in diesem Buch seine Beobachtungen und Erfahrungen der digitalen Transformation. Dabei richtet er seinen Blick auf die nähere Zukunft, welche im Sinne der digitalen Revolution einen großen Einfluss auf die großen Unternehmen und die Wirtschaft der Welt nehmen wird.
Identifizierung eines CPU-Engpasses
Benutzerkontextdaten werden von Dialog-Workprozessen in folgender Reihenfolge abgelegt: Beim Start einer Transaktion wird der Benutzerkontext bis zu einer Größe von ztta/roll_first im lokalen Roll-Bereich des Workprozesses gespeichert. ztta/roll_first soll auf 1 (Byte) gesetzt werden. Dies bedeutet, dass zunächst überhaupt kein SAP Roll Memory belegt werden soll. Aus technischen Gründen werden allerdings immer administrative Daten in der Größenordnung von bis zu 100 kB im lokalen Roll-Bereich des Workprozesses abgelegt, auch wenn ztta/roll_first = 1 ist. Wächst die Größe des Benutzerkontextes über den Wert ztta/roll_first hinaus, werden die Daten im SAP Extended Memory abgelegt. Ist der SAP Extended Memory erschöpft oder erreicht der Benutzerkontext die Quote von ztta/roll_extension*, wird der verbleibende Rest des lokalen Roll-Bereichs bis zu einer Größe von ztta/roll_area genutzt. Wächst der Kontext weiter an und übersteigt der Speicherbedarf auch diesen Wert, allokiert der Workprozess SAP Heap Memory nach Bedarf. Die Verwendung von SAP Heap Memory hat den Nachteil, dass dieser Speicher lokal ist und auch nicht mehr – wie beim SAP Roll Memory – in einen globalen Speicherbereich kopiert (gerollt) werden kann. Wenn ein Prozess SAP Heap Memory allokiert, kann der Kontext nicht mehr zu einem anderen Workprozess übertragen werden. Der Workprozess bleibt einem Benutzer exklusiv zugeordnet. Diesen Zustand bezeichnet man als PRIV-Modus (Private Mode). In der Workprozess-Übersicht wird dieser Zustand in den Spalten Status und Grund durch die Werte hält bzw. PRIV dokumentiert.
Grundlagen des Sizings sind detaillierte Erfahrungswerte über den Ressourcenbedarf von Benutzern und Transaktionen. Diese Erfahrungswerte veralten schnell angesichts neuer Applikations- und Rechnergenerationen, daher fokussieren wir uns in diesem Kapitel auf die Prozesse und Werkzeuge. Bei einem Sizing-Projekt sind mehrere Parteien im Boot: Das Kundenprojekt stellt das Mengengerüst, sprich die Anforderungen an konkurrierende Benutzer, Durchsatz bestimmter Transaktionen und erwartetes Datenvolumen, zusammen. Die Experten des Hardwarepartners erstellen ein Hardwareangebot – wenn nötig, unter Rückgriff auf Experten der SAP. Schließlich benötigen Sie als Projektleiter oder -mitarbeiter das Wissen über den prinzipiellen Sizing-Prozess, um unterschiedliche Sizing-Angebote und Aussagen kompetent vergleichen und bewerten zu können, die Möglichkeiten, Risiken und Grenzen einer Sizing-Aussage zu verstehen und schließlich eine fundierte Entscheidung zwischen den Hardwareangeboten zu treffen.
Etliche Aufgaben der SAP Basis können mit "Shortcut for SAP Systems" einfacher und schneller erledigt werden.
Bei einem Zugriff auf einen fremden Speicher treten Verzögerungen im Vergleich zum Zugriff auf den lokalen Speicher auf.
Denn das Management der zugrundeliegenden SAP-NetWeaver- und SAP-HANA-Plattform ist mittlerweile äußerst komplex.