Speicherarchitektur

In diesem Kapitel wird die Speicherarchitektur einer Datenbankinstanz erläutert.

Arbeitsspeicherstrukturen in Oracle AI Database - Einführung

Wenn eine Instanz gestartet wird, weist Oracle AI Database einen Speicherbereich zu und startet Hintergrundprozesse.

Im Speicherbereich werden Informationen wie die folgenden gespeichert:

Grundlegende Arbeitsspeicherstrukturen

Oracle AI Database umfasst mehrere Speicherbereiche, die jeweils mehrere Unterkomponenten enthalten.

Die grundlegenden Speicherstrukturen, die mit Oracle AI Database verknüpft sind, umfassen:

Die folgende Abbildung veranschaulicht die Beziehungen zwischen diesen Gedächtnisstrukturen.

Abbildung 1: Oracle AI Database - Arbeitsspeicherstrukturen

Beschreibung der Abbildung cncpt217.png

Oracle AI Database-Speicherverwaltung

Zur Speicherverwaltung gehört die Verwaltung optimaler Größen für die Speicherstrukturen für die Oracle-Instanzen, während sich der Bedarf an der Datenbank ändert. Oracle AI Database verwaltet den Speicher basierend auf den Einstellungen der speicherbezogenen Initialisierungsparameter.

Grundlegende Optionen für die Speicherverwaltung sind:

Wenn Sie eine Datenbank mit Database Configuration Assistant (DBCA) erstellen und die grundlegende Installationsoption auswählen, ist die automatische Speicherverwaltung die Standardeinstellung.

Siehe:

System Global Area (SGA) - Überblick

Die SGA ist ein Lese-/Schreibspeicherbereich, der zusammen mit den Oracle-Hintergrundprozessen eine Datenbankinstanz bildet. Hinweis: Die Server- und Hintergrundprozesse befinden sich nicht innerhalb der SGA, sondern in einem separaten Speicherbereich.

Alle Serverprozesse, die im Auftrag von Benutzern ausgeführt werden, können Informationen in der Instance SGA lesen. Während des Datenbankvorgangs werden mehrere Prozesse in die SGA geschrieben.

Jede Datenbankinstanz verfügt über eine eigene SGA. Oracle AI Database weist beim Hochfahren der Instanz automatisch Speicher für eine SGA zu und setzt den Speicher beim Herunterfahren der Instanz zurück. Wenn Sie eine Instanz mit SQL*Plus oder Oracle Enterprise Manager starten, wird die Größe der SGA wie im folgenden Beispiel gezeigt:

SQL> STARTUP
ORACLE instance started.

Total System Global Area  368283648 bytes
Fixed Size                  1300440 bytes
Variable Size             343935016 bytes
Database Buffers           16777216 bytes
Redo Buffers                6270976 bytes
Database mounted.
Database opened.

Wie in Abbildung 17-1 dargestellt, besteht die SGA aus mehreren Speicherkomponenten, bei denen es sich um Speicherpools handelt, die zur Erfüllung einer bestimmten Klasse von Speicherzuweisungsanforderungen verwendet werden. Alle SGA-Komponenten mit Ausnahme des Redo-Logpuffers weisen Speicherplatz in Einheiten mit zusammenhängendem Speicher zu, die als Granules bezeichnet werden. Die Granulatgröße ist plattformspezifisch und wird durch die gesamte SGA-Größe bestimmt.

Sie können die View V$SGASTAT nach Informationen zu SGA-Komponenten abfragen.

Die wichtigsten SGA-Komponenten sind:

Siehe:

Datenbankpuffercache

Der Datenbankpuffercache, auch als Puffercache bezeichnet, ist der Speicherbereich, in dem Kopien von Datenblöcken gespeichert werden, die aus Datendateien gelesen werden.

Ein Puffer ist eine Hauptspeicheradresse, in der der Puffermanager einen aktuell oder zuletzt verwendeten Datenblock temporär zwischenspeichert. Alle Benutzer, die gleichzeitig bei einer Datenbankinstanz angemeldet sind, haben Zugriff auf den Puffercache.

Zweck des Datenbankpuffercaches

Oracle AI Database verwendet den Puffercache, um mehrere Ziele zu erreichen.

Die Ziele umfassen:

Siehe:

Pufferstatus

Die Datenbank verwendet interne Algorithmen, um Puffer im Cache zu verwalten.

Ein Puffer kann einen der folgenden sich gegenseitig ausschließenden Status aufweisen:

Jeder Puffer hat einen Zugriffsmodus: Pinned oder Free (unpinned). Ein Puffer wird im Cache "gepinnt", sodass er während des Zugriffs einer Benutzersession nicht über den Speicher hinausgeht. Mehrere Sessions können einen gepinnten Puffer nicht gleichzeitig ändern.

Puffermodi

Wenn ein Client Daten anfordert, ruft Oracle AI Database Puffer entweder im aktuellen oder im konsistenten Modus aus dem Datenbankpuffercache ab.

Die Modi unterscheiden sich wie folgt:

Siehe:

Puffer-I/O

Ein logischer I/O, auch als Puffer-I/O bezeichnet, bezieht sich auf Lese- und Schreibvorgänge von Puffern im Puffercache.

Wenn kein angeforderter Puffer im Speicher gefunden wird, führt die Datenbank ein physisches I/O aus, um den Puffer aus dem Flashcache oder der Festplatte in den Speicher zu kopieren. Die Datenbank führt dann ein logisches I/O aus, um den gecachten Puffer zu lesen.

Pufferersetzungsalgorithmen

Um den Pufferzugriff effizient zu gestalten, muss die Datenbank entscheiden, welche Puffer im Speicher gecacht werden und auf welche von der Festplatte zugegriffen werden soll.

Die Datenbank verwendet die folgenden Algorithmen:

Siehe auch: Oracle AI Database VLDB and Partitioning Guide, um mehr über den temperaturbasierten Algorithmus zu erfahren

Pufferschreibvorgänge

Der Database Writer-(DBW-)Prozess schreibt regelmäßig Cold-Dirty-Puffer auf den Datenträger.

DBW schreibt Puffer unter folgenden Umständen:

Siehe:

Pufferlesezugriffe

Wenn die Anzahl der nicht verwendeten Puffer gering ist, muss die Datenbank Puffer aus dem Puffercache entfernen.

Der Algorithmus hängt davon ab, ob der Flashcache aktiviert ist:

Wenn ein Clientprozess einen Puffer anfordert, durchsucht der Serverprozess den Puffercache nach dem Puffer. Ein Cache-Treffer tritt auf, wenn die Datenbank den Puffer im Speicher findet. Die Suchreihenfolge lautet wie folgt:

  1. Der Serverprozess sucht nach dem gesamten Puffer im Puffercache.

    Wenn der Prozess den gesamten Puffer findet, führt die Datenbank einen logischen Lesevorgang dieses Puffers aus.

  2. Der Serverprozess sucht in der LRU-Liste des Flashcaches nach dem Pufferheader.

    Wenn der Prozess den Pufferheader findet, führt die Datenbank einen optimierten physischen Lesevorgang des Pufferbodys aus dem Flashcache in den In-Memory-Cache aus.

  3. Wenn der Prozess den Puffer nicht im Speicher findet (ein Cachefehlschlag), führt der Serverprozess die folgenden Schritte aus:

    1. Kopiert den Block aus einer Datendatei auf dem Datenträger in den Speicher (physischer Lesevorgang)

    2. Führt einen logischen Lesevorgang des Buffers durch, der in den Speicher eingelesen wurde

Die Buffer-Suchreihenfolge wird in Abbildung 17-2 dargestellt. Der erweiterte Buffer Cache umfasst sowohl den speicherresidenten Buffer Cache, der ganze Buffer enthält, als auch den Flash Cache, der Buffer Bodies enthält. In der Abbildung sucht die Datenbank nach einem Puffer im Puffercache und liest ihn, ohne den Puffer zu finden, von einer Magnetplatte in den Speicher.

