Cache-Administrationsparameter 
Die Cache-Administrationsparameter dienen der Performance-Optimierung bei der Verwendung des OLAP-Caches.
Administrationsparameter |
Beschreibung |
|---|---|
Allgemeine Einstellungen |
|
Statistiken aufzeichnen |
Sie können festlegen, ob Cache-Statistiken aufgezeichnet werden sollen. Beim Ausführen einer Query werden für jedes Cache-Element Statistiken aufgezeichnet. Dazu zählen folgende:
Das Schreiben der Statistiken erzeugt zusätzliche Zugriffe auf die Datenbank und kann daher Einbußen bei der Performance bedingen. Aus diesem Grund ist es möglich, das Schreiben der Statistiken abzustellen. Standardmäßig ist diese Einstellung aktiviert. Die Statistiken werden standardmäßig gepuffert und erst am Ende eines Querynavigationsschrittes vollständig auf die Datenbank geschrieben. Dies bedingt eine deutliche Performancesteigerung im Vergleich zum Schreiben jedes einzelnen Datensatzes auf die Datenbank. Beachten Sie dazu den Administrationsparameter Statistik-Pufferung ausschalten. |
Statistik-Pufferung ausschalten |
Sie können festlegen, ob die Cache-Statistiken gepuffert aufgezeichnet werden sollen. Für den Zugriff auf Cache-Elemente können Statistiken geschrieben werden. Damit die Performance weniger beeinträchtigt wird, werden alle Statistiken über die Laufzeit eines Navigationsschrittes einer Query gesammelt und erst am Ende des Navigationsschrittes auf die Datenbank geschrieben. Zum Zwecke der Fehleranalyse kann es sinnvoll sein, dass die Einträge nicht gesammelt, sondern jedes Mal direkt auf die Datenbank geschrieben werden. Mit Rücksicht auf die Performance sollte dies aber nicht die Regel sein. |
Monitor soll initial alle Daten lesen |
Sie können festlegen, ob der Cache-Monitor initial sämtliche Cache-Elemente lesen soll. Aus Gründen der Performance liest der Cache-Monitor standardmäßig nur die Einträge auf Query-Ebene und zeigt diese an. Untergeordnete Einträge werden erst dann gelesen, wenn sich ein Benutzer die untergeordneten Einträge anzeigen läßt. Mit diesem Parameter ist es möglich, das System zu veranlassen, beim initialen Laden alle Einträge auf einmal zu lesen. Diese Einstellung gilt nur für den empfohlenen Cachemodus BLOB/Cluster erweitert. |
Cacheprotokollierung an |
Sie können die Cacheprotokollierung ein- oder ausschalten. Zur genaueren Analyse von Fehlersituationen gibt es eine Protokollierung im Cache. Diese ermöglicht es, Informationen über das Schreiben in den Cache und über das Lesen aus dem Cache zu sammeln. Im Fehlerfall lässt sich über diesen Parameter die Protokollierung ein- oder ausschalten. |
Einstellungen für bisherigen Cache |
|
Lesestatistiken des bisherigen Caches aus |
Sie können das Schreiben von Lesestatistiken der alten Cachemodi abstellen und somit ggf. entstehende Inkonsistenzen beim Schreiben von Cache-Einträgen in den alten Cachemodi verringern. Dieser Parameter wirkt sich nur auf die Persistenzmodi Flatfile (sowohl applikationsserverabhängig als auch applikationsserverübergreifend), Cluster-Tabelle sowie transparente Tabelle (BLOB) aus. |
Abbruch, falls Enqueue nicht bekommen |
Der Cache versucht in einer Schleife wiederholt, einen Enqueue zu setzen, um mit einem Cache-Eintrag arbeiten zu können. Sollte es einem Prozess nach vielen (z.B. nach 1000) Versuchen nicht gelungen sein, den Enqueue zu setzen, ist davon auszugehen, dass ein Problem vorliegt. Um auf den Problemfall aufmerksam zu machen und Inkonsistenzen zu vermeiden, bricht der Cache den laufenden Prozess mit einer Fehlermeldung (X-Meldung) ab. Ein Administrator kann die Anzahl der Versuche zum Enqueue-Setzen festlegen. Wenn Sie die Anzahl der Versuche sehr gering einstellen, können Sie allein aufgrund der wenigen Fehlschläge nicht sicher von einem grundsätzlichen Mißlingen ausgehen; wenn Sie die Anzahl der Versuche größer gewählt hätten, hätte der Cache das Enqueue möglicherweise noch erfolgreich setzen können. Für diesen Fall können Sie als Administrator über diesen Parameter einstellen, dass der Prozess, also die Query, nicht mit einer X-Message abbrechen, sondern weiterlaufen soll, auch wenn der Cache kein Enqueue setzen konnte. Dieser Parameter wirkt sich nur auf die Persistenzmodi Flatfile (sowohl applikationsserverabhängig als auch applikationsserverübergreifend), Cluster-Tabelle sowie transparente Tabelle (BLOB) aus. |
Einstellungen für neuen Cache |
|
Ab dieser Größe Daten in größere Persistenz speichern |
Der neue Cachemodus BLOB/Cluster erweitert nutzt für die Ablage der Cache-Einträge mit Querydaten sowohl eine Cluster-Tabelle als auch eine BLOB-Ablage (Tabelle mit XSTRING-Bereich). Mit dieser Einstellung kann beeinflusst werden, bis zu welcher Größe in den Speicherbereich für die kleineren Query-Ergebnisse geschrieben werden soll und ab wann die Ablage für größere Speicher genutzt werden soll. Die beiden folgenden Einstellungen ermöglichen die Auswahl, welcher der beiden Speicher für die größeren Query-Ergebnisse, also die Query-Ergebnisse, deren Größe höher ist, als die hier vorgegebene Kennzahl, genutzt werden soll. Beachten Sie, dass die Entscheidung für eine der beiden Speicher beim initialen Anlegen eines Cache-Eintrages für die Querydaten getroffen wird und von da an nicht mehr geändert werden kann, selbst wenn der Cache-Eintrag zu einem späteren Zeitpunkt größer als die voreingestellte Kennzahl ist. |
BLOB-Tabelle für große Daten |
Wenn diese Option gewählt ist, werden Cache-Einträge mit Querydaten, die beim initialen Anlegen das eingestellte Größenlimit überschreiten, in die BLOB-Tabelle (Tabelle mit XSTRING) geschrieben. BLOB-Tabellen sind beim Transport der Daten zwischen Datenbank und Anwendungsserver bei großen Datenmengen zu bevorzugen. Allerdings können keine internen Tabellen gespeichert werden, wodurch es nicht möglich ist, Daten in speziellen Situationen performanter in eine interne Tabelle statt in einen XSTRING zu exportieren. |
Cluster-Tabelle für große Daten |
Wenn diese Option gewählt ist, werden Cache-Einträge mit Querydaten, die beim initialen Anlegen das eingestellte Größenlimit überschreiten, in die Cluster-Tabelle (auch Index-Tabelle genannt) geschrieben. Cluster-Tabellen sind beim Transport der Daten zwischen Datenbank und Anwendungsserver bei großen Datenmengen im Nachteil, da mehrere implizite SELECT-Statements gemacht werden. Allerdings können hier interne Tabellen abgespeichert werden, was in speziellen Situationen performanter ist als der Datenexport in einen XSTRING. |