Externen Tabellencache verwenden, um die Performance für externe Tabellen zu verbessern
Mit dem externen Tabellencache in Oracle Autonomous AI Database können Sie Daten, auf die häufig zugegriffen wird, aus externen Tabellen in der Datenbank cachen.
Externer Tabellencache wird nur für Oracle AI Database 26ai unterstützt.
- Externen Tabellencache in autonomer KI-Datenbank
Ein externer Tabellencache ist ein Speicherbereich in Ihrer autonomen KI-Datenbank, in dem die Daten aus einer externen Tabelle gespeichert werden. - Schnellstart mit externen Tabellencaches
Zeigt Beispiele an, mit denen Sie mit dem Erstellen und Auffüllen externer Tabellencaches beginnen können. - Caching-Voreinstellung auswählen
Beschreibt, wie Sie die entsprechende Caching-Voreinstellung auswählen, einschließlich Cacheverhalten und Größenzuweisung für externe Tabellen. - Voraussetzungen zum Erstellen des Cache für externe Tabellen
Listet die Voraussetzungen zum Erstellen des Cache für externe Tabellen auf. - Policy-basiertes Caching für externe Tabellen verwenden
Beschreibt, wie Sie das Policy-basierte Caching für externe Tabellen in der autonomen KI-Datenbank verwenden. - Automatisches Caching für externe Tabelle verwenden
Beschreibt, wie Sie das automatische Caching für externe Tabellen in einer autonomen KI-Datenbank verwenden. - Performance des externen Tabellencaches überwachen und diagnostizieren
Die autonome KI-Datenbank bietet Ansichten, mit denen Sie den externen Tabellencache überwachen können. - Anwendungsfälle für das Caching externer Tabellen
Beschreibt allgemeine Szenarios, in denen das Caching externer Tabellen von Vorteil ist.
Übergeordnetes Thema: Features
Externen Tabellencache in autonomer KI-Datenbank
Ein externer Tabellencache ist ein Speicherbereich in Ihrer autonomen KI-Datenbank, in dem die Daten aus einer externen Tabelle gespeichert werden.
Externe Daten werden nicht von der Datenbank verwaltet. Sie können jedoch die externen Tabellen verwenden, um Daten außerhalb der Datenbank abzufragen. Abfragen für externe Tabellen sind nicht so schnell wie Abfragen für Datenbanktabellen, da sie jedes Mal, wenn Sie auf die Daten zugreifen, aus den externen Dateien abgerufen werden müssen, die im Objektspeicher gespeichert sind.
Mit dem externen Tabellencache können Sie häufig besuchte externe Daten lokal speichern. Wenn Sie den Cache verwenden, können Abfragen externer Tabellen Daten direkt aus der autonomen KI-Datenbank abrufen, wodurch sie wesentlich schneller werden. Sie müssen vorhandene SQL-Anweisungen oder Workflows nicht ändern, um von einem schnelleren Zugriff zu profitieren, da dieser Caching-Mechanismus für Anwendungen vollständig transparent ist. Sie können einen externen Tabellencache für partitionierte und nicht partitionierte externe Tabellen erstellen, die in Parquet-, ORC-, AVRO-, CSV- und Iceberg-Tabellen erstellt wurden.
-
Verbesserte Performance für Analysen: Abfragen sind für Ihre häufig aufgerufenen externen Daten um ein Vielfaches schneller – ideal für Dashboards, Berichte und Analysetools, die regelmäßig auf dieselben Daten zugreifen.
-
100% transparent: Der Caching-Mechanismus ist vollständig transparent. Anwendungen können von einer verbesserten Geschwindigkeit profitieren, ohne dass Änderungen an ihren Abfragen, Dashboards oder Anwendungen erforderlich sind.
-
Niedrigere Cloud-Kosten: In einer Multi-Cloud-Anwendung reduziert das Caching den Bedarf an wiederholten externen Datenabrufen aus dem Remotespeicher und reduziert so die Gebühren für den Datenausgang, die mit dem Zugriff auf Daten über Regionen oder Clouds verbunden sind.
-
Fein granuliertes, flexibles Caching-Steuerelement: Sie können alle Dateien, einen Prozentsatz der Dateien oder nur die zuletzt aktualisierten Daten cachen. Sie können die gecachten Daten, die Cachegröße und die Speicherlimits für externe Tabellencaches steuern.
Externe Tabellencaches in der Datenbank können automatisch oder über richtlinienbasierte Einstellungen verwaltet werden. Mit Policy-basiertem Cache-Management können Sie einfache Policys definieren, mit denen Dateien aus dem Cache gefüllt, aktualisiert und als veraltet eingestuft werden. So erhalten Sie genaue Kontrolle über Cache-Inhalte und -Wartung.
Weitere Informationen finden Sie unter Externe Daten abfragen.
Übergeordnetes Thema: Externen Tabellencache zur Performanceverbesserung für externe Tabellen verwenden
Schnellstart mit externen Tabellencaches
Enthält Beispiele für die ersten Schritte beim Erstellen und Auffüllen externer Tabellencaches.
Erstellen Sie einen Policy-basierten externen Tabellencache für das SALES-Schema.
Wenn Sie einen Cache erstellen, ist er zunächst leer und für die Population aktiviert. Die Cachegröße erhöht sich jedes Mal, wenn eine Datei hinzugefügt wird, abhängig von den definierten Speicherplatz-Quota-Grenzwerten für das Schema, bis sie die zugewiesenen Grenzwerte erreicht.
DBMS_EXT_TABLE_CACHE.CREATE_CACHE, um einen externen Tabellencache für Ihr Schema zu erstellen. Beispiel:BEGIN
DBMS_EXT_TABLE_CACHE.CREATE_CACHE (
owner => 'SALES',
table_name => 'STORE_SALES',
partition_type => 'PATH');
END;
/
Dadurch wird ein Cache für die Tabelle STORE_SALES im Schema SALES erstellt. Die STORE_SALES ist eine externe Tabelle, die auf im Objektspeicher gespeicherte Daten verweist.
Der Parameter owner gibt den Schemanamen an. In diesem Beispiel wird ein externer Tabellencache für den Benutzer SALES erstellt.
partition_type steuert, wie der Cache aufgeteilt wird. Bei 'PATH' wird der Cache nach dem Ordnerpfad jeder Quelldatei partitioniert. FILE$PATH ist eine ausgeblendete Spalte, in der dieser Ordnerpfad (alles vor dem Dateinamen) gespeichert wird.
…/n/<ns>/b/<bucket>/o/sales/2024/09/data1.parquet ist, wird FILE$PATH = 'sales/2024/09/' (der Ordner) verwendet.
USER_EXTERNAL_TAB_CACHES abfragen, um die Cacheerstellung zu prüfen. Beispiel:SELECT external_table_name, cached, disabled
FROM user_external_tab_caches;DBMS_EXT_TABLE_CACHE.VALIDATE, um einen externen Tabellencache zu validieren. Ein Fehler wird gemeldet, wenn die referenzierte externe Tabelle nicht in der Datenbank gefunden wurde. Beispiel:BEGIN
DBMS_EXT_TABLE_CACHE.VALIDATE (
owner => 'SALES',
table_name => 'STORE_SALES',
raise_errors => TRUE);
END;
/Führen Sie DBMS_EXT_TABLE_CACHE.ADD_TABLE aus, um eine gesamte Tabelle in den Cache zu füllen. Beispiel:
BEGIN
DBMS_EXT_TABLE_CACHE.ADD_TABLE (
owner => 'SALES',
table_name => 'STORE_SALES');
END;
/In diesem Beispiel wird versucht, die Tabelle STORE_SALES in den Cache zu füllen.
Automatisch verwaltete externe Tabellencaches erstellen
Standardmäßig ist das automatische Caching deaktiviert. AUTO-Caches werden automatisch erstellt, wenn Sie das automatische Caching aktivieren.
DBMS_CACHE.SET_USER_PROPERTY aus, um das automatische Caching der externen Tabelle für das HR-Schema zu aktivieren. Beispiel: BEGIN
DBMS_CACHE.SET_USER_PROPERTY (
property_name => 'max_cache_size',
property_value_num => 10737418240);
END;
/In diesem Beispiel wird das automatische Caching für das HR-Schema aktiviert, und der Parameter MAX_CACHE_SIZE wird auf 10737418240 Byte gesetzt. Dabei wird eine maximale Cachezuweisung von 10 GB für externe Tabellen im HR-Schema angegeben. Außerdem werden die erforderlichen Caches für externe Tabellen erstellt und gefüllt.
BEGIN
DBMS_CACHE.SET_GLOBAL_PROPERTY (
property_name => 'max_cache_percent',
property_value_num => 20);
END;
/Verwenden Sie die globale Eigenschaft MAX_CACHE_PERCENT, um das Standardcachelimit für alle Benutzer festzulegen. Wenn Sie MAX_CACHE_PERCENT auf 20 setzen, kann das automatische Caching externer Tabellen bis zu 20% der zugewiesenen Tablespace-Quota jedes Benutzers belegen (Beispiel: Ein Benutzer mit einer Quota von 100 GB kann bis zu 20 GB cachen, ein Benutzer mit einer Quota von 10 GB bis zu 2 GB). Diese globale Einstellung gilt nur für das automatische Caching und gilt pro Benutzer und nicht für alle Benutzer. Sie können diesen Standardwert für einzelne Benutzer außer Kraft setzen, indem Sie die Prozedur DBMS_CACHE.SET_USER_PROPERTY ausführen.
SELECT external_table_name, cached, auto
FROM all_external_tab_caches;DBMS_CACHE.REFRESH verwenden, um eine On-Demand-Aktualisierung für alle Caches eines angegebenen Benutzers auszuführen. Beispiel:BEGIN
DBMS_CACHE.REFRESH (
owner => 'HR',
refresh_type => 'ALL');
END;
/In diesem Beispiel werden vorhandene Caches aktualisiert und bei Bedarf neue externe Tabellencaches für das Schema HR erstellt. Die Eigenschaft refresh_type gibt den Geltungsbereich an, in dem die Aktualisierung ausgeführt wird.
Übergeordnetes Thema: Externen Tabellencache zur Performanceverbesserung für externe Tabellen verwenden
Wählen Sie Ihre Caching-Voreinstellung
Der externe Tabellencache wird als Schemaobjekt in der Datenbank erstellt. Dabei wird physischer Speicherplatz zugewiesen, ähnlich wie Tabellen und Indizes in Datendateien gespeichert werden. Wenn Sie einen externen Tabellencache erstellen, wird eine neue Tabelle in Ihrem Schema erstellt, und alle für Ihr Schema festgelegten Speicherplatz-Quota-Grenzwerte gelten auch für den externen Tabellencache.
-
Policy-basierte Cacheverwaltung
-
Sie definieren explizit, wie Caches erstellt, gefüllt, aktualisiert und eingestellt werden.
-
Bietet feingranulierte Kontrolle über Cache-Inhalte und -Lebenszyklus.
-
Geeignet, wenn vorhersehbares oder angepasstes Caching-Verhalten erforderlich ist.
-
-
Automatische Cache-Verwaltung
-
Die Datenbank erstellt, füllt, aktualisiert und löscht automatisch Caches.
-
Aktionen werden durch externe Tabellenabfragemuster und Workload-Nutzung gesteuert.
-
Ideal für Umgebungen, in denen sich das Caching-Verhalten ohne manuelle Eingriffe dynamisch anpassen muss.
-
Übergeordnetes Thema: Externen Tabellencache zur Performanceverbesserung für externe Tabellen verwenden
Voraussetzungen zum Erstellen des Cache für externe Tabellen
Listet die Voraussetzungen für die Erstellung des Cache für externe Tabellen auf.
-
Sie können nur einen externen Tabellencache in Ihrem eigenen Schema und für die externen Tabellen erstellen, deren Eigentümer Sie sind.
-
Sie müssen eine geeignete Speicherplatz-Quota für Ihr Schema zugewiesen haben, um sicherzustellen, dass genügend Speicherkapazität für die Cachedaten vorhanden ist.
-
Sie benötigen Zugangsdaten für den Zugriff auf externe Tabellendateien, die im Objektspeicher gespeichert sind. Sie müssen keine Zugangsdaten erstellen, wenn Sie Resource Principal-Zugangsdaten für den Zugriff auf den Oracle Cloud Infrastructure-Objektspeicher aktivieren.
Übergeordnetes Thema: Externen Tabellencache zur Performanceverbesserung für externe Tabellen verwenden
Policy-basiertes Caching für externe Tabellen verwenden
Beschreibt, wie Sie Policy-basiertes Caching für externe Tabellen in Autonomous AI Database verwenden.
Policy-basiertes Caching bietet Ihnen explizite Kontrolle darüber, wie externe Daten in der Datenbank gecacht, aktualisiert und verwaltet werden. In diesem Ansatz definieren Sie Caching-Policys und verwalten den gesamten Cachelebenszyklus mit PL/SQL-Prozeduren, die im Package DBMS_EXT_TABLE_CACHE verfügbar sind. Mit diesen Prozeduren können Sie verschiedene Cache-Lebenszyklusvorgänge explizit ausführen, wie das Erstellen und Füllen von Caches, das Löschen von Dateien aus dem Cache und das Aktivieren oder Deaktivieren der Caches.
Mit diesem Ansatz können Sie das Cache-Verhalten fein granuliert steuern. Sie können angeben, welche externen Tabellendateien oder welcher Prozentsatz der Daten einer externen Tabelle gecacht werden sollen, um eine optimale Nutzung des Cachespeichers basierend auf den Workload-Anforderungen sicherzustellen. Mit Prozeduren wie ADD_BY_LIKE und ADD_LATEST_FILES können Sie Dateien basierend auf verschiedenen Parametern filtern und in den Cache füllen, wie z.B. Dateinamensmustern, Änderungszeiten oder Kriterien zur Datenaktualität. Ebenso können Sie Prozeduren wie CLEAR, RETIRE_FILES oder DROP_BY_LIKE verwenden, um Dateien aus dem Cache zu entfernen.
Da Policy-basierte Caches nicht von einem automatischen Löschalgorithmus verwaltet werden, lässt die Datenbank sie nicht automatisch unter Speicherplatzdruck fallen. Wenn der Cachespeicher nicht mehr verfügbar ist, können neue Dateien möglicherweise erst aufgefüllt werden, wenn zusätzlicher Speicherplatz freigegeben wird. Dieser Ansatz bietet mehr Flexibilität und ist ideal für Workloads geeignet, bei denen Sie mehr Kontrolle über Cacheinhalte benötigen.
Weitere Informationen finden Sie unter DBMS_EXT_TABLE_CACHE Package.
Im folgenden Flussdiagramm werden die Schritte zum Verwalten Policy-basierter Caches mit dem Package DBMS_EXT_TABLE_CACHE beschrieben. Es umfasst wichtige Schritte wie die Erstellung von Caches, die Auffüllung und das Löschen.
Themen
- Dateien in externen Tabellencache laden
Beschreibt, wie Sie den zuvor erstellten Policy-basierten Cache auffüllen. - Dateien aus externem Tabellencache löschen
Zeigt Beispiele zum Löschen von Dateien aus externem Tabellencache an. - Externen Tabellencache deaktivieren und aktivieren
Zeigt Beispiele zum Deaktivieren und Aktivieren des Cache für externe Tabellen an. - Externen Tabellencache löschen
Zeigt ein Beispiel zum Löschen des externen Tabellencaches. - Optionale Größenvoreinstellungen für Policy-basierte Caches festlegen
Beschreibt, wie Sie Größenvoreinstellungen für Policy-basierte externe Tabellencaches in der autonomen KI-Datenbank festlegen.
Übergeordnetes Thema: Externen Tabellencache zur Performanceverbesserung für externe Tabellen verwenden
Dateien in externen Tabellencache auffüllen
Beschreibt, wie der zuvor erstellte Policy-basierte Cache gefüllt wird.
Nachdem Sie einen Cache erstellt haben, können Sie Dateien in den Cache füllen. Beim Auffüllen von Dateien wird der Inhalt der angegebenen externen Tabellendateien in den Cache geladen. Sie können wählen, ob Sie alle Dateien aus einer Tabelle oder einen bestimmten Prozentsatz der Tabelle auffüllen oder eine Filterbedingung angeben, um die Dateien zu begrenzen, die Sie auffüllen möchten. Beispiel: Sie können die Dateien nach ihren Namen oder einem Datumsbereich filtern.
-
Je nachdem, welche Speicherplatz-Quota dem Schema zugewiesen ist, versucht Oracle, Dateien in den Cache zu füllen. Wenn der zugewiesene Quota-Grenzwert erreicht ist, füllt Oracle keine Dateien mehr auf, es sei denn, der erforderliche Speicherplatz wird zugewiesen.
-
Der Cache der externen Tabelle wird nicht automatisch aktualisiert. Um den Cache zu aktualisieren, wenn eine Datei im Objektspeicher geändert wird, müssen Sie die Datei erneut auffüllen.
-
Wenn eine Datei aus dem Objektspeicher gelöscht wird, werden die entsprechenden gecachten Daten sofort ungültig und können nicht abgerufen werden.
Tabelle zu externem Tabellencache hinzufügen
Verwenden Sie DBMS_EXT_TABLE_CACHE.ADD_TABLE, um eine gesamte Tabelle oder einen bestimmten Prozentsatz der externen Tabelle in den Cache zu füllen.
Beispiele
BEGIN
DBMS_EXT_TABLE_CACHE.ADD_TABLE (
owner => 'SALES',
table_name => 'STORE_SALES');
END;
/In diesem Beispiel wird versucht, die Tabelle STORE_SALES in den Cache aufzufüllen. Dabei werden alle vorhandenen Dateien übersprungen, die bereits aufgefüllt wurden.
BEGIN
DBMS_EXT_TABLE_CACHE.ADD_TABLE (
owner => 'SALES',
table_name => 'STORE_SALES',
percent_files => 80);
END;
/In diesem Beispiel wird versucht, 80% der Tabelle STORE_SALES in den Cache aufzufüllen. Alle vorhandenen Dateien, die bereits aufgefüllt wurden, werden übersprungen.
Der Parameter percent_files ist optional. Wenn Sie diesen Parameter nicht angeben, wird die gesamte Tabelle in den Cache gefüllt.
Weitere Informationen finden Sie unter Prozedur ADD_TABLE.
Dateien zu externem Tabellencache hinzufügen
-
ADD_FILE: Zum Hinzufügen einer einzelnen Datei in den Cache. -
ADD_BY_LIKE: Zum Hinzufügen einer oder mehrerer angegebener Dateien basierend auf den angegebenen Pfadfiltern. -
ADD_LATEST_FILES: Zum Hinzufügen einer oder mehrerer Dateien basierend auf dem angegebenen Zeitintervall.
Beispiele
DBMS_EXT_TABLE_CACHE.ADD_FILE, um eine einzelne Datei in den externen Tabellencache zu füllen. Beispiel:BEGIN
DBMS_EXT_TABLE_CACHE.ADD_FILE (
owner => 'SALES',
table_name => 'STORE_SALES',
file_url => 'https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/salesdata.parquet'
);
END;
/In diesem Beispiel werden Daten aus der Datei salesdata.parquet in den Cache gefüllt.
In diesem Beispiel wird das Auffüllen der Datei in den Cache übersprungen, wenn die angegebene Datei im Cache vorhanden ist und seit dem letzten Zwischenspeichern der Datei nicht mehr geändert wurde.
Weitere Informationen finden Sie unter Prozedur ADD_FILE.
DBMS_EXT_TABLE_CACHE.ADD_BY_LIKE, um eine oder mehrere Dateien in den externen Tabellencache zu füllen. Beispiel:BEGIN
DBMS_EXT_TABLE_CACHE.ADD_BY_LIKE (
owner => 'SALES',
table_name => 'STORE_SALES',
path_filters => '["https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales%.parquet",
"https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/customer%.parquet"]'
);
END;
/In diesem Beispiel werden alle Dateien mit Namen gefüllt, die mit sales oder customer beginnen, während Dateien ausgeschlossen werden, die bereits aufgefüllt wurden.
BEGIN
DBMS_EXT_TABLE_CACHE.ADD_BY_LIKE (
owner => 'SALES',
table_name => 'STORE_SALES',
path_filters => '["https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales#_data1.parquet",
"https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales#_data2.parquet"]',
esc_char => '#',
force => TRUE);
END;
/In diesem Beispiel werden die Dateien sales_data1.parquet und sales_data2.parquet in den Cache gefüllt.
In diesem Beispiel wird das Zeichen "#" als Escapezeichen definiert. Das Zeichen "_" nach "#" wird als literaler Unterstrich und nicht als Platzhalter behandelt, der mit einem einzelnen Zeichen übereinstimmt.
Weitere Informationen finden Sie unter Prozedur ADD_BY_LIKE.
DBMS_EXT_TABLE_CACHE.ADD_LATEST_FILES, um eine oder mehrere Dateien basierend auf dem letzten Änderungsdatum in den externen Tabellencache zu füllen. Beispiel:BEGIN
DBMS_EXT_TABLE_CACHE.ADD_LATEST_FILES (
owner => 'SALES',
table_name => 'STORE_SALES',
since => INTERVAL '7' DAY,
max_files => 5,
force => TRUE);
END;
/Der Parameter since gibt das Zeitintervall an. Nur Dateien, die innerhalb der letzten sieben (7) Tage geändert wurden, können in den Cache aufgefüllt werden.
Der Parameter max_files begrenzt die Anzahl der Dateien, die in den Cache aufgefüllt werden können. In diesem Beispiel werden nur fünf (5) Dateien aufgefüllt.
Der Parameter force erzwingt, dass die angegebenen Dateien im Cache überschrieben werden, selbst wenn die Dateien nicht geändert wurden.
Weitere Informationen finden Sie unter Prozedur ADD_LATEST_FILES.
Übergeordnetes Thema: Policy-basiertes Caching für externe Tabellen verwenden
Dateien aus externem Tabellencache löschen
Zeigt Beispiele zum Löschen von Dateien aus dem externen Tabellencache.
Cache für externe Tabelle löschen
Verwenden Sie DBMS_EXT_TABLE_CACHE.CLEAR, um alle Dateien aus dem externen Tabellencache zu löschen. Beispiel:
BEGIN
DBMS_EXT_TABLE_CACHE.CLEAR (
owner => 'SALES',
table_name => 'STORE_SALES');
END;
/In diesem Beispiel werden alle Dateien aus dem STORE_SALES-Cache gelöscht, und der gesamte Speicherplatz, der von den entfernten Dateien belegt wird, wird aufgehoben.
Weitere Informationen finden Sie unter CLEAR-Prozedur.
Dateien aus externem Tabellencache löschen
-
DROP_FILE: zum Löschen einer einzelnen Datei aus dem Cache. -
DROP_BY_LIKE: Zum Löschen einer oder mehrerer Dateien aus dem Cache basierend auf den angegebenen Pfadfiltern. -
RETIRE_FILES: Zum Löschen einer oder mehrerer Dateien aus dem Cache basierend auf dem angegebenen Intervall.
Beispiele
Verwenden Sie DBMS_EXT_TABLE_CACHE.DROP_FILE, um eine Datei aus dem externen Tabellencache zu löschen. Beispiel:
BEGIN
DBMS_EXT_TABLE_CACHE.DROP_FILE (
owner => 'SALES',
table_name => 'STORE_SALES',
file_url => 'https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/salesdata.parquet'
);
END;
/In diesem Beispiel wird die Datei salesdata.parquet aus dem Cache gelöscht, und der gesamte Speicherplatz, der von der entfernten Datei belegt wird, wird aufgehoben.
Weitere Informationen finden Sie unter Prozedur DROP_FILE.
Verwenden Sie DBMS_EXT_TABLE_CACHE.DROP_BY_LIKE, um eine oder mehrere Dateien basierend auf dem Parameter path_filters zu löschen. Beispiel:
BEGIN
DBMS_EXT_TABLE_CACHE.DROP_BY_LIKE (
owner => 'SALES',
table_name => 'STORE_SALES',
path_filters => '["https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/salesdata.parquet",
"https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/salesdata1.parquet"]'
);
END;
/In diesem Beispiel werden die Dateien salesdata.parquet und salesdata1.parquet aus dem Cache gelöscht, und der gesamte Speicherplatz, der von den entfernten Dateien belegt wird, wird aufgehoben.
BEGIN
DBMS_EXT_TABLE_CACHE.DROP_BY_LIKE (
owner => 'SALES',
table_name => 'STORE_SALES',
path_filters => '["https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales#_data1.parquet",
"https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/your_namespace/your_bucket/sales#_data2.parquet"]'
);
END;
/In diesem Beispiel werden die Dateien sales#_data1 und sales#_data2 aus dem Cache gelöscht, und der gesamte Speicherplatz, der von den entfernten Dateien belegt wird, wird aufgehoben.
In diesem Beispiel wird das Zeichen "#" als Escapezeichen definiert. Das Zeichen "_" nach "#" wird als literaler Unterstrich und nicht als Platzhalter behandelt, der mit einem einzelnen Zeichen übereinstimmt.
Weitere Informationen finden Sie unter Prozedur DROP_BY_LIKE.
Verwenden Sie DBMS_EXT_TABLE_CACHE.RETIRE_FILES, um eine oder mehrere Dateien basierend auf dem angegebenen Intervall zu löschen. Beispiel:
BEGIN
DBMS_EXT_TABLE_CACHE.RETIRE_FILES (
owner => 'SALES',
table_name => 'STORE_SALES',
before => INTERVAL '30' DAY);
END;
/In diesem Beispiel werden Dateien, die älter als dreißig (30) Tage sind, aus dem Cache gelöscht und der gesamte von den entfernten Dateien belegte Speicherplatz freigegeben.
Weitere Informationen finden Sie unter Prozedur RETIRE_FILES.
In den obigen Beispielen werden eine oder mehrere Dateien aus dem Cache entfernt, während der Cache beibehalten wird. Sie können Dateien bei Bedarf erneut in den Cache laden. Weitere Informationen finden Sie unter Dateien in externen Tabellencache füllen.
Übergeordnetes Thema: Policy-basiertes Caching für externe Tabellen verwenden
Externen Tabellencache deaktivieren und aktivieren
Zeigt Beispiele zum Deaktivieren und Aktivieren des Cache für externe Tabellen.
Führen Sie DBMS_EXT_TABLE_CACHE.DISABLE aus, um den externen Tabellencache aus der Datenbank zu deaktivieren. Wenn Sie einen Cache deaktivieren, werden keine Daten aus dem Cache gelöscht. Stattdessen wird der Cache als DISABLED gekennzeichnet, und der Optimizer kann den Cache nicht für Query Rewrites verwenden.
Beispiel
BEGIN
DBMS_EXT_TABLE_CACHE.DISABLE (
owner => 'SALES',
table_name => 'STORE_SALES');
END;
/In diesem Beispiel wird der STORE_SALES-Cache deaktiviert.
Weitere Informationen finden Sie unter DISABLE-Prozedur.
Nachdem Sie einen externen Tabellencache deaktiviert haben, aktivieren Sie den Cache mit DBMS_EXT_TABLE_CACHE.ENABLE.
BEGIN
DBMS_EXT_TABLE_CACHE.ENABLE (
owner => 'SALES',
table_name => 'STORE_SALES'
);
END;
/In diesem Beispiel wird der STORE_SALES-Cache aktiviert.
Weitere Informationen finden Sie unter ENABLE - Prozedur.
Übergeordnetes Thema: Policy-basiertes Caching für externe Tabellen verwenden
Cache für externe Tabelle löschen
Zeigt ein Beispiel zum Löschen des Cache für externe Tabellen.
Führen Sie DBMS_EXT_TABLE_CACHE.DROP_CACHE aus, um einen externen Tabellencache zu löschen. Die Prozedur DBMS_EXT_TABLE_CACHE.DROP_CACHE entfernt den angegebenen externen Tabellencache aus der Datenbank und gibt den mit dem Cache verknüpften Speicherplatz frei.
Beispiel:
BEGIN
DBMS_EXT_TABLE_CACHE.DROP_CACHE (
owner => 'SALES',
table_name => 'STORE_SALES');
END;
/In diesem Beispiel wird der STORE_SALES-Cache aus dem Schema SALES gelöscht.
Wenn Sie einen Cache löschen, werden seine Metadaten aus dem Data Dictionary entfernt, und alle gecachten Daten werden gelöscht.
Weitere Informationen finden Sie unter Prozedur DROP_CACHE.
USER_EXTERNAL_TAB_CACHES ab, um zu prüfen, ob der Cache gelöscht wurde. Beispiel:SELECT external_table_name, cached
FROM user_external_tab_caches;Weitere Informationen finden Sie unter Views DBA_EXTERNAL_TAB_CACHES und USER_EXTERNAL_TAB_CACHES.
Übergeordnetes Thema: Policy-basiertes Caching für externe Tabellen verwenden
Optionale Größenvoreinstellungen für Policy-basierte Caches festlegen
Beschreibt, wie Sie Größenvoreinstellungen für Policy-basierte externe Tabellencaches in Autonomous AI Database festlegen.
Standardmäßig ist der externe Tabellencache für einen Benutzer deaktiviert. Um den externen Tabellencache zu aktivieren und zu erstellen, verwenden Sie die Prozedur DBMS_EXT_TABLE_CACHE.CREATE_CACHE. Der Cache wird in Ihrem Standardschema erstellt und erbt alle für Ihr Schema definierten Speicherplatz-Quota-Grenzwerte. Sie können jedoch auch die Prozedur DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY verwenden, um Speicherplatzkontingente für den externen Tabellencache zu definieren. Sie verwenden die Parameter PROPERTY_NAME und PROPERTY_VALUE der Prozedur DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY, um die Grenzwerte für die Speicherplatz-Quota festzulegen.
Der Parameter PROPERTY_NAME akzeptiert die Werte MAX_CACHE_SIZE und MAX_CACHE_PERCENT. Die Eigenschaft MAX_CACHE_SIZE gibt die gesamte externe Cachegröße in Byte an. Die Eigenschaft MAX_CACHE_PERCENT gibt die gesamte externe Cachegröße als Prozentsatz der Quota des angegebenen Benutzers an.
Beispiele
BEGIN
DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY (
property_name => 'MAX_CACHE_PERCENT',
property_value => 50,
owner => 'SALES');
END;
/
In diesem Beispiel wird die Caching-Voreinstellung für das Schema SALES auf MAX_CACHE_PERCENT gesetzt.
property_value ist 50%, was angibt, dass die Cachespeicher-Quota für das Schema SALES maximal 50% der gesamten für SALES definierten Speicherplatz-Quota beträgt.
BEGIN
DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY (
owner => 'SALES',
property_name => 'MAX_CACHE_SIZE',
property_value => 5368709120);
END;
/In diesem Beispiel wird die Caching-Voreinstellung für das Schema SALES auf MAX_CACHE_SIZE gesetzt.
Die property_value ist 5368709120, was angibt, dass die maximale Cachegröße für das Schema SALES bis zu 5 GB beträgt.
Weitere Informationen finden Sie unter Prozedur SET_USER_PROPERTY und Prozedur CREATE_CACHE.
Verwenden Sie DBMS_EXT_TABLE_CACHE.GET_USER_PROPERTY, um die Eigenschaften der Cachegröße abzurufen.
Beispiel:
SET SERVEROUTPUT ON
DECLARE
max_cache_sz NUMBER,
BEGIN
max_cache_sz := DBMS_EXT_TABLE_CACHE.GET_USER_PROPERTY (
property_name => 'MAX_CACHE_SIZE',
owner => 'SALES');
END;
/Weitere Informationen finden Sie unter Funktion GET_USER_PROPERTY.
Beachten Sie die folgende Prioritätsreihenfolge zum Festlegen der Cachegrößeneigenschaften:
-
Wenn
MAX_CACHE_SIZE,MAX_CACHE_PERCENTund die Speicherplatz-Quota definiert sind, hatMAX_CACHE_PERCENTVorrang vorMAX_CACHE_SIZE. -
Wenn nur
MAX_CACHE_SIZEdefiniert ist undMAX_CACHE_PERCENToder das Speicherplatz-Quota nicht definiert ist, hatMAX_CACHE_SIZEVorrang. -
Wenn nur die Speicherplatz-Quota definiert ist und
MAX_CACHE_SIZEundMAX_CACHE_PERCENTnicht definiert sind, entspricht die Quota für die Cachegröße standardmäßig 10% der gesamten Schema-Quota. -
Wenn
MAX_CACHE_SIZE,MAX_CACHE_PERCENToder die Speicherplatz-Quota nicht definiert ist, wird die Cache-Speicher-Quota standardmäßig aufUNLIMITEDgesetzt.
Um die Nutzung des Cachespeichers zu überwachen, fragen Sie die Spalte
CACHE_CUR_SIZE in den Ansichten ALL_EXTERNAL_TAB_CACHES ab. Weitere Informationen finden Sie unter Views DBA_EXTERNAL_TAB_CACHES und USER_EXTERNAL_TAB_CACHES.
Übergeordnetes Thema: Policy-basiertes Caching für externe Tabellen verwenden
Automatisches Caching für externe Tabelle verwenden
Beschreibt, wie Sie automatisches Caching für externe Tabellen in Autonomous AI Database verwenden.
Wenn Sie das automatische Caching für Ihre Datenbank aktivieren, verwaltet die Datenbank automatisch den gesamten Cache-Lebenszyklus, einschließlich Erstellung, Auffüllung, Aktualisierung und Löschen, ohne dass Ihr Eingreifen erforderlich ist. Oracle verwendet interne Mechanismen, um zu bestimmen, welche externen Tabellen vom Caching profitieren können, wann die Caches aktualisiert werden und wann sie basierend auf Nutzungsmustern und verfügbarem Speicherplatz gelöscht werden sollen. Dieser Ansatz reduziert den Overhead für die Cache-Verwaltung, da die Cache-Nutzung kontinuierlich überwacht wird. Dadurch wird sichergestellt, dass häufig auf externe Tabellendaten zugegriffen wird, die im Cache verfügbar bleiben, um die Antwortzeiten der Abfrage zu verbessern.
Standardmäßig ist das automatische Caching in der Datenbank nicht aktiviert. Um sie zu aktivieren, müssen Sie die Cachegröße mit Prozeduren wie DBMS_CACHE.SET_USER_PROPERTY im Package DBMS_CACHE auf einen Wert ungleich Null setzen. Sie können das automatische Caching entweder für einen bestimmten Benutzer oder als Standardeinstellung für alle Datenbankbenutzer konfigurieren, je nach Ihren Anforderungen.
Wenn das automatische Caching externer Tabellen aktiviert ist, erstellt Oracle externe Tabellencaches, die als AUTO markiert sind, und füllt alle entsprechenden Daten aus einer externen Tabelle in den Cache auf, wenn die Quota dies zulässt. Die AUTO-Caches werden automatisch nach einem regulären Zeitplan aktualisiert. Sie können jedoch auch die Prozeduren DBMS_CACHE.REFRESH oder DBMS_CACHE.CLEAR verwenden, um Ihre Caches zu aktualisieren oder zu löschen.
Oracle verwaltet die AUTO-Caches mit einem Räumungsalgorithmus ähnlich dem LRU (Least Recently Used). Unter Speicherplatzdruck werden Caches, auf die zuletzt zugegriffen wurde, während des Aktualisierungszyklus automatisch gelöscht, um den Speicherplatz freizugeben.
Themen
- Automatisches Caching für externe Tabellen aktivieren
Beschreibt, wie Sie automatische Caching-Eigenschaften konfigurieren. - Externe Tabellencaches aktualisieren
Zeigt ein Beispiel für die Aktualisierung von AUTO-Caches für das angegebene Schema. - Externe Tabellencaches löschen
Zeigt ein Beispiel zum Löschen von AUTO-Caches für das angegebene Schema.
Übergeordnetes Thema: Externen Tabellencache zur Performanceverbesserung für externe Tabellen verwenden
Automatisches Caching für externe Tabellen aktivieren
Beschreibt, wie automatische Caching-Eigenschaften konfiguriert werden.
Standardmäßig ist das automatische Caching deaktiviert. Sie können das automatische Caching für Ihre externen Tabellen entweder global für alle Datenbankbenutzer oder für einen bestimmten Benutzer aktivieren. Nachdem das automatische Caching aktiviert wurde, erstellt die Datenbank automatisch externe Tabellencaches. Alle neu erstellten Caches werden als AUTO markiert. Vorhandene Caches folgen weiterhin den richtlinienbasierten Cache-Management-Einstellungen.
Mit DBMS_CACHE.SET_GLOBAL_PROPERTY oder DBMS_CACHE.SET_USER_PROPERTY legen Sie AUTO-Caching-Eigenschaften fest, einschließlich Eigenschaften, mit denen das automatische Caching global oder für einen bestimmten Benutzer aktiviert wird. Voreinstellungen für das Caching auf Benutzerebene haben Vorrang vor globalen Caching-Voreinstellungen. Verwenden Sie die Parameter PROPERTY_NAME und PROPERTY_VALUE dieser Prozeduren, um Speicherplatzquota-Grenzwerte für externe Tabellencaches festzulegen.
Je nach angegebener Speicherplatz-Quota erstellt Oracle die Caches und versucht, die gesamten externen Tabellendaten in den Cache zu füllen. Der Populationsprozess ist nicht erfolgreich, wenn die Cachegröße nicht ausreicht, um die gesamten Daten der externen Tabelle aufzunehmen.
Um die Nutzung des Cachespeichers zu überwachen, fragen Sie die Spalte
CACHE_CUR_SIZE in den Ansichten ALL_EXTERNAL_TAB_CACHES ab. Weitere Informationen finden Sie unter Views DBA_EXTERNAL_TAB_CACHES und USER_EXTERNAL_TAB_CACHES.
Übergeordnetes Thema: Automatisches Caching für externe Tabelle verwenden
Caches für externe Tabellen werden aktualisiert
Zeigt ein Beispiel zum Aktualisieren von AUTO-Caches für das angegebene Schema an.
-
Neue Caches hinzufügen
-
Löschen Sie alle ungültigen Caches (die Caches, auf die nicht mehr zugegriffen werden kann, werden als ungültig markiert und im nachfolgenden Aktualisierungszyklus gelöscht).
-
Aktualisieren oder füllen Sie vorhandene Caches erneut.
-
Löschen Sie die zuletzt aufgerufenen Caches, wenn der Speicherplatz unter Druck steht.
Alternativ können Sie auch die Prozedur DBMS_CACHE.REFRESH verwenden, um eine On-Demand-Aktualisierung für alle Caches des HR-Benutzers auszuführen.
Übergeordnetes Thema: Automatisches Caching für externe Tabelle verwenden
Externe Tabellencaches löschen
Zeigt ein Beispiel zum Löschen von AUTO-Caches für das angegebene Schema an.
Während jedes Aktualisierungszyklus werden ungültige Caches und die zuletzt aufgerufenen Caches aus der Datenbank gelöscht. Alternativ können Sie die Prozedur DBMS_CACHE.CLEAR verwenden, um alle Caches für einen angegebenen Benutzer zu löschen.
Übergeordnetes Thema: Automatisches Caching für externe Tabelle verwenden
Cacheperformance für externe Tabellen überwachen und diagnostizieren
Autonomous AI Database bietet Ansichten, mit denen Sie den externen Tabellencache überwachen können.
| Anzeigen | Beschreibung |
|---|---|
|
Ansichten DBA_EXTERNAL_TAB_CACHES und USER_EXTERNAL_TAB_CACHES |
Stellt Informationen über alle externen Tabellencaches in der Datenbank oder über die externen Tabellencaches eines Benutzers bereit. |
|
Stellt Informationen zu den Dateien in Cloud Storage bereit, die für den aktuellen Benutzer zugänglich sind und zu gecachten externen Tabellen gehören. |
|
|
Enthält Informationen zu den Dateien im Cloud-Speicher, deren Eigentümer der aktuelle Benutzer ist und die zu zwischengespeicherten externen Tabellen gehören. In dieser Ansicht wird die Spalte |
Diese Views enthalten detaillierte Informationen darüber, wie gecachte Daten für externe Tabellen in der Datenbank gespeichert, aufgerufen und verwaltet werden. Mit diesen Views können Sie die Cache-Performance überwachen, veraltete oder veraltete Daten identifizieren und die Speicherplatzauslastung analysieren, um eine optimale Abfrageeffizienz sicherzustellen. Durch die Überwachung dieser Views können Sie erkennen, wann Caches aktualisiert werden müssen, prüfen, ob die Cachegrößen innerhalb der konfigurierten Grenzwerte liegen, und Performanceengpässe im Zusammenhang mit dem externen Datenzugriff diagnostizieren.
Beispiele:
SELECT table_name, cached, stale, last_refreshed, last_accessed
FROM all_external_tab_cache_locations
ORDER BY stale DESC, usage_count DESC;Die folgende Abfrage enthält Informationen zu Cache-Bestand und Speicherplatzbelegung:
SELECT external_table_name, cache_cur_size, cache_max_size, disabled
FROM user_external_tab_caches;Übergeordnetes Thema: Externen Tabellencache zur Performanceverbesserung für externe Tabellen verwenden
Anwendungsfälle für das Caching externer Tabellen
Beschreibt häufige Szenarios, in denen externes Tabellen-Caching von Vorteil ist.
| Anwendungsfall | Was zu cachen | Kostenauswirkung | Performanceauswirkung | Notizen |
|---|---|---|---|---|
|
Interaktives BI oder Dashboards über externe Tabellen |
Häufig abgefragte externe Tabellen oder Partitionen, die Dashboards füttern |
Eliminiert wiederholte cloudübergreifende oder regionale Lesevorgänge |
Hält heiße Daten lokal, um schnellere, konsistente Reaktionszeiten zu erzielen und Kaltstarts zu vermeiden |
Dies ist das häufigste Szenario |
|
Multicloud-Analysen (Beispiel: Autonomous AI Database auf OCI, die S3 oder GCS oder Azure liest) |
Zugriff auf Hot-Datasets aus Nicht-OCI-Objektspeichern |
Reduziert Cloud-übergreifenden Egress-Traffic und reduziert die Gebühren für Provideranforderungen |
Entfernt Remote-I/O und Netzwerklatenz |
Kosten und Latenz gemeinsam angeben |
|
Regionsübergreifender Zugriff (gleiche Cloud) |
Externe Daten in einer anderen Region |
Verhindert regionsübergreifenden Egress bei wiederholten Scans |
Reduziert die Latenz durch Lokalisierung von Lesevorgängen |
Dieselbe Begründung wie bei Multicloud. |
|
Materialized View über externe Daten aktualisieren |
Externe Quelltabellen für Materialized Views |
Reduziert wiederholten Egress für geplante Aktualisierungen |
Stabilisiert und beschleunigt die Materialized View-Aktualisierung; verkürzt die Remote Scan-Zeit |
Ideal für nahe an Echtzeitaggregate |
|
Letzte Dateien Pipelines (Landing Zone) |
Letzte |
Neueste Daten sind immer heiß |
||
|
Kleine, aber häufig verknüpfte Lookup- oder Referenzdaten |
Kleine externe Tabellen, die in Joins verwendet werden |
Verhindert Überlastung aufgrund vieler kleiner Anforderungen |
Behält Lookup-Daten für Joins lokal |
Kleine Dictionary-Daten sind immer auf dem neuesten Stand und müssen kein komplexes ETL verwalten |
|
Data Science und Feature Engineering |
Wiederverwendung von Schulungen oder Featuresets in externen Tabellen |
Weniger Remote-Lesevorgänge während iterativer Arbeit |
Schnellere wiederholte Scans während des Experiments |
Funktioniert gut mit Notebook-gesteuerten Loops |
|
Bursty- oder gedrosselter Objektspeicher |
Externe Tabelle mit hohem Datenverkehr |
Weniger Wiederholungen bei vielen Benutzern |
Schirmt Abfragen von Speicherdrosselung und variablem Durchsatz ab |
Verbessert die SLA-Vorhersagbarkeit |
|
Eisberg oder große abgetrennte Seen |
Häufig gelesene Hot-Partitionen oder Snapshots |
Vermeidet wiederholte Lesevorgänge derselben Parkettstreifen |
Lokalisiert Datenseiten für Hot-Partitionen; Steadier-Abfragezeiten |
Link zur Iceberg-Einrichtungsseite |
|
Ad-hoc-Exploration in großem Maßstab |
Vorläufige externe Tabellen mit wiederholtem Zugriff |
Verhindert Rückzahlung von Egress während der Erkundung |
Veranlasst Nachfassabfragen nach dem ersten Durchlauf |
Gut auf Rampen, ohne Pipelines zu kopieren. |
Übergeordnetes Thema: Externen Tabellencache zur Performanceverbesserung für externe Tabellen verwenden
