Cachemodus 

Definition

Der Cachemodus bestimmt, ob und auf welche Weise die durch den OLAP-Prozessor berechneten Query-Ergebnisse und Navigationszustände als hochkomprimierte Daten in einem Cache gespeichert werden sollen. Der jeweilige Modus kann im Customizing zu einem InfoProvider als Standardwert und im Querymonitor zu einer Query festgelegt werden.

Verwendung

Caching ist ein Mittel zur Verbesserung der Query-Performance. Achten Sie jedoch auf ein Gleichgewicht zwischen Nutzen und Kosten:

●      Nutzen: Caching verbessern die Antwortzeit von Queries

●      Kosten: Aufwand zum Aufbau und Halten der Daten im Cache

Sie können die Cache-Daten im Hauptspeicher, auf einem Applikationsserver oder im Netz verteilt halten. Welche Möglichkeit Sie wählen, hängt von verschiedenen Parametern ab. Zu berücksichtigen sind z.B.:

●      Häufigkeit der Queryabfrage

Wir empfehlen, Queries, die besonders oft abgefragt werden, im Cache zu speichern. Hauptspeicher-Cache ist besonders schnell, in der Größe aber begrenzt; die Auslagerung von gecachten Daten hebt die Begrenztheit des Hauptspeichers zwar auf, hat aber Auswirkungen auf die Performance. Für den persistenten Cache stellt der auf der Datenbank oder in dem Dateisystem zur Verfügung stehende Speicherplatz praktisch keine Einschränkung dar. In Hinsicht auf die Performance ist der direkte Zugriff auf die komprimierten Daten im persistenten Cache ebenfalls sehr leistungsstark.

●      Komplexität der Query

Caching bringt insbesondere bei solchen Queries einen Performance-Gewinn, deren Berechnung einen hohen Aufwand bedingt. Wir empfehlen, vom OLAP-Prozessor aufwendig aufbereitete Daten im Cache zu halten. (Daher ist z.B. der Cachemodus Hauptspeicher Cache ohne Swapping für solche Queries wenig geeignet.)

●      Häufigkeit des Datenladens

Wenn sich queryrelevante Daten oft ändern und dementsprechend oft geladen werden, bringt die Verwendung des Caches kaum einen Gewinn: Der Cache muss jedes Mal neu aufgebaut werden. Wenn die gecachten Daten im Hauptspeicher gehalten werden, können dadurch die Daten von häufig abgerufenen Queries verdrängt werden; ihr Aufruf erfordert anschließend wiederum mehr Zeit.

Struktur

Es werden folgende Modi für den globalen Cache unterstützt:

...

       1.      Cache ist inaktiv (0)

Der transaktionsübergreifende Cache wird gezielt abgeschaltet.

Die folgenden Modi gelten für den aktiven Cache: Der transaktionsübergreifende Cache ist eingeschaltet.

       2.      Hauptspeicher Cache ohne Swapping (1)

Die Cache-Daten liegen im Hauptspeicher. Wenn der für das Caching zur Verfügung stehende Speicher verbraucht ist, werden Daten nach dem LRU-Algorithmus verdrängt, d.h. aus dem Speicher gelöscht. Bei einer erneuten Queryanfrage muss das Ergebnis erneut aus dem InfoProvider gelesen werden.

       3.      Hauptspeicher Cache mit Swapping (2)

Die Cache-Daten liegen im Hauptspeicher. Wenn der für das Caching zur Verfügung stehende Speicher verbraucht ist, werden die zu verdrängenden Daten auf einen Hintergrundspeicher geschrieben und können bei einer erneuten Anfrage wieder in den Cache-Speicher geladen werden.

Nachdem queryrelevante Daten erneut geladen wurden, kann der Hintergrundspeicher nicht mehr verwendet werden.

       4.      Persistenter Cache pro Applikationsserver (3)

Die Cache-Daten liegen persistent als Datenbanktabelle oder als Datei in einem vom Applikationsserver erreichbaren Verzeichnis. Wir empfehlen, ein nahe am Applikationsserver liegendes Verzeichnis zu wählen.

Wenn Sie die Cache-Daten in einer Datenbanktabelle speichern, belastet dies zwar auch die Datenbank, ist gegenüber dem Zugriff auf nicht gecachte Daten in der Datenbank aber deutlich schneller. Im Vergleich zur Ablage der Daten z.B. im Sternschema (siehe InfoCube) werden weniger Tabellen gelesen und weniger Indizes zugegriffen.

       5.      Persistenter Cache Applikationsserver übergreifend (4)

Die Cache-Daten liegen persistent als Datenbanktabelle oder als Datei applikationsserverübergreifend in einem vom Applikationsserver zugreifbaren Dateisystem im Netz. In diesem Modus gibt es keine Verdrängung und Begrenzung der Speichergröße. Dadurch wird zwar mehr Platz beansprucht, aber auch Zeit gespart.

