Sizing der Sperrtabelle
Verwendung
Für einen real-time-fähigen InfoCube sind für die Dauer einer Sperroperation keine anderen Zugriffe auf den BI-Sperrserver möglich. Der Sperrserver ist also eine ggf. knappe Ressource. Daher ist es erforderlich, bei der Implementierung von Planungsanwendungen in einem BI-System ein Design zu wählen, das die Anzahl und Größe der Selektionen möglichst klein hält. Je kleiner die Sperrtabelle ist, desto besser sind die Antwortzeiten des Sperrservers.
Sie können die Sperrtabelle dadurch verkleinern, dass Sie Merkmale, die die Selektion nicht separieren, aus der Liste der für die Sperren relevanten Merkmale eines real-time-fähigen InfoCubes entfernen. Dazu gehören Merkmale, die für alle Benutzer gleiche oder überlappende Werte annehmen. Weitere Informationen finden Sie unter Auswahl der Sperrmerkmale.
Die folgenden Abschnitte enthalten Informationen zum Sizing der Sperrtabelle für die BI Integrierte Planung. Es wird erläutert, wie man den benötigten Speicherverbrauch ermitteln und dann die entsprechenden Profilparameter einstellen kann.
Weitere Informationen über die verschiedenen Möglichkeiten, die Sperrtabelle abzulegen, finden Sie unter Ablegen der Sperrtabelle.
Aktuelle Sizing-Informationen finden Sie im SAP-Hinweis 928044 BI Sperrserver.
Integration
Die aktuell gesetzten Werte können Sie in der Pflege der Profilparameter (Transaktionscode RZ11) anzeigen lassen.
Funktionsumfang
Ablage der Sperrtabelle im SAP Standard-Sperrserver
Die Größe der Sperrtabelle des SAP Standard-Sperrservers kann über den Profilparameter enque/table_size eingestellt werden.
Die Einstellung
enque/table_size = 25.000
sollte für die meisten Systeme ausreichend sein, in denen die BI Planung verwendet wird.
Genauer kann die Anzahl der benötigten Sperrsätze wie folgt abgeschätzt werden:
● Die Anzahl der aktiv genutzten InfoCubes sei IC.
● Die durchschnittliche Anzahl der Zeilen in der Selektionstabelle sei Rec. Diese Anzahl können Sie für einen repräsentativen Benutzer über die Pflege der Sperreinstellungen für die Planung (Transaktionscode RSPLSE) ermitteln, indem Sie sich auf der Registerkarte Anzeige der aktiven Sperren die gesperrten Selektionen anzeigen lassen.
● Die Anzahl der Sperranfragen pro Benutzer sei LReq. Diese Anzahl hängt vom Design der Planungsanwendung ab: Anzahl der eingabebereiten Queries, Anzahl der verwendeten Planungsfunktionen und wie oft diese Komponenten Daten im Änderungsmodus anfragen.
● Die Anzahl der aktiven Benutzer sei U.
● Der Komprimierungsfaktor für eine Selektionstabelle sei Compr. Dieser Faktor ist zwischen 5 und 10.
Die Anzahl der Sperrsätze NLCK ist dann:
NLCK = IC * U * LReq * Rec / Compr |
Um festzustellen, wie viele Sperrsätze bei dem aktuellen Wert des Profilparameters enque/table_size in der Sperrtabelle maximal abgelegt werden können, wählen Sie in der SAP-Sperrverwaltung (Transaktionscode SM12) Zusätze ® Statistik. Sie finden den Wert in der Zeile Sperreinträge Tabelle, Groesse.
Ablage der Sperrtabelle im Shared Object Memory eines Applikationsservers (Voreinstellung des Systems)
Die Größe der Sperrtabelle im Shared Object Memory eines Applikationsservers kann über den Profilparameter abap/shared_objects_size_MB eingestellt werden.
Die Einstellung
abap/shared_objects_size_MB = 200
sollte für die meisten Systeme ausreichend sein, in denen die BI Planung verwendet wird.
Genauer kann die Anzahl der benötigten Sperrsätze wie folgt abgeschätzt werden:
● Die Anzahl der aktiv genutzten InfoCubes sei IC.
● Die durchschnittliche Anzahl der Zeilen in der Selektionstabelle sei Rec. Die eigentlichen Selektionen liegen zweimal im Shared Object Memory: einmal optimiert für Suchzugriffe pro Merkmal und einmal optimiert für Zugriffe pro gesperrter Selektion (Sekundärindex). Die benutzte DDIC-Struktur hat eine Breite von 207 Zeichen, also von 207 Byte (bzw. 414 Byte in Unicode-Systemen). Man kann mit etwa 1KByte pro Zeile der Selektionstabelle rechnen.
● Die Anzahl der Sperranfragen pro Benutzer sei LReq. Diese Anzahl hängt vom Design der Planungsanwendung ab: Anzahl der eingabebereiten Queries, Anzahl der verwendeten Planungsfunktionen und wie oft diese Komponenten Daten im Änderungsmodus anfragen.
● Die Anzahl der aktiven Benutzer sei U.
Die Anzahl der Sperrsätze NLCK ist dann:
NLCK = IC * U * LReq * Rec |
Daraus ergibt sich der benötigte Speicher in Kilobyte durch Multiplikation von NLCK mit dem Faktor 2, denn bei einer Sperranfrage zieht das System für die Dauer einer Kollisionsprüfung eine Kopie der bereits gesperrten Selektionen.
Informationen über den aktuell benötigten Speicher für den BI Sperrserver finden Sie in der Shared Object Gebietsverwaltung (Transaktionscode SHMA): Rufen Sie diese Transaktion auf dem Server mit der BI Sperrtabelle auf; verwenden Sie als 'Gebiet' CL_RSPLS_ENQ_AREA.
Ablage der Sperrtabelle im SAP liveCache
Wenn Sie den SAP liveCache im BI Sperrserver verwenden möchten, finden Sie entsprechende Sizing-Informationen im SAP-Hinweis 816730.