Show TOC Anfang des Inhaltsbereichs

Hintergrunddokumentation Arbeitsspeicherbereiche  Dokument im Navigationsbaum lokalisieren

Um möglichst wenig Zugriffe auf den permanenten Speicher (Volumes) machen zu müssen, puffert das Datenbanksystem Lese- und Schreiboperationen im Arbeitsspeicher. Für Informationen dazu, wann das Datenbanksystem Informationen aus dem Arbeitsspeicher in den permanenten Speicher schreibt, siehe Datenspeicherung.

Die Einheit, in der das Datenbanksystem den Arbeitsspeicher nutzt, sind Seiten.

Das Datenbanksystem unterteilt den Arbeitsspeicher, den es verwendet, in folgende Bereiche:

     I/O-Buffer-Cache, besteht im Wesentlichen aus:

     Data-Cache (größter Anteil)

     Converter

     internes Dateiverzeichnis

     Catalog-Cache

     Shared-SQL-Cache

     Sequence-Cache

     Log-Warteschlangen

     nur liveCache-Datenbankinstanzen: OMS-Heap

Arbeitsspeicherbereiche

Diese Grafik wird im zugehörigen Text erklärtBeispiel für Arbeitsspeichergrößen (Vorlage Desktop PC / Laptop für eine MaxDB-Datenbankinstanz)

Cache

Datenbankparameter

maximale Größe

I/O-Buffer-Cache

CACHE_SIZE = 2500

19,53 MB

Catalog-Cache

CAT_CACHE_SUPPLY = 1632

12,75 MB

Shared-SQL-Cache

SHAREDSQL_COMMANDCACHESIZE = 262144

256 MB (initial 16 MB)

Sequence-Cache

SEQUENCE_CACHE = 1

0,01 MB

Log-Warteschlangen

LOG_IO_QUEUE = 50 (Größe einer Log-Warteschlange)

LOG_QUEUE_COUNT = 1 (Anzahl Log-Warteschlangen)

0,4 MB

I/O-Buffer-Cache

Im I/O-Buffer-Cache verwaltet das Datenbanksystem den gesamten Arbeitsspeicher, der für I/O-Operationen zur Verfügung steht.

     Data-Cache

Im Data-Cache speichert das Datenbanksystem die Seiten, auf die es zuletzt im Datenbereich lesend oder schreibend zugegriffen hat. Hierzu gehören z. B. Tabellen, Indizes, Long-Werte und Undo-Log-Einträge

Das Datenbanksystem sucht Daten immer zuerst im Data-Cache, bevor es auf den Datenbereich zugreift.

Die Größe des Data-Cache wirkt sich folgendermaßen auf die Performance des Datenbanksystems aus:

     Ein großer Data-Cache ermöglicht eine hohe Trefferrate. Wir empfehlen eine Trefferrate von mindestens 98%.

     Ein zu großer Data-Cache kann auf einem Computer mit einem kleinen Arbeitsspeicher dazu führen, dass das Betriebssystem Seiten aus dem Arbeitsspeicher auf die Festplatte auslagert (Swapping), was die Performance stark verschlechtert.

     Converter-Cache

Im Converter speichert das Datenbanksystem die Informationen dazu, welche logische Seitennummer an welcher physikalischen Position (MaxDB-Blockadresse) gespeichert ist. Beim Starten der Datenbankinstanz liest das Datenbanksystem den ganzen Converter in den Arbeitsspeicher ein.

Siehe Converter.

Wenn der Converter im laufenden Datenbankbetrieb wächst und mehr Seiten benötigt, dann teilt das Datenbanksystem ihm mehr Seiten aus dem I/O-Buffer-Cache zu.

Hinweis

Sie können die Größe von Data-Cache und Converter nicht direkt konfigurieren, sondern nur indirekt über die Größe des I/O-Buffer-Cache.

Catalog-Cache

Im Catalog-Cache speichert das Datenbanksystem Folgendes:

     Informationen aus dem Datenbankkatalog

     Informationen zu bereits ausgeführten SQL-Anweisungen der einzelnen Datenbankbenutzer (benutzerspezifisch, nur wenn der Datenbankparameter SHAREDSQL den Wert NO hat). Wenn mehrere Datenbankbenutzer dieselbe SQL-Anweisung ausführen, wird, wird diese auch mehrmals im Catalog-Cache gespeichert.

Wenn der Catalog-Cache voll ist, verlagert das Datenbanksystem Informationen in den Data-Cache.

Jeder User-Task weist das Datenbanksystem zu Beginn der Datenbanksitzung einen Bereich des Catalog-Cache zu, den es nach Ende der Datenbanksitzung wieder freigibt.

Die Trefferrate für den Catalog-Cache sollte über 85 Prozent liegen. Die untere Grenze der Trefferrate hängt stark von der Anwendung ab.