Abbildung 2: Puffersuche

Beschreibung der Abbildung cncpt304.gif

Im Allgemeinen ist der Zugriff auf Daten über einen Cache-Treffer schneller als über einen Cache-Fehler. Die Puffercache-Trefferrate misst, wie oft die Datenbank einen angeforderten Block im Puffercache gefunden hat, ohne ihn von der Festplatte lesen zu müssen.

Die Datenbank kann physische Lesevorgänge aus einer Datendatei oder einer temp-Datei ausführen. Auf Lesezugriffe aus einer Datendatei folgen logische I/Os. Lesevorgänge aus einer temporären Datei treten auf, wenn zu wenig Speicher die Datenbank zwingt, Daten in eine temporäre Tabelle zu schreiben und später wieder zu lesen. Diese physischen Lesevorgänge umgehen den Puffercache und verursachen kein logisches I/O.

Siehe auch: In der Oracle AI Database Performance Tuning Guide erfahren Sie, wie Sie die Puffercache-Trefferrate berechnen.

Pufferanzahl

Die Datenbank misst die Häufigkeit des Zugriffs auf Puffer in der LRU-Liste mit einem Touch Count. Mit diesem Mechanismus kann die Datenbank einen Zähler erhöhen, wenn ein Puffer gepinnt wird, anstatt Puffer in der LRU-Liste ständig zu mischen.

Hinweis: Die Datenbank verschiebt keine Blöcke im Speicher. Die Bewegung ist die Änderung der Position eines Zeigers auf einer Liste.

Wenn ein Puffer gepinnt wird, bestimmt die Datenbank, wann die Anzahl der Berührungen zuletzt erhöht wurde. Wenn die Anzahl vor mehr als drei Sekunden erhöht wurde, wird die Anzahl erhöht. Andernfalls bleibt die Anzahl gleich. Die Drei-Sekunden-Regel verhindert, dass Pins auf einem Puffer so viele Berührungen zählen. Beispiel: Eine Session kann mehrere Zeilen in einen Datenblock einfügen. Die Datenbank betrachtet diese Einfügungen jedoch als eine Berührung.

Wenn sich ein Puffer am kalten Ende der LRU befindet, die Anzahl der Berührungen jedoch hoch ist, wird der Puffer an das heiße Ende verschoben. Wenn die Anzahl der Berührungen niedrig ist, wird der Puffer aus dem Cache entfernt.

Pufferpools

Ein Pufferpool ist eine Sammlung von Puffern.

Der Datenbank-Puffercache ist in einen oder mehrere Pufferpools unterteilt, die Blöcke in der Regel auf die gleiche Weise verwalten. Die Pools verfügen über keine radikal unterschiedlichen Algorithmen für Alterungs- oder Caching-Blöcke.

Sie können separate Pufferpools manuell konfigurieren, die entweder Daten im Puffercache speichern oder die Puffer unmittelbar nach der Verwendung der Datenblöcke für neue Daten verfügbar machen. Anschließend können Sie dem entsprechenden Pufferpool bestimmte Schemaobjekte zuweisen, um zu steuern, wie Blöcke aus dem Cache entfernt werden. Beispiel: Sie können Segmente in Hot-, Warm- und Cold-Pufferpools trennen.

Folgende Pufferpools sind möglich:

Eine Datenbank hat eine Standardblockgröße. Sie können einen Tablespace mit einer Blockgröße erstellen, die sich von der Standardgröße unterscheidet. Jede nicht standardmäßige Blockgröße verfügt über einen eigenen Pool. Oracle AI Database verwaltet die Blöcke in diesen Pools auf die gleiche Weise wie im Standardpool.

Die folgende Abbildung zeigt die Struktur des Puffercaches, wenn mehrere Pools verwendet werden. Der Cache enthält Standard-, Keep- und Recycle-Pools. Die Standardblockgröße ist 8 KB. Der Cache enthält separate Pools für Tablespaces, die nicht standardmäßige Blockgrößen von 2 KB, 4 KB und 16 KB verwenden.

Abbildung 3: Datenbankpuffercache

Beschreibung der Abbildung cncpt220.gif

Siehe:

Puffer und Full Table Scans

Die Datenbank verwendet einen komplizierten Algorithmus zur Verwaltung von Tabellenscans. Wenn Puffer vom Datenträger gelesen werden müssen, fügt die Datenbank die Puffer standardmäßig in die Mitte der LRU-Liste ein. Auf diese Weise können Hot-Blöcke im Cache verbleiben, sodass sie nicht erneut von der Festplatte gelesen werden müssen.

Ein Problem wird durch einen vollständigen Table Scan verursacht, der alle Zeilen unter der Tabelle High Water Mark (HWM) sequenziell liest. Angenommen, die Gesamtgröße der Blöcke in einem Tabellensegment ist größer als die Größe des Buffer Caches. Ein vollständiger Scan dieser Tabelle könnte den Puffercache bereinigen und verhindern, dass die Datenbank einen Cache mit Blöcken verwaltet, auf die häufig zugegriffen wird.

Standardmodus für Full Table Scans

Standardmäßig verfolgt die Datenbank einen konservativen Ansatz bei Full Table Scans und lädt nur dann eine kleine Tabelle in den Speicher, wenn die Tabellengröße einen kleinen Prozentsatz des Puffercaches beträgt.

Um zu bestimmen, ob Tabellen mittlerer Größe gecacht werden sollen, verwendet die Datenbank einen Algorithmus, der das Intervall zwischen dem letzten Table Scan, dem Alterungszeitstempel des Puffercaches und dem im Puffercache verbleibenden Speicherplatz enthält.

Bei sehr großen Tabellen verwendet die Datenbank in der Regel einen Direct Path-Lesevorgang, der Blöcke direkt in die PGA lädt und die SGA insgesamt umgeht, um zu vermeiden, dass der Puffercache gefüllt wird. Bei Tabellen mittlerer Größe kann die Datenbank einen direkten Lese- oder Cache-Lesevorgang verwenden. Wenn ein Cache-Lesevorgang verwendet werden soll, platziert die Datenbank die Blöcke am Ende der LRU-Liste, um zu verhindern, dass der Scan den Puffercache effektiv bereinigt.

Ab Oracle Database 12c Release 1 (12.1.0.2) führt der Puffercache einer Datenbankinstanz automatisch eine interne Berechnung aus, um zu bestimmen, ob der Speicher ausreicht, damit die Datenbank vollständig in der Instanz-SGA gecacht wird, und ob das Caching von Tabellen beim Zugriff für die Performance von Vorteil wäre. Wenn die gesamte Datenbank vollständig in den Speicher passen kann und verschiedene andere interne Kriterien erfüllt sind, behandelt Oracle AI Database alle Tabellen in der Datenbank als kleine Tabellen und betrachtet sie als für das Caching geeignet. Die Datenbank cacht jedoch keine LOBs, die mit dem Attribut NOCACHE markiert sind.

Parallele Abfrageausführung

Bei einem Full Table Scan kann die Datenbank manchmal die Antwortzeit verbessern, indem mehrere Server für die Parallelverarbeitung verwendet werden.

In einigen Fällen kann die Datenbank parallele Abfragedaten in der System Global Area (SGA) cachen, anstatt Direct Path-Lesevorgänge in die Programm Global Area (PGA) zu verwenden. In der Regel werden parallele Abfragen in Data Warehouses mit geringer Währung aufgrund der potenziellen Ressourcennutzung ausgeführt.

Siehe:

CACHE-Attribut

In seltenen Fällen, in denen das Standard-Caching-Verhalten nicht erwünscht ist, können Sie mit ALTER TABLE ... CACHE ändern, wie Blöcke aus großen Tabellen in den Datenbankpuffercache gelesen werden.

