Logging- und Diagnoseinformationen mit Cloud-Tabellen speichern

Sie können Cloud-Tabellen erstellen, in denen Tabellendaten im von Oracle verwalteten Cloud-Speicher gespeichert sind und die Tabellendaten keinen Datenbankspeicher belegen.

Cloud-Tabellen

Sie können Cloud-Tabellen als ergänzende Alternative zu datenbankinternen Tabellen erstellen.

Alle Cloud-Tabellendaten werden im von Oracle verwalteten Object Storage gespeichert. Von Oracle verwalteter Object Storage ist ein externer Speicher außerhalb der Datenbank, den Autonomous AI Database erstellt und verwaltet.

Mit Cloud-Tabellen können Sie selten verwendete Anwendungsloggingdaten, Diagnoseinformationen oder andere Daten speichern. In einigen vorhandenen Anwendungen, die nicht auf einer autonomen KI-Datenbank ausgeführt werden, können Sie diese Art von Informationen in Dateien in einem lokalen Dateisystem speichern (z.B. mit UTL_FILE-APIs). Solche Protokollierungsmechanismen und die zugehörigen Dateien können sehr hilfreich sein, wenn Sie Anwendungsfehler diagnostizieren und beheben müssen. Das Speichern von Informationen in Datenbanktabellen kann jedoch große Mengen an Datenbankspeicher für Daten verwenden, die selten verwendet werden. Mithilfe von Cloud-Tabellen werden die persistenten Daten im von Oracle verwalteten Object Storage gespeichert, ohne dass der Datenbankspeicher belegt wird.

Hinweis

Der Parameter CLOUD_TABLE_COMMIT_THRESHOLD gilt für alle Cloud-Tabellen und kann von jedem Benutzer mit der Berechtigung ALTER SESSION festgelegt werden. Daher sind Cloud-Tabellen nicht für sicherheitskritische Daten geeignet, bei denen festgeschriebene Änderungen dauerhaft sein müssen und für gleichzeitige Lesevorgänge sofort sichtbar sein müssen. Aus diesem Grund sind Cloud-Tabellen möglicherweise nicht für Anwendungsfälle wie Auditlogtabellen geeignet.

SELECT- und DML-Einschränkungen für Cloud-Tabellen

Cloud-Tabellen funktionieren wie normale Datenbanktabellen mit einigen Einschränkungen. Sie können SELECT- und DML-Anweisungen (Data Manipulation Statement) mit folgenden Ausnahmen verwenden:

  • MERGE-Anweisungen werden nicht unterstützt.
  • LOB-Spalten sind auf 10 MB Daten begrenzt.
  • Die Kontrolle des gleichzeitigen DML-Zugriffs unterscheidet sich. Daher gilt Folgendes:
    • LOCK TABLE verhindert möglicherweise nicht die gleichzeitige DML wie bei einer Datenbanktabelle.
    • INSERT fordert keine Sperre für die Tabelle an. Daher wird INSERT nie von gleichzeitigen DML-Vorgängen blockiert.
    • Die Vorgänge UPDATE und DELETE fordern beide eine exklusive Sperre für eine Cloud-Tabelle an. Daher blockieren UPDATE- oder DELETE-Transaktionen nebenläufige UPDATE- oder DELETE-Vorgänge in einer Cloud-Tabelle.
  • Nur NOT NULL-Constraints werden durchgesetzt.
  • DML ist in einer autonomen KI-Datenbank mit Lese-/Schreibzugriff wie für jede andere Tabelle zulässig. Cloud-Tabellen ermöglichen auch DML-Vorgänge in einem aktualisierbaren Klon.

Cloud-Tabellen unterstützen Folgendes nicht:

  • Indizes
  • Unsichtbare Spalte
  • Virtuelle Säulen
  • DML-Trigger
  • Mehr als 996 Spalten
  • Spalten des Datentyps "Boolesch"

Lifecycle Management-Vorgänge und Cloud-Tabellen

Cloud-Tabellendaten werden im von Oracle verwalteten Object Storage gespeichert. Das bedeutet, dass bestimmte Vorgänge in der autonomen KI-Datenbank Cloud-Tabellen anders behandeln als datenbankinterne Tabellen, wie folgt:

  • Cloud-Tabellendaten werden aus dem Backup und Recovery einer autonomen KI-Datenbankinstanz ausgeschlossen (die Daten werden nicht gesichert, und Sie können Cloud-Tabellendaten nicht wiederherstellen).

  • Cloud-Tabellendaten werden über von Oracle verwalteten Object Storage geschützt.

  • Die Lebenszyklusmanagementvorgänge, die sich auf den Status einer autonomen KI-Datenbankinstanz auswirken, haben keine Auswirkungen auf die in Cloud-Tabellen gespeicherten Daten.