Shared-SQL-Cache

Wenn der Datenbankparameter SHAREDSQL den Wert YES hat, dann verwendet das Datenbanksystem den Shared-SQL-Cache.

Im Shared-SQL-Cache speichert das Datenbanksystem bereits ausgeführte SQL-Anweisungen einschließlich ihrer Ausführungspläne. Der Shared-SQL-Cache wird von allen Datenbankbenutzern gemeinsam verwendet, dieselbe SQL-Anweisung wird also nur einmal gespeichert.

Hinweis

Wenn der Datenbankparameter SHAREDSQL den Wert NO hat, dann speichert das Datenbanksystem bereits ausgeführte SQL-Anweisungen für jeden Datenbankbenutzer einzeln im Catalog-Cache.

Sequence-Cache

Im Sequence-Cache speichert das Datenbanksystem Informationen zu Sequenzen.

Log-Warteschlangen

Das Datenbanksystem weist jeder Transaktion eine Log-Warteschlange zu, in die die Transaktion ihre Redo-Log-Einträge schreibt. Mehrere Transaktionen können in dieselbe Log-Warteschlange schreiben.

Siehe auch Protokollierung von Datenänderungen (Logging).

Arbeitsspeicher für das interne Dateiverzeichnis

Beim Starten der Datenbankinstanz liest das Datenbanksystem das gesamte interne Dateiverzeichnis in den Arbeitsspeicher ein. Im internen Dateiverzeichnis speichert das Datenbanksystem Informationen für den logischen Zugriff auf Datenbankobjekte, wie z. B. die Zuordnung der Wurzelseiten der B*-Bäume zu den Tabellen-IDs.

OMS-Heap (nur für SAP liveCache-Datenbankinstanzen)

Der OMS-Heap ist ein spezieller Arbeitsspeicherbereich, der nur von SAP liveCache-Datenbankinstanzen verwendet wird. Im OMS-Heap befinden sich folgende Daten:

     lokale Kopien der OMS-Daten

Beim ersten Zugriff auf ein Objekt innerhalb einer konsistenten Sicht schreibt das Datenbanksystem die entsprechenden Daten in den OMS-Heap.

     lokale Anwendungsdaten

Für jede OMS-Version kopiert das Datenbanksystem die Daten beim Lesen in den OMS-Heap.

Um auf ein persistentes Objekt zuzugreifen, sucht das Datenbanksystem es zuerst im OMS-Heap. Wenn es das Objekt dort nicht findet, sucht es im Data-Cache. Wenn es das Objekt auch dort nicht findet, kopiert das Datenbanksystem das Objekt vom Datenbereich in den Data-Cache und von dort in den OMS-Heap. Alle Änderungen an Objekten führt das Datenbanksystem dann im OMS-Heap durch. Objekte, die innerhalb einer konsistenten Sicht gelesen, aber nicht geändert wurden, löscht das Datenbanksystem aus dem OMS-Heap. Mit dem Beenden einer Transaktion (COMMIT) schreibt das Datenbanksystem die OMS-Daten aus dem OMS-Heap in den Data-Cache.

Der OMS-Heap wächst, wenn die Anwendung zusätzlichen Arbeitsspeicher anfordert. Die maximale Größe des OMS-Heap konfigurieren Sie mit dem liveCache-Datenbankparameter OMS_HEAP_LIMIT.

Siehe liveCache-Datenbankparameter.

Wie synchronisiert das Datenbanksystem Zugriffe auf kritische Abschnitte?

Ein kritischer Abschnitt ist ein Bereich des Arbeitsspeichers, für den das Datenbanksystem konkurrierende Zugriffe von Tasks über spezielle Synchronisationsmittel (Regionen, Reader-Writer-Locks) ermöglicht.

Spezielle Synchronisationsmittel

Name

verwendet für

Beschreibung

Region

Data-Cache

exklusive Sperre

Wenn eine Task auf einen kritischen Abschnitt zugreift, dann sperrt die zuständige Region diesen kritischen Abschnitt für alle anderen Tasks.

Reader-Writer-Lock

Catalog-Cache

Shared-SQL-Cache

exklusive oder shared

Wenn eine Task schreibend auf einen kritischen Abschnitt zugreift, dann sperrt das zuständige Reader-Writer-Lock diesen kritischen Abschnitt für weitere schreibende Zugriffe, lesende Zugriffe sind jedoch möglich.

Wenn eine Task lesend auf einen kritischen Abschnitt zugreift, dann sperrt das zuständige Reader-Writer-Lock diesen kritischen Abschnitt für schreibende Zugriffe, weitere lesende Zugriffe sind jedoch möglich.

Siehe auch:

Datenbankparameter

Savepoint

Überwachung

Performance

Ende des Inhaltsbereichs