Bei Tabellen mit dem Attribut CACHE erzwingt oder pinnt die Datenbank die Blöcke im Puffercache nicht. Stattdessen altert die Datenbank die Blöcke aus dem Cache auf die gleiche Weise wie jeder andere Tabellenblock. Verwenden Sie bei der Ausübung dieser Option Vorsicht, da ein vollständiger Scan einer großen Tabelle die meisten anderen Blöcke aus dem Cache entfernen kann. Hinweis: Wenn Sie ALTER TABLE ... CACHE ausführen, verursacht keine Tabelle, die gecacht werden soll.

KEEP-Attribut

Bei großen Tabellen können Sie ALTER TABLE ... STORAGE BUFFER_POOL KEEP verwenden, damit Scans Blöcke für diese Tabellen in den Keep Pool laden.

Wenn Sie eine Tabelle in den Keep Pool einfügen, ändert sich der Teil des Buffer Caches, in dem die Blöcke gespeichert sind. Anstatt Blöcke im Standardpufferpool zwischenzuspeichern, speichert die Datenbank sie im Keep-Pufferpool. Keine separaten Algorithmen steuern das Pool-Caching.

Siehe:

Vollständigen Datenbank-Caching-Modus erzwingen

Um die Performance in einigen Situationen zu verbessern, können Sie die Anweisung ALTER DATABASE ... FORCE FULL DATABASE CACHING explizit ausführen, um den Vollständigen Datenbank-Caching-Modus erzwingen zu aktivieren.

Im Gegensatz zum automatischen Standardmodus betrachtet der Modus "Vollständiges Datenbank-Caching erzwingen" die gesamte Datenbank, einschließlich NOCACHE-LOBs, als für das Caching im Datenbankpuffercache geeignet. Dieser Modus ist ab Oracle Database 12c Release 1 (12.1.0.2) verfügbar. Hinweis: Wenn Sie den Modus "Vollständiges Datenbank-Caching erzwingen" aktivieren, wird die Datenbank nicht in den Speicher erzwungen. Stattdessen kann die gesamte Datenbank nicht im Puffercache gecacht werden. Oracle AI Database cacht Tabellen nur, wenn auf sie zugegriffen wird.

Oracle empfiehlt, den vollständigen Datenbank-Caching-Modus nur dann zu aktivieren, wenn die Puffercachegröße jeder einzelnen Instance größer als die Datenbankgröße ist. Diese Richtlinie gilt sowohl für Einzelinstanz- als auch für Oracle RAC-Datenbanken. Wenn Oracle RAC-Anwendungen jedoch gut partitioniert sind, können Sie den Modus "Vollständiges Datenbank-Caching erzwingen" aktivieren, wenn der kombinierte Puffercache aller Instanzen mit zusätzlichem Speicherplatz für die Verarbeitung doppelt gecachter Blöcke zwischen Instanzen größer als die Datenbankgröße ist.

Siehe:

DRAM- und PMEM-Puffer

Standard-Datenbankpuffer (DRAM) unterscheiden sich von PMEM-Puffern, weisen jedoch gemeinsame Merkmale auf.

Wenn Oracle Persistent Memory Filestore (PMEM Filestore) konfiguriert ist, wird jeder Datenblock direkt dem Puffercache in DRAM zugeordnet. Im Gegensatz zu DRAM-Puffern kopieren PMEM-Puffer den Inhalt von Datenblöcken nicht. Stattdessen verweisen PMEM-Pufferheader auf Datenblöcke, die in PMEM Filestore gespeichert sind. Bei den meisten Lesevorgängen speichert die Datenbank nur die Blockmetadaten, nicht den Inhalt. PMEM-Puffer verwenden einen speziellen Granulattyp, dessen Struktur sich von den Standard-Puffercache-Granulaten unterscheidet.

Hinweis: Der Initialisierungsparameter DB_CACHE_SIZE gibt die Mindestgröße des DRAM-Cache an. PMEM-Metadaten-Overhead ist in dieser Zuweisung nicht enthalten.

PMEM-Puffer können folgende Statusangaben haben:

PMEM hat eine höhere Latenz als DRAM. Oracle AI Database verwendet einen internen, Workload-basierten Algorithmus, um zu entscheiden, welche Blöcke von PMEM zu DRAM migriert werden sollen.

Siehe:

Redo-Logpuffer

Der Redo-Logpuffer ist ein zyklischer Puffer in der SGA, der Redo-Einträge speichert, die an der Datenbank vorgenommene Änderungen beschreiben.

Ein Redo-Datensatz ist eine Datenstruktur mit den Informationen, die zum Rekonstruieren oder Wiederholen von Änderungen an der Datenbank durch DML- oder DDL-Vorgänge erforderlich sind. Beim Datenbank-Recovery werden Redo-Einträge auf Datendateien angewendet, um verlorene Änderungen wiederherzustellen.

Die Datenbankprozesse kopieren Redo-Einträge aus dem Benutzerspeicherplatz in den Redo Log-Buffer in der SGA. Die Redo-Einträge belegen fortlaufenden, sequenziellen Speicherplatz im Puffer. Der Log Writer-Prozess (LGWR) im Hintergrundprozess schreibt den Redo-Logpuffer in die aktive Online-Redo-Loggruppe auf Datenträger. Abbildung 17-4 zeigt diese Redo-Pufferaktivität.

Abbildung 4: Redo-Logpuffer

Beschreibung der Abbildung cncpt226.gif

LGWR schreibt Redo sequenziell auf Platte, während DBW verstreute Schreibvorgänge von Datenblöcken auf Platte durchführt. Verstreute Schreibvorgänge sind in der Regel viel langsamer als sequenzielle Schreibvorgänge. Da LGWR es Benutzern ermöglicht, nicht darauf zu warten, dass DBW seine langsamen Schreibvorgänge abschließt, liefert die Datenbank eine bessere Performance.

Der Initialisierungsparameter LOG_BUFFER gibt die Speichermenge an, die Oracle AI Database beim Puffern von Redo-Einträgen verwendet. Im Gegensatz zu anderen SGA-Komponenten teilen der Redo Log-Puffer und der feste SGA-Puffer den Speicher nicht in Granulate auf.

Siehe:

Shared Pool

Der Shared Pool speichert verschiedene Arten von Programmdaten im Cache.

Beispiel: Der Shared Pool speichert geparste SQL-, PL/SQL-Code-, Systemparameter- und Data Dictionary-Informationen. Der Shared Pool ist an fast jedem Vorgang in der Datenbank beteiligt. Beispiel: Wenn ein Benutzer eine SQL-Anweisung ausführt, greift Oracle AI Database auf den Shared Pool zu.

Der Shared Pool ist in mehrere Unterkomponenten unterteilt, von denen die wichtigsten in Abbildung 17-5 dargestellt sind.

Abbildung 5: Shared Pool

Beschreibung der Abbildung cncpt225.gif

Es werden folgende Themen behandelt:

Bibliotheks-Cache

Der Bibliothekscache ist eine Shared Pool-Speicherstruktur, in der ausführbarer SQL- und PL/SQL-Code gespeichert wird.

Dieser Cache enthält die Shared SQL- und PL/SQL-Bereiche sowie Kontrollstrukturen wie Sperren und Library-Cache-Handles. In einer Shared Server-Architektur enthält der Library-Cache auch private SQL-Bereiche.

Wenn eine SQL-Anweisung ausgeführt wird, versucht die Datenbank, zuvor ausgeführten Code wiederzuverwenden. Wenn eine geparste Darstellung einer SQL-Anweisung im Library-Cache vorhanden ist und gemeinsam verwendet werden kann, verwendet die Datenbank den Code erneut, der als Soft Parse oder Treffer des Library-Caches bezeichnet wird. Andernfalls muss die Datenbank eine neue ausführbare Version des Anwendungscodes erstellen, die als Hard Parse oder Library Cache Miss (Fehler im Bibliothekscache) bezeichnet wird.