¡        Datenbanktabelle: Die Last trägt die Datenbankinstanz, auf der die Tabelle liegt.

¡        Datei: Die Last trägt das Betriebssystem des Netzknotens, auf dem die Datei liegt.

¡        Hinzu kommen bei beiden Ablagetypen der Applikationsserver, der die Daten ausrechnet, und die Netzwerkkommunikation.

       6.      BLOB/Cluster erweitert (5)

Die Cache-Daten liegen persistent in Datenbanktabellen. In diesem Modus gibt es keine Verdrängung und Begrenzung der Speichergröße. Dadurch wird zwar mehr Platz beansprucht, aber auch Zeit gespart.

○       Datenbanktabelle: Die Last trägt die Datenbankinstanz, auf der die Tabelle liegt

○       Hinzu kommen bei beiden Ablagetypen der Applikationsserver, der die Daten ausrechnet, und die Netzwerkkommunikation.

Die Verarbeitung und die Speicherung der Daten hat sich bei diesem Cachemodus im Vergleich zu den oben aufgeführten Cache-Modi grundlegend geändert. Es wird kein Sperrkonzept verwendet und auf ein zentrales Verzeichnis der Cache-Elemente wird verzichtet.

Der Cachemodus BLOB/Cluster erweitert ist nicht standardmäßig verfügbar. Um diesen Cachemodus benutzen zu können, müssen Sie den RSADMIN-Parameter RSR_CACHE_ACTIVATE_NEW aktivieren (VALUE=x).

Weitere Informationen finden Sie im SAP-Hinweis 1026944.

Die folgende Tabelle gibt einen Überblick über die zur Verfügung stehenden Modi des aktiven Caches:

Modi des aktiven Caches

Eigenschaft	Hauptspeicher-Cache		Persistenter Cache
	ohne Swapping	mit Swapping	pro Applikationsserver	Applikationsserver-übergreifend
Verdrängung	ja (LRU-Algorithmus und Löschen)	ja (LRU-Algorithmus mit Auslagerung)	nein	nein
Swapping	nein	ja	nein	nein
Globale Cache-Größe	begrenzt	Hauptspeicher begrenzt, ausgelagerte Teile nicht begrenzt	nicht begrenzt	nicht begrenzt
Dateiname	nein	Bei Swapping in Flatfile: Unter dem Dateinamen liegen die verdrängten Daten.	Bei Flatfile-Cache: Unter dem Dateinamen liegen die gesamten Daten. Der Applikationsserver ist Bestandteil des Dateinamens.	Bei Flatfile-Cache: Unter dem Dateinamen liegen die gesamten Daten. Der Applikationsserver ist nicht Bestandteil des Dateinamens.

Für die unter 3.-6. genannten Modi des aktiven Caches (Hauptspeicher Cache mit Swapping, Persistenter Cache pro Applikationsserver bzw. Applikationsserver übergreifend) können Sie festlegen, wie die verdrängten bzw. gecachten Daten abgelegt werden sollen. Sie können folgende Persistenzmodi wählen:

●      Inaktiv: Wenn Sie diese Option wählen, stellt das System den Cachemodus wieder auf Hauptspeicher Cache ohne Swapping (1) zurück .

●      Flatfile: Ablage in einer Datei.

●      Cluster-Tabelle: Ablage in einer nicht-transparenten Datenbanktabelle vom Typ CLUSTER.

●      Transparente Tabelle (BLOB): Ablage in einer transparenten Datenbanktabelle mit BLOB (Binary Large OBject).

Bei großen Resultsets kann die Transparente Tabelle (BLOB) gegenüber der Cluster-Tabelle zu Performancesteigerungen führen, da weniger Datenbankoperationen ausgeführt werden müssen. Bei kleineren Resultsets dürfte die Cluster-Tabelle von Vorteil sein, da BLOB-Felder datenbankseitig einen größeren Verwaltungsaufwand bedingen.

Mit Hilfe dieser Einstellungen des Persistenzmodus können Sie für jede Query einzeln testen, welche persistente Ablage in Ihrem Systemumfeld die größte Performance bringt.

Wenn Sie keinen Persistenzmodus an der Query definieren, wird der im Customizing als Standardwert gepflegte Persistenzmodus für alle zu einem InfoProvider angelegten Queries berücksichtigt.

Integration

Weitere Informationen über die verschiedenen Möglichkeiten, den Cachemodus für einen InfoProvider bzw. für eine Query festzulegen, finden Sie unter Query-Eigenschaften.

Weitere Informationen über die globalen Cache-Parameter und den Speicherverbrauch des Laufzeitobjektes finden Sie unter OLAP-Cache-Monitor.