クラウド表を使用したロギング情報および診断情報の格納

表データがOracle Managed Cloud Storageに存在し、表データがデータベース記憶域を消費しないクラウド表を作成できます。

クラウド表について

クラウド表は、データベース内表の補足的な代替として作成できます。

すべてのクラウド表データは、Oracle Managed Object Storageに格納されます。Oracle Managed Object Storageは、Autonomous AI Databaseが作成および管理するデータベースの外部ストレージです。

クラウド表を使用して、使用頻度の低いアプリケーション・ロギング・データや診断情報を格納したり、他のデータを格納したりできます。Autonomous AI Databaseで実行されない一部の既存のアプリケーションでは、このような情報をローカル・ファイル・システム上のファイルに格納できます(たとえば、UTL_FILE APIを使用)。このようなロギングメカニズムおよび関連ファイルは、アプリケーションエラーを診断して解決する必要がある場合に非常に役立ちます。ただし、データベース表への情報の格納では、使用頻度の低いデータに大量のデータベース記憶域を使用できます。クラウド表を使用すると、永続データは、データベース・ストレージを使用せずにOracle Managed Object Storageに保存されます。

ノート

ノート: CLOUD_TABLE_COMMIT_THRESHOLDパラメータは、すべてのクラウド表に適用され、ALTER SESSION権限を持つすべてのユーザーが設定できます。したがって、クラウド表は、コミットされた変更が永続的で、同時リーダーからすぐに参照できる必要があるセキュリティ・クリティカルなデータには適していません。このため、クラウド表は監査ログ表などのユース・ケースに適さない場合があります。

クラウド表のSELECTおよびDMLの制限

クラウド表は、いくつかの制限がある通常のデータベース表と同様に機能します。SELECT文とDML文、データ操作文を使用できますが、次の例外があります。

  • MERGE文はサポートされていません。

  • LOB列は、10MBのデータに制限されます。

  • DMLの同時実行性制御は異なるため、次のようになります。

    • LOCK TABLEは、データベース表の場合と同様に同時DMLを防止できません。

    • INSERTは表のロックを取得しないため、INSERTは同時DML操作によってブロックされることはありません。

    • UPDATEおよびDELETE操作はどちらも、クラウド表に対する排他ロックを取得します。したがって、UPDATEまたはDELETEトランザクションは、クラウド表に対する同時UPDATEまたはDELETE操作をブロックします。

  • NOT NULL制約のみが適用されます。

  • DMLは、読取り/書込み自律AIデータベースでは、他の表と同様に許可されます。また、クラウド表では、リフレッシュ可能クローンでのDML操作も許可されます。

クラウド表では、次のものはサポートされません。

  • 索引

  • 非表示の列

  • 仮想カラム

  • DMLのトリガー

  • 996列以上

  • ブール・データ型の列

ライフサイクル管理操作とクラウド表

クラウド表データは、Oracle Managed Object Storageに格納されます。つまり、自律型AIデータベースでの特定の操作では、次のようにクラウド表がデータベース内表とは異なって処理されます。

  • クラウド表データは、Autonomous AI Databaseインスタンスのバックアップおよびリカバリから除外されます(データはバックアップされず、クラウド表データをリストアできません)。

  • クラウド表データは、Oracle管理オブジェクト・ストレージを介して保護されます。

  • 自律型AIデータベース・インスタンスの状態に影響するライフサイクル管理操作は、クラウド表に格納されているデータには影響しません。

オブジェクト・ストレージのクラウド表ネーミングは、そのOCIDに基づいて、Autonomous AI Databaseインスタンスごとに一意に定義されます。つまり、既存のデータベースの新規OCIDを変更または導入する操作は、クラウド表に影響します。次に、クラウド表データに対するライフサイクル操作の影響を示します。

ライフサイクル処理 クラウド表データ可用性
同じリージョン・データベース・クローン クラウド表はクラウド表データなしでクローニングされます。
クロス・リージョン・データベース・クローン クラウド表はクラウド表データなしでクローニングされます。
同じリージョン(ローカル)のAutonomous Data Guardスタンバイ クラウド表およびクラウド表データにアクセスできます
クロスリージョンAutonomous Data Guardスタンバイ クラウド表は、クラウド表データなしでスタンバイで使用できます
同じリージョン(ローカル)のバックアップベースのディザスタ・リカバリ・ピア クラウド表およびクラウド表データにアクセスできます
クロス・リージョン・バックアップベースのディザスタ・リカバリ・ピア クラウド表は、クラウド表データなしでスタンバイで使用できます
自律型AIデータベース・インスタンスのSCN/タイムスタンプに影響するライフサイクル管理操作:
  • 長期のバックアップ
  • データベースのリストア(ポイント・イン・タイム・リストア)
  • バックアップからのクローニング