Gemeinsame SQL-Bereiche

Die Datenbank stellt jede SQL-Anweisung dar, die sie im Shared SQL-Bereich und im privaten SQL-Bereich ausführt.

Die Datenbank verwendet den Shared SQL-Bereich, um das erste Auftreten einer SQL-Anweisung zu verarbeiten. Dieser Bereich ist für alle Benutzer zugänglich und enthält den Anweisungsparsebaum und den Ausführungsplan. Für eine eindeutige Anweisung ist nur ein Shared SQL-Bereich vorhanden. Jede Session, die eine SQL-Anweisung absetzt, verfügt über einen privaten SQL-Bereich in ihrer PGA. Jeder Benutzer, der dieselbe Anweisung weiterleitet, verfügt über einen privaten SQL-Bereich, der auf denselben Shared SQL-Bereich verweist. Daher können viele private SQL-Bereiche in separaten PGAs mit demselben Shared SQL-Bereich verknüpft werden.

Die Datenbank bestimmt automatisch, wann Anwendungen ähnliche SQL-Anweisungen weiterleiten. Die Datenbank berücksichtigt sowohl SQL-Anweisungen, die direkt von Benutzern und Anwendungen abgesetzt wurden, als auch rekursive SQL-Anweisungen, die intern von anderen Anweisungen abgesetzt wurden.

Die Datenbank führt die folgenden Schritte aus:

  1. Prüft, ob ein Shared SQL-Bereich für eine syntaktisch und semantisch identische Anweisung vorhanden ist:

    • Wenn eine identische Anweisung vorhanden ist, verwendet die Datenbank den Shared SQL-Bereich für die Ausführung der nachfolgenden neuen Instanzen der Anweisung, wodurch der Speicherverbrauch reduziert wird.

    • Wenn keine identische Anweisung vorhanden ist, weist die Datenbank einen neuen Shared SQL-Bereich im Shared Pool zu. Eine Anweisung mit derselben Syntax, aber unterschiedlicher Semantik verwendet einen untergeordneten Cursor.

    In beiden Fällen verweist der private SQL-Bereich für den Benutzer auf den Shared SQL-Bereich, der die Anweisung und den Ausführungsplan enthält.

  2. Ordnet einen privaten SQL-Bereich für die Session zu

    Der Speicherort des privaten SQL-Bereichs hängt von der Verbindung ab, die für die Session hergestellt wurde. Wenn eine Session über einen Shared Server verbunden ist, wird ein Teil des privaten SQL-Bereichs in der SGA beibehalten.

Abbildung 17-6 zeigt eine dedizierte Serverarchitektur, in der zwei Sessions eine Kopie derselben SQL-Anweisung in ihren eigenen PGAs speichern. In einem Shared Server befindet sich diese Kopie in der UGA, die sich in der MGA befindet.

Abbildung 6: Private SQL-Bereiche und Shared SQL-Bereich

Beschreibung der Abbildung cncpt252.gif

Siehe:

Programmeinheiten und der Library Cache

Der Library-Cache enthält ausführbare Formen von PL/SQL-Programmen und Java-Klassen. Diese Elemente werden zusammen als Programmeinheiten bezeichnet.

Die Datenbank verarbeitet Programmeinheiten ähnlich wie SQL-Anweisungen. Beispiel: Die Datenbank weist einen Shared Area zu, der die geparste, kompilierte Form eines PL/SQL-Programms enthält. Die Datenbank weist einen privaten Bereich zu, der bestimmte Werte für die Session enthält, in der das Programm ausgeführt wird. Dazu gehören lokale, globale und Packagevariablen sowie Puffer für die Ausführung von SQL. Wenn mehrere Benutzer dasselbe Programm ausführen, verwaltet jeder Benutzer eine separate Kopie seines privaten SQL-Bereichs, der sessionspezifische Werte enthält, und greift auf einen einzelnen Shared SQL-Bereich zu.

Die Datenbank verarbeitet einzelne SQL-Anweisungen innerhalb einer PL/SQL-Programmeinheit wie zuvor beschrieben. Trotz ihrer Ursprünge innerhalb einer PL/SQL-Programmeinheit verwenden diese SQL-Anweisungen einen Shared Area, um ihre geparsten Darstellungen zu speichern, und einen privaten Bereich für jede Session, in der die Anweisung ausgeführt wird.

Zuweisung und Wiederverwendung von Speicher im Shared Pool

Die Datenbank weist Shared Pool-Speicher zu, wenn eine neue SQL-Anweisung geparst wird, es sei denn, die Anweisung ist DDL, was nicht als gemeinsam verwendbar gilt. Die Größe des zugewiesenen Speichers hängt von der Komplexität der Anweisung ab.

Im Allgemeinen bleibt ein Element im Shared Pool so lange erhalten, bis die Datenbank es gemäß einem LRU-(Least Recently Used-)Algorithmus entfernt. Die Datenbank ermöglicht, dass Shared Pool-Elemente, die von vielen Sessions verwendet werden, im Speicher bleiben, solange sie nützlich sind, selbst wenn der Datenbankprozess, der das Element erstellt hat, beendet wird. Dieser Mechanismus minimiert den Overhead und die Verarbeitung von SQL-Anweisungen. Wenn Speicherplatz für neue Elemente benötigt wird, gibt die Datenbank Speicherplatz frei, der von selten verwendeten Elementen belegt wird.

Die Anweisung ALTER SYSTEM FLUSH SHARED_POOL entfernt alle Informationen im Shared Pool, ebenso wie die Änderung des globalen Datenbanknamens.

Siehe:

Data-Dictionary-Cache

Das Data Dictionary ist eine geschützte Sammlung von Datenbanktabellen und Views, die Referenzinformationen über die Datenbank, ihre Strukturen und ihre Benutzer enthalten.

Oracle AI Database greift beim Parsen von SQL-Anweisungen häufig auf das Data Dictionary zu. Oracle AI Database greift so oft auf das Data Dictionary zu, dass die folgenden speziellen Speicherorte für Dictionary-Daten bestimmt sind:

Alle Serverprozesse verwenden diese Caches für den Zugriff auf Data Dictionary-Informationen gemeinsam.

Siehe:

Serverergebniscache

Der Serverergebniscache ist ein Speicherpool im Shared Pool. Im Gegensatz zu den Pufferpools enthält der Serverergebniscache Ergebnismengen und keine Datenblöcke. Hinweis: Ein Clientergebniscache unterscheidet sich vom Serverergebniscache. Ein Clientcache wird auf Anwendungsebene konfiguriert und befindet sich im Clientspeicher, nicht im Datenbankspeicher.

SQL-Abfrageergebniscache

Der SQL-Abfrageergebniscache ist eine Teilmenge des Serverergebniscaches, in dem die Ergebnisse von Abfragen und Abfragefragmenten gespeichert werden. Sie können das Ergebnis-Caching auf Datenbank- oder Anweisungsebene aktivieren oder deaktivieren.

Wenn eine Abfrage ausgeführt wird, bestimmt die Datenbank, ob das Ergebnis im Abfrageergebniscache vorhanden ist. Wenn das Ergebnis nicht im Cache gespeichert wird und das Caching für die Abfrage aktiviert ist, führt die Datenbank die Abfrage aus, gibt das Ergebnis zurück und speichert es anschließend. Wenn das Ergebnis jedoch vorhanden ist, ruft die Datenbank es aus dem Cache ab, anstatt die Abfrage auszuführen.

Die Datenbank invalidiert automatisch ein gecachtes Ergebnis, wenn eine Transaktion die Daten oder Metadaten von Datenbankobjekten ändert, die zum Erstellen des Ergebnisses verwendet werden. Die nächste Abfrage kann das gecachte Ergebnis nicht verwenden. Daher berechnet die Datenbank automatisch ein neues Ergebnis und speichert es anschließend zur Verwendung durch nachfolgende Abfragen im Cache. Der Cacheaktualisierungsprozess ist für die Anwendung transparent.