Die Benennung von Cloud-Tabellen in Object Storage ist für jede Instanz der autonomen KI-Datenbank basierend auf ihrer OCID eindeutig definiert. Das bedeutet, dass jeder Vorgang, der eine neue OCID für eine vorhandene Datenbank ändert oder einführt, Auswirkungen auf Cloud-Tabellen hat. Im Folgenden werden die Auswirkungen von Lebenszyklusvorgängen auf Cloud-Tabellendaten dargestellt.

Lebenszyklusvorgang Cloud-Tabellendatenverfügbarkeit
Gleicher Regionsdatenbankklon Cloud-Tabelle ohne Cloud-Tabellendaten geklont
Regionsübergreifender Datenbankklon Cloud-Tabelle ohne Cloud-Tabellendaten geklont
Gleiche Region (lokal) Autonomous Data Guard-Standbydatenbank Auf Cloud-Tabellen- und Cloud-Tabellendaten kann zugegriffen werden
Regionsübergreifende Autonomous Data Guard-Standbydatenbank Cloud-Tabelle ist in der Standbydatenbank ohne die Cloud-Tabellendaten verfügbar
Gleiche Region (lokal) Backup-basierter Disaster Recovery-Peer Auf Cloud-Tabellen- und Cloud-Tabellendaten kann zugegriffen werden
Regionsübergreifender Backup-basierter Disaster Recovery-Peer Cloud-Tabelle ist in der Standbydatenbank ohne Cloud-Tabellendaten verfügbar
Lebenszyklusmanagementvorgänge, die sich auf die SCN/den Zeitstempel einer autonomen KI-Datenbankinstanz auswirken, einschließlich:
  • Langfristiges Sicherung
  • Datenbank wiederherstellen (Point-in-Time-Wiederherstellung)
  • Aus Backup klonen

Die Cloud-Tabelle wird weiterhin aktualisiert, und der alte Status der Cloud-Tabellendaten wird nicht beibehalten oder wiederhergestellt. Das bedeutet, dass nur die aktuellen Cloud-Tabellendaten verfügbar sind.

Lebenszyklus-Managementvorgänge, einschließlich:
  • Ressourcenzuweisung verwalten
  • Verschieben
  • Verkleinern
  • Umbenennen
  • Modus: Schreibgeschützt/Schreibgeschützt
  • Workload-Typ ändern: Beispiel: von Lakehouse zur Transaktionsverarbeitung
Keine Auswirkung auf Cloud-Tabellen oder Cloud-Tabellendaten

Pufferung mit Cloud-Tabellen

Standardmäßig werden DML-Änderungen an Cloud-Tabellen in Object Storage exportiert, wenn die DML festgeschrieben wird. Dies kann jedoch nicht gut funktionieren, wenn DMLs als kleine, häufig festgeschriebene Transaktionen strukturiert sind. Um die Performance in diesem Szenario zu verbessern, legen Sie den Parameter CLOUD_TABLE_COMMIT_THRESHOLD fest, um die Pufferung von DML-Änderungen der Cloud-Tabelle innerhalb einer Session zu aktivieren.

Wenn der Parameter CLOUD_TABLE_COMMIT_THRESHOLD auf einen Wert ungleich Null gesetzt ist, behandelt das System den Wert als Schwellenwert für die Änderungsanzahl, und Cloud-Tabellenänderungen werden gepuffert, bis die Anzahl der Änderungen den angegebenen Schwellenwert erreicht. Wenn der Schwellenwert erreicht ist, werden die gepufferten Änderungen in Object Storage exportiert. Gepufferte Änderungen werden auch exportiert, wenn die Session normal beendet wird, selbst wenn CLOUD_TABLE_COMMIT_THRESHOLD nicht erreicht wurde. Bevor gepufferte Änderungen exportiert werden, sehen nebenläufige Sessions die Änderungen nicht. In seltenen Fällen mit unerwartetem Ablauf des Prozesses werden die gepufferten Änderungen möglicherweise nie exportiert, und die Änderungen sind nicht dauerhaft (d.h. die gepufferten Änderungen werden nicht in den Objektspeicher exportiert).

Weitere Informationen finden Sie unter CLOUD_TABLE_COMMIT_THRESHOLD.

Cloud-Tabellen erstellen

Zeigt die Schritte zum Erstellen einer Cloud-Tabelle in einer autonomen KI-Datenbank an.