クラウド表は引き続き更新され、クラウド表データの古い状態は保持またはリストアされません。つまり、現在のクラウド表データのみが使用可能になります。
ライフサイクル管理の操作。次のものが含まれます。
  • リソース割当ての管理
  • 移動
  • 縮小
  • 名前変更
  • モード: 読み取り専用/書き込み可能
  • ワークロード・タイプの変更(レイクハウスからトランザクション処理など)
クラウド表またはクラウド表データへの影響なし

クラウド表によるバッファリング

デフォルトでは、DMLのコミット時にクラウド表に対するDML変更がオブジェクト・ストレージにエクスポートされます。ただし、DMLが小規模で頻繁にコミットされるトランザクションとして構造化されている場合、これはうまく機能しない可能性があります。このシナリオのパフォーマンスを向上させるには、CLOUD_TABLE_COMMIT_THRESHOLDパラメータを設定して、セッション内のクラウド表DML変更のバッファリングを有効にします。

CLOUD_TABLE_COMMIT_THRESHOLDパラメータが0以外の値に設定されている場合、値は変更数のしきい値として処理され、変更数が指定されたしきい値に達するまでクラウド表の変更がバッファされます。しきい値に達すると、バッファ済の変更がオブジェクト・ストレージにエクスポートされます。CLOUD_TABLE_COMMIT_THRESHOLDに達していなくても、セッションが正常に終了すると、バッファされた変更もエクスポートされます。バッファ済の変更がエクスポートされる前に、同時セッションに変更が表示されません。予期しないプロセスの有効期限が関係するまれなケースでは、バッファされた変更はエクスポートされず、変更は永続的ではありません(つまり、バッファされた変更はオブジェクト・ストアにエクスポートされません)。

詳細は、CLOUD_TABLE_COMMIT_THRESHOLDを参照してください。

クラウド表の作成

自律型AIデータベースにクラウド表を作成するステップを示します。

クラウド表を作成するには:

  1. CREATE_CLOUD_TABLEプロシージャを実行します。

    たとえば:

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

    詳細は、CREATE_CLOUD_TABLEプロシージャを参照してください。

  2. クラウド表にデータを挿入します。

    INSERT INTO cloud_table_test VALUES (1, 'xyz');

    CLOUD_TABLE_COMMIT_THRESHOLD初期化パラメータを使用して、クラウド表のバッファリングを有効にできます。詳細は、CLOUD_TABLE_COMMIT_THRESHOLDを参照してください。

  3. クラウド表からデータを選択します。

    SELECT * FROM cloud_table_test;
    I          STR1
    
    ---------- --------------------------------
    1          xyz

クラウド表を削除する場合は、DROP TABLEを使用します。

たとえば:

DROP TABLE CLOUD_TABLE_TEST;

クラウド表はごみ箱をサポートしていません。

詳細は、クラウド表のノートを参照してください。

クラウド表のノート

クラウド表を使用するためのノートを提供します。

クラウド表の使用に関するノートを次に示します。

  • クラウド表にSELECTINSERTおよびUPDATE権限を付与できます。クラウド表に他の権限を付与することはできません。

    詳細は、「権限とロール認可の構成」を参照してください。

  • クラウド表の制約は、RELY DISABLE NOVALIDATEモードの制約に制限されます。つまり、制約は適用されません。唯一の例外は、NOT NULL制約の場合です。

    クラウド表では、デフォルト・モード(ENABLE VALIDATE)を含むすべてのNOT NULL制約モードがサポートされています。PRIMARY KEYUNIQUEFOREIGN KEYおよびNOT NULL制約がサポートされています。CHECK制約はサポートされていません。

    制約は、COLUMN_LISTの一部としてインラインで宣言できます。

    たとえば:

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;
/

クラウド表のその他の制限については、クラウド表のノートを参照してください。

  • DBMS_CLOUDパッケージは、実行者権限パッケージです。DBMS_CLOUD.CREATE_CLOUD_TABLEプロシージャでは、実行者のスキーマに表のみを作成できます。

    詳細は、「実行者権限および定義者権限句」を参照してください。

  • DBMS_CLOUD.CREATE_CLOUD_TABLEプロシージャ・コールのcolumn_listパラメータには、DEFAULT句を含めることができます。この句は、CREATE TABLEDEFAULT句のように機能します。詳細は、CREATE TABLEを参照してください。

    たとえば:

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

    その後、デフォルト値で挿入できます。たとえば:

    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</code></pre>

  • CLOUD_TABLE_COMMIT_THRESHOLD初期化パラメータを使用して、クラウド表のバッファリングを有効にできます。詳細は、CLOUD_TABLE_COMMIT_THRESHOLDを参照してください。