Tatsächlich fungiert der Abfrageergebniscache als "Just-in-Time"-Materialized View, die von der Datenbank nach Bedarf erstellt und verwaltet wird. Der Cache ermöglicht es der Datenbank, den aufwändigen Vorgang des erneuten Lesens von Datenblöcken und der Neuberechnung von Ergebnissen zu vermeiden. Die meisten Anwendungen profitieren von dieser Leistungssteigerung.

Siehe auch: Im Oracle AI Database Administrator's Guide erfahren Sie, wie Sie die Antwortzeit mit dem Abfrageergebniscache optimieren.

Ergebniscache für PL/SQL-Funktionen

Der PL/SQL-Funktionsergebniscache ist eine Teilmenge des Serverergebniscaches, in dem Funktionsergebnismengen gespeichert werden.

Ohne Caching würden 1000 Aufrufe einer PL/SQL-Funktion bei 1 Sekunde pro Aufruf 1000 Sekunden dauern. Beim Caching können 1000 Funktionsaufrufe mit den gleichen Eingaben 1 Sekunde gesamt dauern. Gute Kandidaten für das Ergebnis-Caching sind häufig aufgerufene Funktionen, die von relativ statischen Daten abhängen.

Der PL/SQL-Funktionscode kann eine Anforderung zum Cachen der Ergebnisse enthalten. Beim Aufruf dieser Funktion prüft das System den Cache. Wenn der Cache das Ergebnis eines vorherigen Funktionsaufrufs mit denselben Parameterwerten enthält, gibt das System das Ergebnis an den ausführenden Benutzer zurück und führt den Funktionsbody nicht erneut aus. Wenn der Cache das Ergebnis nicht enthält, führt das System den Funktionsbody aus und fügt das Ergebnis (für diese Parameterwerte) dem Cache hinzu, bevor die Kontrolle an den ausführenden Benutzer zurückgegeben wird.

Hinweis: Sie können die Datenbankobjekte angeben, mit denen ein gecachtes Ergebnis berechnet wird. Wenn eines davon aktualisiert wird, wird das gecachte Ergebnis ungültig und muss neu berechnet werden.

Eine Funktion, die häufig mit unterschiedlichen Argumenten aufgerufen wird, kann Ergebnisse generieren, die selten wiederverwendet werden, was zu einer Performanceverschlechterung führt. Oracle AI Database verfolgt zuletzt verwendete PL/SQL-Funktionen mit dem Hint RESULT_CACHE. Mit dieser Historie cacht die Datenbank eine PL/SQL-Funktion und ein Argumentpaar nur, wenn sie x mal in der letzten Historie gesehen hat, wobei x durch einen internen Schwellenwert festgelegt ist. Wenn die Datenbank mehr Speicher benötigt, weil zu viele Ergebnisse im Cache gespeichert werden, werden mindestens ein gecachtes Ergebnis überschrieben.

RESULT_CACHE_EXECUTION_THRESHOLD gibt an, wie oft eine Funktion und eine bestimmte Gruppe von Argumenten angezeigt werden müssen, bis sie gecacht wird. Beachten Sie, dass Funktionen als eindeutig gelten, wenn sie unterschiedliche Argumente aufweisen, z.B. MYFUNC(1,2) und MYFUNC(1,3). Sie können diesen Parameter nur auf Systemebene und nicht auf Sessionebene festlegen.

Siehe:

Serverergebnis-Cache-Infrastruktur

Der Abfrageergebniscache und der PL/SQL-Funktionsergebniscache nutzen dieselbe Infrastruktur.

Objekttypen: Ergebnis, Abhängigkeit und Temp

Im Serverergebniscache ist ein Ergebnisobjekt eine Datenstruktur, in der die von einer Abfrage oder PL/SQL-Funktion zurückgegebenen Zeilen gespeichert werden. Ein Abhängigkeitsobjekt speichert die Metadaten für Objekte, auf die Abfragen verweisen, die als Ergebnisobjekte gespeichert sind.

Ein typisches Abfrageergebnis ist klein, teuer zu berechnen, oft wiederverwendet und basiert auf nichtflüchtigen Tabellen. Die Ergebnisse können jedoch manchmal groß sein. Wenn ein Abfrageergebnis das Größenlimit überschreitet, speichert die Datenbank einen Teil des Ergebnisses als temp-Objekt und einen Teil als Standardergebnisobjekt. Ein temporäres Objekt ist eine Sammlung von Ergebnis-Cache-Metadaten, die auf ein temporäres Tablespace-Segment verweisen, das das tatsächliche Abfrageergebnis enthält.

Ergebnis-Untercaches

Je nach Workload kann die Datenbank Ergebnis-Untercaches erstellen, um einen höheren gleichzeitigen Zugriff während des Lese-/Schreibzugriffs zu unterstützen. Oracle AI Database verwendet einen internen Algorithmus, um zu entscheiden, ob Untercaches erstellt werden sollen, und wenn ja, wie viele erstellt werden sollen.

Benutzeroberfläche des Serverergebniscaches

Der Initialisierungsparameter RESULT_CACHE_MODE bestimmt, ob der SQL-Abfrageergebniscache für alle möglichen Abfragen oder nur für angezeigte Abfragen verwendet wird.

Der Initialisierungsparameter RESULT_CACHE_MAX_TEMP_SIZE steuert den maximalen Temporary Tablespace-Speicher, den der Ergebniscache in der PDB belegen kann. RESULT_CACHE_MAX_TEMP_RESULT steuert den maximalen Temporary Tablespace-Speicher, den eine gecachte Abfrage belegen kann.

Um die Parametereinstellung RESULT_CACHE_MODE außer Kraft zu setzen, können Sie eine Abfrage oder ein Abfragefragment mit einem RESULT_CACHE-Hinweis annotieren. Ab Oracle Database 21c akzeptiert der Hint die Option TEMP={TRUE|FALSE}, mit der gesteuert wird, ob die Ergebnisse in einem temporären Tablespace gespeichert werden können.

Mit dem Package DBMS_RESULT_CACHE können Sie den Teil des Shared Pools verwalten, der vom SQL-Ergebniscache und dem Ergebniscache der PL/SQL-Funktion verwendet wird. Sie können Objekte, Sperrlistenabfragen und Objekte invalidieren und zugehörige Vorgänge ausführen.

Die Spalte V$RESULT_CACHE_OBJECTS.TYPE gibt den Typ der Objekte im Cache an. Wenn Abfrageergebnisse im temporären Tablespace gespeichert werden, zeigt TYPE zwei Objekte an: Result und Temp. Auf Subcache-Metadaten kann über V$RESULT_SUBCACHE_STATISTICS und zugehörige Ansichten zugegriffen werden.

Siehe:

Reservierter Pool

Der reservierte Pool ist ein Speicherbereich im Shared Pool, mit dem Oracle AI Database große zusammenhängende Speicherblöcke zuweisen kann.

Die Datenbank weist Speicher aus dem Shared Pool in Blöcken zu. Durch Chunking können große Objekte (über 5 KB) in den Cache geladen werden, ohne dass ein einzelner zusammenhängender Bereich erforderlich ist. Auf diese Weise verringert die Datenbank die Möglichkeit, dass der zusammenhängende Speicher aufgrund der Fragmentierung ausgeht.

In seltenen Fällen können Java-, PL/SQL- oder SQL-Cursor Zuweisungen aus dem Shared Pool vornehmen, die größer als 5 KB sind. Damit diese Zuweisungen am effizientesten erfolgen können, trennt die Datenbank einen kleinen Teil des Shared Pools für den reservierten Pool.

Siehe auch: In Oracle AI Database Performance Tuning Guide erfahren Sie, wie Sie den reservierten Pool konfigurieren.