So erstellen Sie eine Cloud-Tabelle:

  1. Führen Sie die Prozedur CREATE_CLOUD_TABLE aus.

    Beispiel:

    BEGIN
      DBMS_CLOUD.CREATE_CLOUD_TABLE(
       table_name  => 'CLOUD_TABLE_TEST',
       column_list => 'I INTEGER, STR1 VARCHAR2(32)' );
    END;
    /

    Weitere Informationen finden Sie unter Prozedur CREATE_CLOUD_TABLE.

  2. Daten in die Cloud-Tabelle einfügen.
    INSERT INTO cloud_table_test VALUES (1, 'xyz');

    Mit dem Initialisierungsparameter CLOUD_TABLE_COMMIT_THRESHOLD können Sie die Pufferung für Cloud-Tabellen aktivieren. Weitere Informationen finden Sie unter CLOUD_TABLE_COMMIT_THRESHOLD.

  3. Daten aus einer Cloud-Tabelle auswählen.
    SELECT * FROM cloud_table_test;
    I          STR1
    ---------- --------------------------------
    1          xyz                            

Verwenden Sie DROP TABLE, wenn Sie eine Cloud-Tabelle löschen möchten.

Beispiel:

DROP TABLE CLOUD_TABLE_TEST;

Cloud-Tabellen unterstützen den Papierkorb nicht.

Weitere Informationen finden Sie unter Cloud-Tabellenhinweise.

Cloud-Tabellenhinweise

Enthält Hinweise zur Verwendung von Cloud-Tabellen.

Im Folgenden finden Sie Hinweise zur Verwendung von Cloud-Tabellen:

  • Sie können SELECT-, INSERT- und UPDATE-Berechtigungen für eine Cloud-Tabelle erteilen. Einer Cloud-Tabelle können keine anderen Berechtigungen erteilt werden.

    Weitere Informationen finden Sie unter Konfigurieren von Berechtigungen und Rollenautorisierung.

  • Cloud-Tabellen-Constraints sind im Modus RELY DISABLE NOVALIDATE auf Constraints beschränkt. Das bedeutet, dass das Constraint nicht durchgesetzt wird. Die einzige Ausnahme ist für NOT NULL-Constraints.

    Cloud-Tabellen unterstützen alle Constraint-Modi NOT NULL, einschließlich des Standardmodus (ENABLE VALIDATE). Constraints PRIMARY KEY, UNIQUE, FOREIGN KEY und NOT NULL werden unterstützt. Constraints CHECK werden nicht unterstützt.

    Sie können Constraints inline als Teil von COLUMN_LIST deklarieren.

    Beispiel:

    BEGIN
      DBMS_CLOUD.CREATE_CLOUD_TABLE(
            table_name  => 'CLOUD_TAB_WITH_CONSTRAINTS',
            column_list => 'PK INTEGER,
                DATE_ID INT REFERENCES DATE_DIM(DATE_ID) RELY DISABLE NOVALIDATE,
                VAL NUMBER NOT NULL,
                CONSTRAINT CLOUD_TAB_PK PRIMARY KEY(PK) RELY DISABLE NOVALIDATE');
    END;
    /

    Weitere Einschränkungen für Cloud-Tabellen finden Sie unter Cloud-Tabellenhinweise.

  • Das Package DBMS_CLOUD ist ein Rechtepaket des ausführenden Benutzers. Mit der Prozedur DBMS_CLOUD.CREATE_CLOUD_TABLE können Sie nur eine Tabelle im Schema des ausführenden Benutzers erstellen.

    Weitere Informationen finden Sie unter Invoker's Rights and Definer's Rights Clause.

  • Der Parameter column_list in einem DBMS_CLOUD.CREATE_CLOUD_TABLE-Prozeduraufruf kann die DEFAULT-Klausel enthalten, die wie die DEFAULT-Klausel in CREATE TABLE funktioniert. Weitere Informationen finden Sie unter CREATE TABLE.

    Beispiel:

    BEGIN
      DBMS_CLOUD.CREATE_CLOUD_TABLE(
       table_name  => 'CLOUD_TABLE_TEST_DEFAULT',
       column_list => 'I INTEGER, STR2 VARCHAR2(32) DEFAULT ''ABC''');
    END;
    /

    Anschließend können Sie mit Standardwerten einfügen. Beispiel:

    INSERT INTO cloud_table_test_default (i) VALUES (1); 
    1 row created. 
    INSERT INTO cloud_table_test_default VALUES (2, default);
    1 row created.
    INSERT INTO cloud_table_test_default VALUES (3, null);
    1 row created.
    INSERT INTO cloud_table_test_default VALUES (4, 'xyz');
    1 row created.
    COMMIT;
    Commit complete.
    SELECT * FROM cloud_table_test_default ORDER BY i;
    
    I STR2 
    - ---- 
    1 ABC  
    2 ABC  
    3 null 
    4 xyz
  • Mit dem Initialisierungsparameter CLOUD_TABLE_COMMIT_THRESHOLD können Sie die Pufferung für Cloud-Tabellen aktivieren. Weitere Informationen finden Sie unter CLOUD_TABLE_COMMIT_THRESHOLD.