Large Pool

Der große Pool ist ein optionaler Speicherbereich, der für Speicherzuweisungen gedacht ist, die größer sind, als für den Shared Pool geeignet ist.

Der Large Pool kann große Speicherzuweisungen für Folgendes bereitstellen:

Die folgende Abbildung zeigt den großen Pool.

Abbildung 7: Großer Pool

Beschreibung der Abbildung cncpt221.png

Siehe:

Speicherverwaltung für große Pools

Der Large Pool verwaltet den Speicher anders als der Shared Pool, der eine LRU-Liste verwendet, sodass Teile des Speichers veraltet sein können.

Der Large Pool hat keine LRU-Liste. Wenn die Datenbank einer Datenbank-Session großen Pool-Speicher zuweist, kann dieser Speicher nur freigegeben werden, wenn er von der Session freigegeben wird. Sobald ein Teil des Speichers freigegeben wird, können andere Prozesse ihn verwenden. Durch die Zuweisung von Sitzungsspeicher aus dem Large Pool vermeidet die Datenbank die Fragmentierung, die im Shared Pool auftreten kann.

Große Poolpuffer für verzögerte Einfügungen

Bei einem speziellen Einfügetyp, der als verzögerter Einfügevorgang bezeichnet wird, weist die Datenbank Puffer aus dem Large Pool zu.

Für schnelle "fire and forget"-Einfügungen aus Internet of Things-(IoT-)Anwendungen verursacht die Datenbankinfrastruktur einen Performance-Overhead. Der Codepfad umfasst beispielsweise die Navigation im Puffercache, Puffer-Pins und den Schutz vor gleichzeitigem Zugriff. Array-Einfügungen minimieren diese Kosten, aber das Array muss auf der Clientseite erstellt werden, was nicht typisch für Internet of Things-Anwendungen ist. Um dieses Problem zu beheben, kann eine Oracle-Anwendung mit einem Hint Zeilen in eine Tabelle einfügen, die als MEMOPTIMIZE FOR WRITE angegeben ist.

Die Einfügungen werden verzögert, weil sie im Large Pool gepuffert und später asynchron von Hintergrundprozessen auf die Festplatte geschrieben werden. Die Datenbank verarbeitet verzögerte Einfügungen wie folgt:

  1. Die Anwendung sendet MEMOPTIMIZE_WRITE-Einfügungen an eine Middle Tier, die Daten aggregieren kann. Während eine IoT-Anwendung fast immer Einfügungen an die Middle Tier sendet, ist es auch möglich, Einfügungen direkt an die Datenbank zu senden. Beispiel: Mit SQL*Plus werden die Einfügungen direkt an die Datenbank gesendet.

  2. Die Middle Tier schreibt die Aggregation von Einfügungen auf den Datenbankserver.

  3. Optional bewahrt der Middle Tier-Client eine lokale Kopie der Daten auf, die er im vorherigen Schritt geschrieben hat.

  4. Ein Serverprozess schreibt Daten in einen Puffer oder Puffer im Large Pool.

    Um Konflikte zu vermeiden, verfügt jeder Puffer über einen eigenen internen Verriegelungsmechanismus. Dieser Sperrmechanismus ist von dem Sperrmechanismus getrennt, den der Datenbankpuffercache für seine Puffer verwendet. Der grundlegende Schreibprozess lautet wie folgt:

    1. Nach dem Hochfahren der Instanz weist die erste MEMOPTIMIZE_WRITE insert die Puffer aus dem Large Pool zu.

    2. Der Writer wählt einen Puffer aus der Liste der verfügbaren Puffer.

    3. Wenn der gewählte Puffer nicht gesperrt ist und dieser Puffer über freien Speicherplatz verfügt, schreibt der Client in den Puffer, wobei jeder Pufferschreibvorgang mit einer sessionspezifischen Folgenummer versehen wird. Wenn nicht, kehrt der Writer zum vorherigen Schritt zurück und fährt auf diese Weise fort, bis entweder ein Puffer gefunden wird oder genügend Speicherplatz im Large Pool freigegeben wurde.

  5. Die Datenbank erstellt aus den gepufferten Daten ein serverseitiges Array.

  6. Der Space Management Coordinator (SMCO) und seine Helper-Prozesse (Wnnn) schreiben das Array asynchron mit dem Standarddatenblockformat auf den Datenträger.

    Im Gegensatz zu Standard-Einfügungen werden verzögerte Einfügungen automatisch festgeschrieben und können nicht zurückgesetzt werden. Die Datenbank schreibt die Einfügungen für ein bestimmtes Objekt in der Reihenfolge fest, in der sie in einer Session angezeigt werden. Es gibt keine Garantie, zwischen Objekten oder Sessions zu sortieren.

    Die Datenbank unterstützt Constraints und Indexverwaltung genauso wie bei regulären Einfügungen. Die Datenbank führt jedoch beim Schreiben auf die Festplatte Auswertungen durch, nicht beim Schreiben in den Large Pool.

    Hinweis: Um eine optimale Performance zu erzielen, empfiehlt Oracle, Constraints zu deaktivieren.

Die folgende Abbildung zeigt den Workflow für verzögerte Einfügungen.

Abbildung 8: Verzögert InsertMechanism

Beschreibung der Abbildung cncpt_pb_002a.png

Siehe:

Java Pool

Beim Java-Pool handelt es sich um einen Speicherbereich, der für die gesamten sessionspezifischen Java-Code und Daten innerhalb der Java Virtual Machine (JVM) speichert. Dieser Speicher umfasst Java-Objekte, die am Ende des Aufrufs in den Java-Sessionbereich migriert werden.

Bei dedizierten Serververbindungen enthält der Java-Pool den gemeinsamen Teil jeder Java-Klasse, einschließlich Methoden und schreibgeschütztem Speicher, wie Codevektoren, aber nicht den Java-Status jeder Session pro Session. Für Shared Server umfasst der Pool den Shared-Teil jeder Klasse und einige UGA, die für den Status jeder Session verwendet werden. Jede UGA wächst und verkleinert sich nach Bedarf. Die gesamte UGA-Größe muss jedoch in den Java-Poolbereich passen.

Die Java Pool Advisor-Statistiken enthalten Informationen zum Library-Cachespeicher, der für Java verwendet wird, und prognostizieren, wie sich Änderungen der Größe des Java-Pools auf die Parse-Rate auswirken können. Java Pool Advisor ist intern aktiviert, wenn statistics_level auf TYPICAL oder höher gesetzt ist. Diese Statistiken werden zurückgesetzt, wenn der Advisor deaktiviert ist.

Siehe:

Feste SGA

Die feste SGA ist ein interner Housekeeping-Bereich.

Beispiel: Die feste SGA enthält:

Die Größe der festen SGA wird von Oracle AI Database festgelegt und kann nicht manuell geändert werden. Die feste SGA-Größe kann von Release zu Release geändert werden.

Siehe auch: "Überblick über automatische Sperren"

Optionale leistungsbezogene SGA-Subareas

Einige SGA-Unterbereiche sind nur für bestimmte Performance-Features aktiviert.

Der vorliegende Abschnitt umfasst die folgenden Themen:

Speicherresidenter Bereich

Der In-Memory-Bereich ist eine optionale SGA-Komponente, die den In-Memory Column Store (IM-Spaltenspeicher) enthält.

Der IM-Spaltenspeicher enthält Kopien von Tabellen, Partitionen und Materialized Views in einem Spaltenformat, das für schnelle Scans optimiert ist. Der IM-Spaltenspeicher ergänzt den Datenbankpuffercache, in dem Daten IM herkömmlichen Zeilenformat gespeichert werden.

Hinweis: Um einen IM-Spaltenspeicher zu aktivieren, muss die Option "Oracle AI Database In-Memory" aktiviert sein.

Siehe auch: Oracle AI Database In-Memory Guide, um mehr über den In-Memory-Bereich und den IM-Spaltenspeicher zu erfahren

Speicheroptimierungspool

Im memoptimize pool werden Puffer und zugehörige Strukturen für Heap-organisierte Tabellen gespeichert, die als MEMOPTIMIZE FOR READ angegeben sind.

Diese Struktur bietet hohe Performance und Skalierbarkeit für schlüsselbasierte Abfragen wie SELECT * FROM cust WHERE cid = 10. Um die End-to-End-Reaktionszeit zu reduzieren, ziehen Clients angeforderte Puffer direkt aus der SGA über das Netzwerk, wodurch CPU- und Betriebssystem-Overhead vermieden werden. Anwendungen können vom memoptimize-Pool profitieren, ohne dass Codeänderungen erforderlich sind.

Der memoptimierungs-Pool enthält zwei Teile:

Beschreibung der Abbildung cncpt_pb_001a.png

Um den memoptimize-Pool zu aktivieren, setzen Sie den Initialisierungsparameter MEMOPTIMIZE_POOL_SIZE auf einen ganzzahligen Wert (der Pool ist standardmäßig deaktiviert). Der Wert gibt die Menge der SGA an, die dem Pool zugewiesen werden soll. Der Wert MEMOPTIMIZE_POOL_SIZE wird auf SGA_TARGET angerechnet, aber die Datenbank vergrößert und verkleinert den memoptimize-Pool nicht automatisch. Beispiel: Wenn SGA_TARGET 10 GB beträgt und MEMOPTIMIZE_POOL_SIZE 1 GB beträgt, sind insgesamt 9 GB für SGA-Speicher außer dem memoptimize-Pool verfügbar.

Um die Größe des memoptimize-Pools zu ändern, müssen Sie MEMOPTIMIZE_POOL_SIZE manuell festlegen und die Datenbankinstanz neu starten. Sie können die Poolgröße nicht dynamisch mit ALTER SYSTEM ändern.

Mit dem Package DBMS_MEMOPTIMIZE können Sie eine Tabelle explizit in den Memoptimize-Pool auffüllen.

Siehe:

Program Global Area (PGA) - Überblick

Die PGA ist speicherspezifisch für einen Betriebssystemprozess oder Thread, der nicht von anderen Prozessen oder Threads im System gemeinsam verwendet wird. Da die PGA prozessspezifisch ist, wird sie niemals in der SGA zugewiesen.

Die PGA ist ein Memory Heap, der sessionabhängige Variablen enthält, die von einem dedizierten oder Shared Server-Prozess benötigt werden. Der Serverprozess weist Speicherstrukturen zu, die er in der PGA benötigt.

Eine Analogie zu einer PGA ist ein temporärer Arbeitsbereich, der von einem Dateikler verwendet wird. In dieser Analogie ist der Datei-Sachbearbeiter der Server-Prozess, der im Auftrag des Kunden arbeitet (Client-Prozess). Der Sachbearbeiter löscht einen Abschnitt der Arbeitsplatte, verwendet den Arbeitsbereich, um Details über die Kundenanforderung zu speichern und die vom Kunden angeforderten Ordner zu sortieren, und gibt dann den Platz auf, wenn die Arbeit abgeschlossen ist.

Die folgende Abbildung zeigt eine Instanz-PGA (Sammlung aller PGAs) für eine Instanz, die nicht für Shared Server konfiguriert ist. Mit einem Initialisierungsparameter können Sie die maximale Zielgröße der Instanz-PGA festlegen. Einzelne PGAs können je nach Bedarf bis zu dieser Zielgröße wachsen.

Abbildung 10: Instanz-PGA

Beschreibung der Abbildung cncpt218.gif

Hinweis: Hintergrundprozesse weisen auch eigene PGAs zu. Diese Diskussion konzentriert sich nur auf Serverprozess-PGAs.

Inhalt der PGA

Die PGA ist in verschiedene Bereiche unterteilt, die jeweils einen anderen Zweck haben.

Die folgende Abbildung zeigt den möglichen Inhalt der PGA für eine dedizierte Server-Session. Nicht alle PGA-Bereiche werden in jedem Fall existieren.

Abbildung 11: PGA-Inhalt

Beschreibung der Abbildung cncpt219.gif

Privater SQL-Bereich

Ein privater SQL-Bereich enthält Informationen zu einer geparsten SQL-Anweisung und anderen sitzungsspezifischen Informationen zur Verarbeitung.

Wenn ein Serverprozess SQL- oder PL/SQL-Code ausführt, verwendet der Prozess den privaten SQL-Bereich, um Variablenwerte, Informationen zum Ausführungsstatus der Abfrage und Arbeitsbereiche für die Abfrageausführung zu speichern.

Verwechseln Sie einen privaten SQL-Bereich, der sich in der PGA befindet, nicht mit dem SQL-Bereich Shared, in dem Ausführungspläne in der SGA gespeichert werden. Mehrere private SQL-Bereiche in denselben oder verschiedenen Sessions können auf einen einzelnen Ausführungsplan in der SGA verweisen. Beispiel: 20 Ausführungen von SELECT * FROM sales in einer Session und 10 Ausführungen derselben Abfrage in einer anderen Session können denselben Plan gemeinsam verwenden. Die privaten SQL-Bereiche für jede Ausführung werden nicht gemeinsam verwendet und können unterschiedliche Werte und Daten enthalten.

Ein Cursor ist ein Name oder ein Handle für einen bestimmten privaten SQL-Bereich. Wie in der folgenden Grafik dargestellt, können Sie einen Cursor als Zeiger auf der Clientseite und als Status auf der Serverseite betrachten. Da Cursor eng mit privaten SQL-Bereichen verknüpft sind, werden die Begriffe manchmal austauschbar verwendet.

Abbildung 12: Cursor

Beschreibung der Abbildung cncpt324.gif

Ein privater SQL-Bereich ist in folgende Bereiche unterteilt:

Der Clientprozess ist für die Verwaltung privater SQL-Bereiche verantwortlich. Die Zuweisung und Aufhebung der Zuweisung privater SQL-Bereiche hängt weitgehend von der Anwendung ab, obwohl die Anzahl der privaten SQL-Bereiche, die ein Clientprozess zuweisen kann, durch den Initialisierungsparameter OPEN_CURSORS begrenzt ist.

Obwohl die meisten Benutzer auf die automatische Cursorbehandlung von Datenbankutilitys angewiesen sind, bieten die programmatischen Schnittstellen von Oracle AI Database Entwicklern mehr Kontrolle über Cursor. Im Allgemeinen sollten Anwendungen alle geöffneten Cursor schließen, die nicht erneut verwendet werden, um den persistenten Bereich freizugeben und den für Anwendungsbenutzer erforderlichen Speicher zu minimieren.

Siehe:

SQL-Arbeitsbereiche

Ein Arbeitsbereich ist eine private Zuweisung von PGA-Speicher, der für speicherintensive Vorgänge verwendet wird.

Beispiel: Ein Sortieroperator verwendet den Sortierbereich, um eine Reihe von Zeilen zu sortieren. Ebenso verwendet ein Hash Join-Operator einen Hash-Bereich, um eine Hash-Tabelle aus der linken Eingabe zu erstellen, während eine Bitmapzusammenführung den Bitmapzusammenführungsbereich verwendet, um Daten zusammenzuführen, die aus Scans mehrerer Bitmapindizes abgerufen wurden.

Das folgende Beispiel zeigt einen Join von employees und departments mit dem zugehörigen Abfrageplan:

SQL> SELECT *
  2  FROM   employees e JOIN departments d
  3  ON     e.department_id=d.department_id
  4  ORDER BY last_name;
.
.
.
--------------------------------------------------------------------------------
| Id| Operation           | Name        | Rows  | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT    |             |   106 |  9328 |    7  (29)| 00:00:01 |
| 1 |  SORT ORDER BY      |             |   106 |  9328 |    7  (29)| 00:00:01 |
|*2 |   HASH JOIN         |             |   106 |  9328 |    6  (17)| 00:00:01 |
| 3 |    TABLE ACCESS FULL| DEPARTMENTS |    27 |   540 |    2   (0)| 00:00:01 |
| 4 |    TABLE ACCESS FULL| EMPLOYEES   |   107 |  7276 |    3   (0)| 00:00:01 |
--------------------------------------------------------------------------------

Im vorherigen Beispiel verfolgt der Laufzeitbereich den Fortschritt der Full Table Scans. Die Session führt einen Hash Join im Hash-Bereich aus, um Zeilen aus den beiden Tabellen abzugleichen. Die Sortierung ORDER BY erfolgt im Sortierbereich.

Wenn die von den Operatoren zu verarbeitende Datenmenge nicht in einen Arbeitsbereich passt, teilt Oracle AI Database die Eingabedaten in kleinere Teile auf. Auf diese Weise verarbeitet die Datenbank einige Datenteile im Speicher, während der Rest zur späteren Verarbeitung in den temporären Datenträgerspeicher geschrieben wird.

Die Datenbank optimiert automatisch die Arbeitsbereichsgrößen, wenn die automatische PGA-Speicherverwaltung aktiviert ist. Sie können die Größe eines Arbeitsbereichs auch manuell steuern und optimieren.

Im Allgemeinen können größere Arbeitsbereiche die Leistung eines Operators erheblich verbessern, wenn der Speicherverbrauch höher ist. Optimal ist die Größe eines Arbeitsbereichs ausreichend, um die vom zugehörigen SQL-Operator zugewiesenen Eingabedaten und Auxiliary-Speicherstrukturen aufzunehmen. Andernfalls erhöht sich die Antwortzeit, da ein Teil der Eingabedaten auf dem Datenträger gecacht werden muss. Wenn die Größe eines Arbeitsbereichs im Vergleich zur Größe der Eingabedaten zu klein ist, muss die Datenbank im Extremfall mehrere Durchläufe über die Datenelemente durchführen, was die Antwortzeit drastisch erhöht.

Siehe:

PGA-Nutzung in dedizierten und Shared Server-Modi

Die Zuweisung des PGA-Speichers hängt davon ab, ob die Datenbank dedizierte oder Shared Server-Verbindungen verwendet.

In der folgenden Tabelle werden die Unterschiede aufgeführt.

Tabelle 1: Unterschiede bei der Speicherzuweisung zwischen dedizierten und Shared Servern

Speicherbereich Dedizierter Server Shared Server
Art des Sitzungsgedächtnisses Privat Gemeinsam
Speicherort des persistenten Bereichs PGA SGA
Speicherort des Laufzeitbereichs für DML- und DDL-Anweisungen PGA PGA

Siehe auch: Im Oracle AI Database Administrator's Guide erfahren Sie, wie Sie eine Datenbank für Shared Server konfigurieren.

Überblick über den globalen Benutzerbereich

Bei der UGA handelt es sich um den Session-Speicher, der Session-Variablen zugewiesen wird, z. B. Anmeldeinformationen, und andere Informationen, die von einer Datenbank-Session benötigt werden. Im Wesentlichen speichert die UGA den Sessionzustand.

Die folgende Abbildung zeigt die UGA.

Abbildung 13: User Global Area (UGA)

Beschreibung der Abbildung cncpt222.gif

Wenn eine Session ein PL/SQL-Package in den Speicher lädt, enthält die UGA den Packagestatus. Dabei handelt es sich um das Werteset, das zu einem bestimmten Zeitpunkt in allen Packagevariablen gespeichert ist. Der Paketstatus ändert sich, wenn ein Paketunterprogramm die Variablen ändert. Standardmäßig sind die Packagevariablen für die Dauer der Session eindeutig und werden beibehalten.

Der OLAP-Seitenpool wird ebenfalls in der UGA gespeichert. Dieser Pool verwaltet OLAP-Datenseiten, die Datenblöcken entsprechen. Der Seitenpool wird zu Beginn einer OLAP-Session zugewiesen und am Ende der Session freigegeben. Eine OLAP-Session wird automatisch geöffnet, wenn ein Benutzer ein Dimensionsobjekt abfragt, z.B. einen Cube.

Die UGA muss für die Dauer der Session für eine Datenbank-Session verfügbar sein. Aus diesem Grund kann die UGA nicht in der PGA gespeichert werden, wenn eine Shared Server-Verbindung verwendet wird, da die PGA für einen einzelnen Prozess spezifisch ist. Daher wird die UGA in der MGA gespeichert, wenn Shared Server-Verbindungen verwendet werden, sodass alle Shared Server-Prozesse darauf zugreifen können. Wenn Sie eine dedizierte Server-Verbindung verwenden, wird die UGA in der PGA gespeichert.

Siehe:

Überblick über die Managed Global Area (MGA)

Die Managed Global Area (MGA) ist ein einzigartiges Speicher-Framework, mit dem Speicher über eine Reihe vertrauenswürdiger Oracle-Prozesse hinweg gemeinsam genutzt und koordiniert werden kann.

Es kann ein konfigurierbarer, elastischer, modularer, On-Demand-wiederherstellbarer Shared Memory-Bereich sein. Mit MGA können Sie verschiedene Typen von Shared Memory-Bereichen in der Datenbank verwenden. Sie wird als Namespaces für interne Datenbanklayer bereitgestellt, die jeweils nur zu einem dieser Layer gehören. Ein Namespace besteht hauptsächlich aus einer Gruppe von Shared Memory-Segmenten und Metadaten, die zusammen mit ihm verwendet werden.

Die Schichten in der Datenbank können die Eigenschaften, den Geltungsbereich, die Lebensdauer und die interne Segmentgröße des Namespace definieren. Alle MGA werden unter dem PGA-Aggregatgrenzwert gebucht.

Bei Linux erfordert die MGA tempfs, das auf /dev/shm gemountet ist, und ist so konfiguriert, dass sie mindestens die Größe des PGA-Aggregatlimits aufweist. Wenn mehrere Instanzen auf demselben Rechner ausgeführt werden, muss die Größe von /dev/shm über alle Instanzen hinweg mindestens sum(PGA_AGGREGATE_LIMIT) betragen.

Siehe:

Überblick über Softwarecodebereiche

Ein Softwarecodebereich ist ein Teil des Speichers, in dem Code gespeichert ist, der ausgeführt oder ausgeführt werden kann. Oracle AI Database-Code wird in einem Softwarebereich gespeichert, der in der Regel exklusiver und geschützter ist als der Speicherort von Benutzerprogrammen.

Softwarebereiche sind in der Regel statisch und ändern sich nur, wenn die Software aktualisiert oder neu installiert wird. Die erforderliche Größe dieser Bereiche variiert je nach Betriebssystem.

Softwarebereiche sind schreibgeschützt und können gemeinsam genutzt oder nicht gemeinsam verwendet werden. Einige Datenbanktools und -utilitys, wie Oracle Forms und SQL*Plus, können gemeinsam installiert werden, einige jedoch nicht. Wenn möglich, wird Datenbankcode gemeinsam verwendet, sodass alle Benutzer darauf zugreifen können, ohne mehrere Kopien im Speicher zu haben, was zu einer Verringerung des Hauptspeichers und einer allgemeinen Verbesserung der Leistung führt. Mehrere Instanzen einer Datenbank können denselben Datenbankcodebereich mit verschiedenen Datenbanken verwenden, wenn sie auf demselben Computer ausgeführt werden. Hinweis: Die Option zum Installieren von gemeinsam genutzter Software ist nicht für alle Betriebssysteme verfügbar, z.B. auf PCs mit Microsoft Windows. Weitere Informationen finden Sie in der Dokumentation zu Ihrem Betriebssystem.