Oracle Cloud Infrastructureドキュメント

レイク・キャッシュを使用した外部表およびマウント済カタログ表のパフォーマンスの向上

Oracle Autonomous AI Databaseのレイク・キャッシュを使用すると、データベース内の外部表およびマウントされたカタログを介して公開される表から、頻繁にアクセスされるデータをキャッシュできます。

ノート

ノート:レイク・キャッシュは、Oracle AI Database 26aiでのみサポートされています。

Autonomous AI Databaseのレイク・キャッシュについて

レイク・キャッシュは、外部表またはマウントされたカタログを介して公開された表のデータを格納する、自律型AIデータベース内のストレージ領域です。

外部データはデータベースによって管理されませんが、外部表またはDBMS_CATALOGでマウントされたカタログによって公開される表を介して問い合せることができます。マウントされたカタログ表は、[schema].object@catalog_nameまたはobject@catalog_name (DEFAULT_SCHEMAがカタログに対して構成されている場合)を使用して問い合せることができます。これらのソース表に対する問合せは、外部ソースからデータをフェッチする必要があるため、データベース表に対する問合せより低速です。レイク・キャッシュを使用すると、頻繁にアクセスされるソース・データをローカルに格納できます。このデータ・キャッシュは、DBMS_CATALOGによって提供されるメタデータ・キャッシュとは異なります。

レイク・キャッシュを使用すると、アクセス頻度の高いソース・データをローカルに格納できます。キャッシュを使用すると、外部表またはマウントされたカタログ表に対する問合せで、Autonomous AI Database内から直接データを取得できるため、大幅に高速化されます。このキャッシュ・メカニズムはアプリケーションに対して完全に透過的であるため、高速アクセスを利用するために既存のSQL文やワークフローを変更する必要はありません。

パーティション表と非パーティション外部表、およびParquet表、ORC表、AVRO表、CSV表およびIceberg表でバックアップされるデータを含む、マウントされたカタログを介して公開される適格な表に対して、レイク・キャッシュを作成できます。キャッシュを作成またはリフレッシュするときに、キャッシュ・アクションを実行するリソース・グループを指定することで、キャッシュ操作で使用されるリソースをオプションで制御できます。ソース表全体をキャッシュしない場合は、列のサブセットのみをキャッシュするように選択することもできます。

レイク・キャッシュを使用する利点の一部を次に示します。

  • 分析のパフォーマンスの向上: クエリーは、頻繁にアクセスされる外部データに対して数倍高速です。ダッシュボード、レポート、および同じデータに定期的にアクセスする分析ツールに最適です。

  • 100%透過的: キャッシュ・メカニズムは完全に透過的です。アプリケーションでは、問合せ、ダッシュボードまたはアプリケーションを変更することなく、高速化の恩恵を受けることができます。

  • クラウド・コストの削減: マルチクラウド・アプリケーションでは、キャッシュにより、リモート・ストレージから外部データを繰り返し取得する必要性が減り、リージョンやクラウド間のデータへのアクセスに関連するデータ・エグレス料金が削減されます。

  • ファイングレインでフレキシブルなキャッシュ制御: すべてのファイル、ファイルの割合、または最近更新されたデータのみをキャッシュできます。レイク・キャッシュのキャッシュ・データ、キャッシュ・サイズおよびストレージ制限を制御できます。また、すべての列をキャッシュするか、外部表の列のサブセットのみをキャッシュするかを選択して、列レベルでファイングレイン選択を適用することもできます。

データベース内のレイク・キャッシュは、自動またはポリシーベースの設定を介して管理できます。ポリシーベースのキャッシュ管理では、キャッシュからファイルを移入、リフレッシュおよびリタイアする単純なポリシーを定義して、キャッシュの内容とメンテナンスを正確に制御できます。

詳細は、外部データ問合せを参照してください。

レイク・キャッシュを使用したクイック・スタート

レイク・キャッシュの作成および移入の開始に役立つ例を提供します。

SALESスキーマのポリシーベースのレイク・キャッシュを作成します。

キャッシュを作成すると、最初は空になり、移入が有効になります。キャッシュ・サイズは、割り当てられた制限に達するまで、スキーマに定義された領域割当て制限に応じて、ファイルを追加するたびに増加します。

DBMS_EXT_TABLE_CACHE.CREATE_CACHEを使用して、スキーマのレイク・キャッシュを作成します。次に例を示します。

BEGIN
    DBMS_EXT_TABLE_CACHE.CREATE_CACHE (
      owner          => 'SALES',
      table_name     => 'STORE_SALES',
      partition_type => 'PATH');
END;
/

これにより、SALESスキーマにSTORE_SALES表のキャッシュが作成されます。STORE_SALESは、オブジェクト・ストアに格納されているデータを指す外部表です。

ownerパラメータでは、スキーマ名を指定します。この例では、SALESユーザーのレイク・キャッシュを作成します。

partition_typeは、キャッシュの分割方法を制御します。'PATH'を使用すると、キャッシュは各ソース・ファイルのフォルダ・パスによってパーティション化されます。FILE$PATHは、そのフォルダ・パス(ファイル名の前のすべて)を格納する非表示の列です。

たとえば、ファイルが.../n/<ns>/b/<bucket>/o/sales/2024/09/data 1.parquetの場合、FILE$PATH = 'sales/2024/09/' (フォルダ)になります。

レイク・キャッシュを作成する場合、オプションで、すべての列をキャッシュするのではなく、外部表の列のサブセットのみをキャッシュするように選択できます。これにより、アプリケーションに対して問合せ動作を透過的に保ちながら、キャッシュ・サイズを小さくし、未使用データのキャッシュを回避できます。次に例を示します。

BEGIN
  DBMS_EXT_TABLE_CACHE.CREATE_CACHE(
    owner          => 'SALES',
    table_name     => 'EMP_XT',
    partition_type => 'PATH',
    columns        => '["ENAME","MGR","DEPTNO"]');
END;
/

partition_typeパラメータは、キャッシュの分割方法を制御します。PATHを使用すると、キャッシュは各ソース・ファイルのフォルダ・パスによってパーティション化されます。FILE$PATHは、そのフォルダ・パス(ファイル名の前のすべて)を格納する非表示の列です。パス別にパーティション化すると、たとえば日付ごとに外部データがフォルダ別に編成されている場合に、管理性とリフレッシュの動作が向上します。

たとえば、ファイルが…/n/<ns>/b/<bucket>/o/sales/2024/09/data1.parquet then FILE$PATH = 'sales/2024/09/'(フォルダ)の場合です。

columnsパラメータを使用すると、キャッシュの作成時にファイングレイン列を選択できます。この例では、キャッシュに格納できるのはENAME、MGRおよびDEPTNO列のみです。これにより、キャッシュ・サイズが小さくなり、未使用データのキャッシュを回避できます。これらの列のみを参照する問合せは、移入後にキャッシュから満たすことができます。他の列を必要とする問合せは、外部ソースから読み取ることができます。

レイク・キャッシュを作成すると、そのメタデータはデータ・ディクショナリに格納されます。ただし、キャッシュは最初は空であり、キャッシュが移入されるまで、キャッシュ・データは格納されません(たとえば、DBMS_EXT_TABLE_CACHE.ADD_TABLEを実行)。

レイク・キャッシュを初めて作成する場合、そのメタデータはデータ・ディクショナリに格納されます。ただし、キャッシュ・データには領域は割り当てられません。USER_EXTERNAL_TAB_CACHESビューを問い合せて、キャッシュの作成を確認できます。

次に例を示します。

SELECT external_table_name, cached, disabled
  FROM user_external_tab_caches;

レイク・キャッシュを検証するには、DBMS_EXT_TABLE_CACHE.VALIDATEプロシージャを使用します。参照先の外部表がデータベースに見つからない場合は、エラーが報告されます。次に例を示します。

BEGIN
  DBMS_EXT_TABLE_CACHE.VALIDATE (
    owner         => 'SALES',
    table_name    => 'STORE_SALES',
    raise_errors  => TRUE);
END;
/

DBMS_EXT_TABLE_CACHE.ADD_TABLEを実行して、表全体をキャッシュに移入します。次に例を示します。

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE (
    owner         => 'SALES',
    table_name    => 'STORE_SALES');
END;
/

この例では、STORE_SALES表をキャッシュに移入しようとします。

次の例では、前の例で作成したEMP_XTのレイク・キャッシュを移入します(ENAME、MGRおよびDEPTNOのみがキャッシュ適格列として選択されています)。移入後は、適格な列のみを参照する問合せをローカル・キャッシュから処理できます。

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE (
    owner         => 'SALES',
    table_name    => 'EMP_XT');
END;
/

クイック・スタート: マウントされたカタログ表をキャッシュします。

DBMS_CATALOGを使用してカタログをマウントした後、[schema].table@catalog_nameを使用して、またはカタログのDEFAULT_SCHEMAプロパティが構成されているときにtable@catalog_nameを使用して、マウントされたカタログ表を問い合せることができます。同じレイク・キャッシュのライフサイクルが適用されます。キャッシュの作成、検証、移入、およびUSER_EXTERNAL_TAB_CACHESでの検証です。

SELECT * FROM "SH"."SALES"@catalogname;
SELECT * FROM SALES@catalogname;

自動管理レイク・キャッシュの作成

デフォルトでは、自動キャッシュは無効になっており、自動キャッシュを有効にすると AUTOキャッシュが自動的に作成されます。

DBMS_CACHE.SET_USER_PROPERTYを実行して、HRスキーマに適格なソース表の自動キャッシュを有効にします。次に例を示します。

BEGIN
 DBMS_CACHE.SET_USER_PROPERTY (
 property_name      => 'max_cache_size',
 property_value_num => 10737418240);
END;
/

この例では、HRスキーマの自動キャッシュを有効にし、MAX_CACHE_SIZEパラメータを10737418240バイトに設定して、HRスキーマ内の適格なソース表に対する最大キャッシュ割当てを10 GBに指定します。また、適格なソース表に必要なレイク・キャッシュが作成され、移入されます。

すべてのデータベース・ユーザーの自動キャッシュを有効にする例:

BEGIN
 DBMS_CACHE.SET_GLOBAL_PROPERTY (
 property_name       => 'max_cache_percent',
 property_value_num  => 20);
END;
/

MAX_CACHE_PERCENTグローバル・プロパティを使用して、すべてのユーザーのデフォルトのキャッシュ制限を設定します。MAX_CACHE_PERCENTを20に設定すると、レイク・キャッシュの自動割当てでは、各ユーザーに割り当てられた表領域割当て制限の最大20%を使用できます(たとえば、100 GBの割当て制限を持つユーザーは最大20 GBをキャッシュでき、最大2 GBの割当て制限を持つユーザーは最大2 GBをキャッシュできます)。このグローバル設定は、自動キャッシュにのみ適用され、ユーザーごとに適用されます。すべてのユーザーの合計制限ではありません。DBMS_CACHE.SET_USER_PROPERTYプロシージャを実行して、個々のユーザーのこのデフォルトをオーバーライドできます。

次の問合せを実行して、キャッシュが作成され、有効になっていることを確認します。

SELECT external_table_name, cached, auto
  FROM all_external_tab_caches;

AUTOキャッシュは、通常のスケジュールで自動的にリフレッシュされます。オプションで、DBMS_CACHE.REFRESHプロシージャを使用して、指定したユーザーのすべてのキャッシュに対してオンデマンド・リフレッシュを実行することもできます。次に例を示します。

BEGIN
    DBMS_CACHE.REFRESH (
      owner          => 'HR',
      refresh_type   => 'ALL');
END;
/

この例では、必要に応じて、既存のキャッシュを更新し、HRスキーマの新しいレイク・キャッシュを作成します。refresh_typeプロパティは、リフレッシュが実行されるスコープを指定します。

レイク・キャッシュのResource Management

レイク・キャッシュ操作によって消費されるリソースは、データベース・リソース・コンシューマ・グループに割り当てることで制御できます。これにより、ワークロードを管理し、キャッシュ操作が重要なデータベース・ワークロードと競合しないようにできます。

CONSUMER_GROUPプロパティは、キャッシュ移入またはリフレッシュ操作が実行されるデータベース・リソース・グループを指定するために使用されます。たとえば、ポリシーベース・キャッシュのリソース・コンシューマ・グループを設定するには:

BEGIN
  DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY(
    property_name     => 'CONSUMER_GROUP',
    property_value    => 'LOW');
END;
/

自動キャッシュのリソース・コンシューマ・グループを設定するには:

BEGIN
  DBMS_CACHE.SET_USER_PROPERTY(
    property_name     => 'CONSUMER_GROUP',
    property_value    => 'LOW');
END;
/

CONSUMER_GROUPが指定されていない場合、操作はMEDIUMリソース・コンシューマ・グループで実行されます。

以前に構成したリソース・コンシューマ・グループをクリアし、デフォルトに戻すには:

  • ポリシーベースのキャッシュの場合、DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTYを使用して値をNULLに設定します。

  • 自動キャッシュの場合は、DBMS_CACHE.SET_USER_PROPERTYを使用して値をNULLに設定します。

これにより、CONSUMER_GROUP設定がクリアされ、次のキャッシュ操作はデフォルトのMEDIUMリソース・コンシューマ・グループを使用して実行されます。

詳細は、「SET_USER_PROPERTYプロシージャ」および「SET_USER_PROPERTYプロシージャ」を参照してください。

キャッシュ・プリファレンスの選択

外部表およびマウントされたカタログ表のキャッシュ動作およびサイズ割当てなど、適切なキャッシュ・プリファレンスを選択する方法について説明します。

レイク・キャッシュは、データベース内にスキーマ・オブジェクトとして作成され、表および索引がデータファイルに格納される方法と同様の物理領域が割り当てられます。レイク・キャッシュを作成すると、スキーマに新しい表が作成され、スキーマに設定された領域割当て制限もレイク・キャッシュに適用されます。

レイク・キャッシュ管理には、次の2つのタイプがあります。

  • ポリシーベースのキャッシュ管理

    • キャッシュの作成方法、移入方法、リフレッシュ方法およびリタイア方法を明示的に定義します。

    • キャッシュの内容とライフサイクルをきめ細かく制御できます。

    • 予測可能またはカスタマイズされたキャッシュ動作が必要な場合に適しています。

  • 自動キャッシュ管理

    • データベースは、キャッシュを自動的に作成、移入、リフレッシュおよび削除します。

    • アクションは、外部表の問合せパターンおよびワークロードの使用によって決まります。

    • 手動操作なしでキャッシュ動作を動的に適応させる環境に最適です。

レイク・キャッシュの作成の前提条件

レイク・キャッシュを作成するための前提条件をリストします。

  • レイク・キャッシュ・オブジェクトは、独自のスキーマに作成します。キャッシュ・ソースは、@catalog構文を使用して問い合せることができる外部表またはマウントされたカタログを介して公開される表です。table@catalog_nameを使用する場合、カタログはDEFAULT_SCHEMAを定義する必要があります。

  • キャッシュ・データに十分な記憶域容量があることを確認するために、スキーマに適切な領域割当て制限を割り当てる必要があります。

  • オブジェクト・ストアに格納されている外部表ファイルにアクセスするには、資格証明が必要です。Oracle Cloud Infrastructureオブジェクト・ストアへのアクセスに対してリソース・プリンシパル資格証明を有効にする場合、資格証明を作成する必要はありません。

外部表およびマウント済カタログ表に対するポリシーベースのキャッシュの使用

Autonomous AI Databaseで外部表およびマウントされたカタログ表にポリシーベースのキャッシュを使用する方法について説明します。

ポリシーベースのキャッシュでは、ソース・データがデータベース内でキャッシュ、リフレッシュおよび管理される方法を明示的に制御できます。ソース・データは、外部表またはマウントされたカタログを介して公開される表から取得できます。この方法では、DBMS_EXT_TABLE_CACHEパッケージを使用して、キャッシュ・ポリシーを定義し、キャッシュ・ライフサイクルを管理します。

この方法では、キャッシュ動作をきめ細かく制御できます。キャッシュするソース・ファイルまたはソース表のデータの割合を指定できるため、ワークロード要件に基づいてキャッシュ領域を最適に使用できます。ADD_BY_LIKEやADD_LATEST_FILESなどのプロシージャを使用すると、ファイル名パターン、変更時間、データ鮮度基準など、複数のパラメータに基づいてファイルをフィルタし、キャッシュに移入できます。

ポリシーベースのキャッシュは自動削除アルゴリズムで管理されないため、データベースでは領域不足で自動的に削除されません。キャッシュ領域が使用できなくなった場合、追加の領域が解放されるまで、新しいファイルの移入が失敗することがあります。このアプローチにより柔軟性が向上し、キャッシュの内容をより詳細に制御する必要があるワークロードに最適です。

詳細は、DBMS_EXT_TABLE_CACHEパッケージを参照してください。

次のフローチャートは、DBMS_EXT_TABLE_CACHEパッケージを使用してポリシーベースのキャッシュを管理するステップの概要を示しています。これには、キャッシュの作成、移入、削除などの主要なステップが含まれます。

adb_external_table_cache.pngの説明が続きます

図adb_external_table_cache.pngの説明

レイク・キャッシュへのファイルの移入

以前に作成したポリシーベース・キャッシュを移入する方法について説明します。

キャッシュを作成した後、ファイルをキャッシュに移入できます。ファイルへの移入では、指定された外部表ファイルの内容がキャッシュにロードされます。表からすべてのファイルを移入するか、表の特定のパーセンテージを移入するか、移入するファイルを制限するフィルタ条件を指定できます。たとえば、ファイル名または日付範囲に基づいてファイルをフィルタできます。

ノート

注意:

  • スキーマに割り当てられた領域割当て容量に応じて、Oracleはファイルをキャッシュに移入しようとします。割り当てられた割当て制限に達すると、必要な領域が割り当てられていないかぎり、Oracleはファイルの移入を停止します。

  • レイク・キャッシュは自動的にリフレッシュされません。オブジェクト・ストア上のファイルが変更されたときにキャッシュを更新するには、ファイルを再移入する必要があります。

  • オブジェクト・ストアからファイルを削除すると、対応するキャッシュ・データは即時に無効になり、取得できません。

レイク・キャッシュへの表の追加

DBMS_EXT_TABLE_CACHE.ADD_TABLEを使用して、表全体または特定の割合の外部表をキャッシュに移入します。

例

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE (
    owner         => 'SALES',
    table_name    => 'STORE_SALES');
END;
/

この例では、すでに移入されている既存のファイルをスキップして、STORE_SALES表をキャッシュに移入しようとします。

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE (
    owner         => 'SALES',
    table_name    => 'STORE_SALES',
    percent_files => 80);
END;
/

この例では、すでに移入されている既存のファイルをスキップして、STORE_SALES表の80%をキャッシュに移入しようとします。

percent_filesパラメータはオプションです。このパラメータを指定しない場合、表全体がキャッシュに移入されます。

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

レイク・キャッシュへのファイルの追加

次の手順を使用して、1つ以上のファイルをレイク・キャッシュに追加できます。

  • ADD_FILE: 単一のファイルをキャッシュに追加します。

  • ADD_BY_LIKE: 指定されたパス・フィルタに基づいて、指定された1つ以上のファイルを追加します。

  • ADD_LATEST_FILES: 指定した時間間隔に基づいて1つ以上のファイルを追加します。

例

DBMS_EXT_TABLE_CACHE.ADD_FILEプロシージャを使用して、1つのファイルをレイク・キャッシュに移入します。次に例を示します。

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

この例では、salesdata.parquetファイルのデータをキャッシュに移入します。

この例では、指定されたファイルがキャッシュ内に存在し、ファイルが最後にキャッシュされてから変更されていない場合、そのファイルのキャッシュへの移入をスキップします。

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

DBMS_EXT_TABLE_CACHE.ADD_BY_LIKEプロシージャを使用して、1つ以上のファイルをレイク・キャッシュに移入します。次に例を示します。

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

この例では、すでに移入されているファイルを除き、salesまたはcustomerで始まるすべてのファイルに名前を移入します。

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

この例では、sales_data1.parquetおよびsales_data2.parquetファイルをキャッシュに移入します。

この例では、'#'文字がエスケープ文字として定義されています。'#'に続く'_'文字は、単一文字に一致するワイルドカードとしてではなく、リテラル・アンダースコアとして扱われます。

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

最終変更日に基づいて1つ以上のファイルをレイク・キャッシュに移入するには、DBMS_EXT_TABLE_CACHE.ADD_LATEST_FILESプロシージャを使用します。次に例を示します。

BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_LATEST_FILES (
    owner        => 'SALES',
    table_name   => 'STORE_SALES',
    since        => INTERVAL '7' DAY,
    max_files    => 5,
    force        => TRUE);
END;
/

sinceパラメータは、時間間隔を指定します。過去7日以内に変更されたファイルのみがキャッシュに移入されます。

max_filesパラメータは、キャッシュに移入できるファイルの数を制限します。この例では、5つのファイルのみを移入します。

forceパラメータでは、ファイルが変更されていない場合でも、指定したファイルがキャッシュで上書きされます。

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

次のデータ・ディクショナリ・ビューを問い合せて、レイク・キャッシュにキャッシュされたファイルをリストします。

レイク・キャッシュからのファイルの削除

レイク・キャッシュからファイルを削除する例を示しています。

キャッシュからすべてのファイルを削除することも、フィルタ条件を指定してキャッシュから1つ以上のファイルを削除することもできます。たとえば、ファイル名で、または特定の時間間隔に基づいてファイルをフィルタできます。

レイク・キャッシュのクリア

DBMS_EXT_TABLE_CACHE.CLEARを使用して、レイク・キャッシュからすべてのファイルを削除します。次に例を示します。

BEGIN
  DBMS_EXT_TABLE_CACHE.CLEAR (
    owner         => 'SALES',
    table_name    => 'STORE_SALES');
END;
/

この例では、STORE_SALESキャッシュからすべてのファイルを削除し、削除されたファイルで使用されているすべての領域の割当てを解除します。

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

レイク・キャッシュからのファイルの削除

レイク・キャッシュから1つ以上のファイルを削除するには、次の手順を使用します。

  • DROP_FILE: キャッシュから単一のファイルを削除します。

  • DROP_BY_LIKE: 指定したパス・フィルタに基づいてキャッシュから1つ以上のファイルを削除します。

  • RETIRE_FILES: 指定した間隔に基づいてキャッシュから1つ以上のファイルを削除します。

例

DBMS_EXT_TABLE_CACHE.DROP_FILEを使用して、レイク・キャッシュからファイルを削除します。次に例を示します。

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

この例では、キャッシュからsalesdata.parquetファイルを削除し、削除されたファイルで使用されているすべての領域の割当てを解除します。

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

DBMS_EXT_TABLE_CACHE.DROP_BY_LIKEを使用して、path_filtersパラメータに基づいて1つ以上のファイルを削除します。次に例を示します。

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

この例では、キャッシュからsalesdata.parquetおよびsalesdata1.parquetファイルを削除し、削除されたファイルで使用されているすべての領域の割当てを解除します。

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

この例では、キャッシュからsales#_data1およびsales#_data2ファイルを削除し、削除されたファイルで使用されているすべての領域の割当てを解除します。

この例では、'#'文字がエスケープ文字として定義されています。'#'に続く'_'文字は、単一文字に一致するワイルドカードとしてではなく、リテラル・アンダースコアとして扱われます。

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

DBMS_EXT_TABLE_CACHE.RETIRE_FILESを使用して、指定した間隔に基づいて1つ以上のファイルを削除します。次に例を示します。

BEGIN
 DBMS_EXT_TABLE_CACHE.RETIRE_FILES (
    owner        => 'SALES',
    table_name   => 'STORE_SALES',
    before       => INTERVAL '30' DAY);
END;
/

この例では、キャッシュから30日より古いファイルを削除し、削除されたファイルで使用されているすべての領域の割当てを解除します。

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

前述の例では、キャッシュを保持しながら1つ以上のファイルをキャッシュから削除します。必要に応じて、ファイルをキャッシュに再度ロードできます。詳細は、「レイク・キャッシュへのファイルの移入」を参照してください。

レイク・キャッシュの無効化および有効化

レイク・キャッシュを無効化および有効化する例を示しています。

DBMS_EXT_TABLE_CACHE.DISABLEを実行して、データベースからレイク・キャッシュを無効にします。キャッシュを無効にしても、キャッシュからデータは削除されません。代わりに、キャッシュに DISABLEDフラグが付けられ、オプティマイザはクエリーリライトにキャッシュを使用できません。

例

BEGIN
    DBMS_EXT_TABLE_CACHE.DISABLE (
      owner          => 'SALES',
      table_name     => 'STORE_SALES');
END;
/

この例では、STORE_SALESキャッシュを無効にします。

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

レイク・キャッシュを無効にした後、DBMS_EXT_TABLE_CACHE.ENABLEを使用してキャッシュを有効にします。

例:

BEGIN
  DBMS_EXT_TABLE_CACHE.ENABLE (
    owner        => 'SALES',
    table_name   => 'STORE_SALES'
 );
END;
/

この例では、STORE_SALESキャッシュを有効にします。

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

レイク・キャッシュの削除

レイク・キャッシュを削除する例を示しています。

DBMS_EXT_TABLE_CACHE.DROP_CACHEを実行して、レイク・キャッシュを削除します。DBMS_EXT_TABLE_CACHE.DROP_CACHEプロシージャは、指定されたレイク・キャッシュをデータベースから削除し、キャッシュに関連付けられたストレージ領域を解放します。

例:

BEGIN
    DBMS_EXT_TABLE_CACHE.DROP_CACHE (
      owner          => 'SALES',
      table_name     => 'STORE_SALES');
END;
/

この例では、SALESスキーマからSTORE_SALESキャッシュを削除します。

キャッシュを削除すると、そのメタデータがデータ・ディクショナリから削除され、キャッシュされたすべてのデータが削除されます。

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

USER_EXTERNAL_TAB_CACHESビューを問い合せて、キャッシュが削除されたことを確認します。次に例を示します。

SELECT external_table_name, cached
  FROM user_external_tab_caches;

詳細は、「DBA_EXTERNAL_TAB_CACHESビューおよびUSER_EXTERNAL_TAB_CACHESビュー」を参照してください。

ポリシーベース・キャッシュのオプションのサイズ設定プリファレンスの設定

Autonomous AI Databaseでポリシーベースのレイク・キャッシュのサイズ設定プリファレンスを設定する方法について説明します。

デフォルトでは、レイク・キャッシュはユーザーに対して無効になっています。レイク・キャッシュを有効化および作成するには、DBMS_EXT_TABLE_CACHE.CREATE_CACHEプロシージャを使用します。キャッシュはデフォルト・スキーマに作成され、スキーマに定義された領域割当て制限を継承します。ただし、DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTYプロシージャを使用して、レイク・キャッシュの領域割当てを定義することもできます。領域割当て制限を設定するには、DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTYプロシージャのPROPERTY_NAMEおよびPROPERTY_VALUEパラメータを使用します。

PROPERTY_NAMEパラメータは、MAX_CACHE_SIZEおよびMAX_CACHE_PERCENT値を受け入れます。MAX_CACHE_SIZEプロパティは、合計外部キャッシュ・サイズをバイト単位で指定します。MAX_CACHE_PERCENTプロパティは、指定されたユーザーの割当て制限に対する合計外部キャッシュ・サイズをパーセンテージで指定します。

例

BEGIN
    DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY (
    property_name  => 'MAX_CACHE_PERCENT',
    property_value => 50,
    owner          => 'SALES');
END;
/

この例では、SALESスキーマのキャッシュ・プリファレンスをMAX_CACHE_PERCENTに設定します。

property_valueは50%で、SALESスキーマのキャッシュ領域割当て制限が、SALESに定義された合計領域割当て制限の最大50%であることを指定します。

BEGIN
    DBMS_EXT_TABLE_CACHE.SET_USER_PROPERTY (
    owner          => 'SALES',
    property_name  => 'MAX_CACHE_SIZE',
    property_value => 5368709120);
END;
/

この例では、SALESスキーマのキャッシュ・プリファレンスをMAX_CACHE_SIZEに設定します。

property_valueは5368709120で、SALESスキーマの最大キャッシュ・サイズが最大5GBであることを指定します。

詳細は、SET_USER_PROPERTYプロシージャおよびCREATE_CACHEプロシージャを参照してください。

DBMS_EXT_TABLE_CACHE.GET_USER_PROPERTYを使用して、キャッシュ・サイズのプロパティを取得します。

例:

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

詳細は、GET_USER_PROPERTYファンクションを参照してください。

キャッシュ・サイズ・プロパティを設定する場合、次の優先順位に注意してください。

  • MAX_CACHE_SIZE、MAX_CACHE_PERCENTおよび領域割当てが定義されている場合、MAX_CACHE_PERCENTはMAX_CACHE_SIZEより優先されます。

  • MAX_CACHE_SIZEのみが定義され、MAX_CACHE_PERCENTまたは領域割当てが定義されていない場合は、MAX_CACHE_SIZEが優先されます。

  • 領域割当て制限のみが定義され、MAX_CACHE_SIZEおよびMAX_CACHE_PERCENTが定義されていない場合、キャッシュ・サイズの割当て制限は、スキーマ割当て制限の合計の10%にデフォルト設定されます。

  • MAX_CACHE_SIZE、MAX_CACHE_PERCENTまたは領域割当てが定義されていない場合、キャッシュ領域割当てはデフォルトでUNLIMITEDに設定されます。

ノート

ノート:キャッシュ領域の使用状況を監視するには、ALL_EXTERNAL_TAB_CACHESビューのCACHE_CUR_SIZE列を問い合せます。詳細は、「DBA_EXTERNAL_TAB_CACHESビューおよびUSER_EXTERNAL_TAB_CACHESビュー」を参照してください。

外部表およびマウント済カタログ表に対する自動キャッシュの使用

Autonomous AI Databaseで外部表およびマウントされたカタログ表に自動キャッシュを使用する方法について説明します。

データベースの自動キャッシュを有効にすると、データベースによって、作成、移入、リフレッシュ、削除などのキャッシュ・ライフサイクル全体が、介入なしで自動的に管理されます。Oracleでは、内部メカニズムを使用して、キャッシュからメリットを得られるソース表、キャッシュをリフレッシュするタイミング、および使用パターンと使用可能な記憶域に基づいて削除するタイミングを決定します。このアプローチにより、キャッシュの使用状況が継続的に監視されるため、キャッシュ管理のオーバーヘッドが軽減され、アクセス頻度の高いソース・データがキャッシュに保持されて問合せのレスポンス時間が短縮されます。

デフォルトでは、データベースでは自動キャッシュは有効になっていません。これを有効にするには、DBMS_CACHEパッケージで提供されているDBMS_CACHE.SET_USER_PROPERTYなどのプロシージャを使用して、キャッシュ・サイズを0以外の値に設定する必要があります。要件に応じて、特定のユーザーに対して自動キャッシュを構成するか、すべてのデータベース・ユーザーのデフォルト設定として自動キャッシュを構成できます。

適格なソース表の自動キャッシュを有効にすると、OracleはAUTOとマークされたレイク・キャッシュを作成し、割当て制限が許可されている場合は、ソース表から対応するすべてのデータをそのキャッシュに移入します。AUTOキャッシュは、通常のスケジュールで自動的にリフレッシュされます。ただし、DBMS_CACHE.REFRESHプロシージャまたはDBMS_CACHE.CLEARプロシージャを使用して、キャッシュをそれぞれリフレッシュまたは削除することもできます。

Oracleは、Least Recently Used (LRU)に似た削除アルゴリズムを使用してAUTOキャッシュを管理します。領域が不足している場合、最近アクセスされたキャッシュはリフレッシュ・サイクル中に自動的に削除され、ストレージ領域が解放されます。

詳細は、次を参照してください:

外部表およびマウント済カタログ表の自動キャッシュの有効化

自動キャッシュ・プロパティを構成する方法について説明します。

デフォルトでは、自動キャッシュは無効になっています。外部表およびマウントされたカタログ表を含む適格なソース表の自動キャッシュは、すべてのデータベース・ユーザーに対してグローバルに、または特定のユーザーに対して有効にできます。自動キャッシュを有効にすると、データベースは自動的にレイク・キャッシュを作成します。新しく作成されたキャッシュはすべて AUTOとマークされます。既存のキャッシュは、引き続きポリシーベースのキャッシュ管理設定に従います。

DBMS_CACHE.SET_GLOBAL_PROPERTYまたはDBMS_CACHE.SET_USER_PROPERTYを使用して、AUTOキャッシュ・プロパティ(グローバルまたは指定したユーザーに対して自動キャッシュを有効にするプロパティを含む)を設定します。ユーザー・レベルのキャッシュ・プリファレンスは、グローバル・キャッシュ・プリファレンスよりも優先されます。レイク・キャッシュの領域割当て制限を設定するには、これらのプロシージャのPROPERTY_NAMEおよびPROPERTY_VALUEパラメータを使用します。

指定した領域割当て容量に応じて、Oracleはキャッシュを作成し、ソース表データ全体をキャッシュに移入しようとします。キャッシュ・サイズがソース表のデータ全体を格納するのに十分でない場合、移入プロセスは失敗します。

  1. DBMS_CACHE.SET_GLOBAL_PROPERTYを使用して、すべてのデータベース・ユーザーの自動キャッシュを有効にします。

    例:

    すべてのデータベース・ユーザーの自動キャッシュを有効にする例:

    BEGIN
 DBMS_CACHE.SET_GLOBAL_PROPERTY (
    property_name       => 'MAX_CACHE_PERCENT',
    property_value_num  => 20);
END;
/

    この例では、すべてのデータベース・ユーザーのデフォルトとしてキャッシュ・プリファレンスをMAX_CACHE_PERCENTに設定し、Lake Cache割当て制限を、割り当てられたユーザー割当て制限の合計の最大20%に設定します。DBMS_CACHE.SET_USER_PROPERTYプロシージャを使用して、個々のユーザーのこのデフォルト設定をオーバーライドできます。

    自動キャッシュを有効にする場合は、必要に応じてキャッシュ・リフレッシュの範囲(各リフレッシュ・サイクル中にリフレッシュの対象となるキャッシュ)を指定し、リフレッシュ・プロセスの完了を許可する時間ウィンドウを定義できます。

    すべてのデータベース・ユーザーの自動リフレッシュ・モードを設定する例:

    BEGIN
 DBMS_CACHE.SET_GLOBAL_PROPERTY (
    property_name       => 'AUTO_REFRESH_MODE',
    property_value_str  => 'NEW');
END;
/

    これは、各リフレッシュ・サイクル中にAUTOキャッシュがリフレッシュされるスコープを指定します。property_value_str値は、DBMS_CACHE.SET_USER_PROPERTYプロシージャを使用してスキーマ・レベルでオーバーライドできます。

    リフレッシュを完了できる最大時間ウィンドウを設定する例:

    BEGIN
 DBMS_CACHE.SET_GLOBAL_PROPERTY (
    property_name       => 'MAX_REFRESH_WINDOW',
    property_value_num  => 20);
END;
/

    この例では、MAX_REFRESH_WINDOWを20秒に設定します。

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

    ノート

    ノート: MAX_REFRESH_WINDOWプロパティはデータベース・レベルでのみ定義でき、このプロパティはスキーマ・レベルでは設定できません。

    DBMS_CACHE.GET_GLOBAL_PROPERTYを実行して、デフォルトの自動レイク・キャッシュ・プリファレンスを取得します。次に例を示します。

    SET SERVEROUTPUT ON;
DECLARE
   cache_property NUMBER;
BEGIN
   DBMS_CACHE.GET_GLOBAL_PROPERTY (
      property_name  => 'MAX_CACHE_SIZE',
      property_value => cache_property
   );
 DBMS_OUTPUT.PUT_LINE('MAX_CACHE_SIZE = ' || cache_property);
END;
/

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

  2. DBMS_CACHE.SET_USER_PROPERTYを使用して、特定のユーザーに対して適格なソース表の自動キャッシュを有効にします。次に例を示します。

    BEGIN
 DBMS_CACHE.SET_USER_PROPERTY (
        property_name       => 'MAX_CACHE_PERCENT',
        property_value_num  => 50,
        owner               => 'HR');
END;
/

    この例では、グローバル・キャッシュ・プリファレンスをDBMS_CACHE.SET_USER_PROPERTYで指定された値でオーバーライドします。

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

    DBMS_CACHE.GET_USER_PROPERTYを使用して、指定したユーザーの自動レイク・キャッシュ・プリファレンスを取得します。次に例を示します。

    SET SERVEROUTPUT ON;
DECLARE
   cache_property NUMBER;
BEGIN
   DBMS_CACHE.GET_USER_PROPERTY (
      property_name  => 'MAX_CACHE_SIZE',
      owner          => 'HR',
      property_value => cache_property
   );
 DBMS_OUTPUT.PUT_LINE('MAX_CACHE_SIZE = ' || cache_property);
END;
/

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

    ノート

    ノート:キャッシュ領域の使用状況を監視するには、ALL_EXTERNAL_TAB_CACHESビューのCACHE_CUR_SIZE列を問い合せます。詳細は、「DBA_EXTERNAL_TAB_CACHESビューおよびUSER_EXTERNAL_TAB_CACHESビュー」を参照してください。

レイク・キャッシュのリフレッシュ

指定したスキーマのAUTOキャッシュをリフレッシュする例を示しています。

AUTOキャッシュは、通常のスケジュールで自動的にリフレッシュされます。指定したリフレッシュ・タイプに応じて、データベースは次のことが可能です。

  • 新しいキャッシュを追加します。

  • 無効なキャッシュを削除します(アクセスできなくなったキャッシュは無効としてマークされ、後続のリフレッシュ・サイクルで削除されます)。

  • 既存のキャッシュを更新または再移入します。

  • 領域が不足している場合は、最近アクセスしたキャッシュを削除します。

または、DBMS_CACHE.REFRESHプロシージャを使用して、HRユーザーのすべてのキャッシュに対してオンデマンド・リフレッシュを実行することもできます。

  1. DBMS_CACHE.REFRESHを使用して、HRユーザーのすべてのレイク・キャッシュをリフレッシュします。次に例を示します。

    BEGIN
    DBMS_CACHE.REFRESH (
      owner          => 'HR',
      refresh_type   => 'ALL');
END;
/

    この例では、必要に応じて、既存のキャッシュを更新し、HRスキーマの新しいレイク・キャッシュを作成します。

    refresh_typeプロパティは、リフレッシュが実行されるスコープを指定します。このプロパティーには、次の値のいずれかを指定できます。

    • ALL: HRスキーマの既存のAUTOキャッシュはすべてリフレッシュされ、必要に応じて新しいキャッシュが作成されます。

    • CURRENT: 既存のキャッシュのみがリフレッシュされ、新しいキャッシュは追加されません。

    • NEW: 新しいキャッシュのみが作成されます。

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

レイク・キャッシュの削除

指定されたスキーマの AUTOキャッシュを削除する例を示しています。

リフレッシュ・サイクルごとに、無効なキャッシュおよび最も最近アクセスされたキャッシュがデータベースから削除されます。または、DBMS_CACHE.CLEARプロシージャを使用して、指定したユーザーのすべてのキャッシュを削除できます。

  1. DBMS_CACHE.CLEARを使用して、HRスキーマのすべてのレイク・キャッシュを削除します。次に例を示します。

    BEGIN
 DBMS_CACHE.CLEAR (
    owner => 'HR');
END;
/

    この例では、HRスキーマのすべてのレイク・キャッシュを削除します。

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

レイク・キャッシュ・パフォーマンスのモニターおよび診断

Autonomous AI Databaseは、レイク・キャッシュを監視できるビューを提供します。同じ監視ビューが、外部表から作成されたキャッシュ、およびマウントされたカタログ表から作成されたキャッシュに適用されます。

表示 摘要
DBA_EXTERNAL_TAB_CACHESおよびUSER_EXTERNAL_TAB_CACHESビュー データベース内のすべてのレイク・キャッシュまたはユーザーのレイク・キャッシュに関する情報を提供します。
外部_TAB_CACHE_LOCATIONS 現在のユーザーがアクセスでき、キャッシュされた外部表に属しているクラウド・ストレージ内のファイルに関する情報を提供します。
ユーザー_外部_タブ_キャッシュ_ロケーション 現在のユーザーが所有し、キャッシュされた外部表に属しているクラウド・ストレージ内のファイルに関する情報を提供します。このビューは、OWNER列を表示しません。

これらのビューは、外部表のキャッシュされたデータのデータベース内での格納、アクセスおよび保守方法に関する詳細情報を提供します。これらのビューを使用すると、キャッシュ・パフォーマンスを監視し、古いデータまたは古いデータを識別し、領域使用率を分析して、最適な問合せ効率を確保できます。これらのビューを監視することで、キャッシュをリフレッシュする必要があるタイミングを検出し、キャッシュ・サイズが構成済の制限内にあることを確認し、外部データ・アクセスに関連するパフォーマンスのボトルネックを診断できます。

例:

次の問合せは、アクティブまたは失効しているレイク・キャッシュに関する情報を提供します。その後、失効したキャッシュをクリアまたは削除して、必要に応じてストレージ領域を解放できます。

SELECT table_name, cached, stale, last_refreshed, last_accessed
  FROM all_external_tab_cache_locations
  ORDER BY stale DESC, usage_count DESC;

次の問合せは、キャッシュ・インベントリおよび領域使用量に関する情報を提供します。

SELECT external_table_name, cache_cur_size, cache_max_size, disabled
    FROM user_external_tab_caches;

レイク・キャッシングのユースケース

外部表およびマウントされたカタログ表にレイク・キャッシュが役立つ一般的なシナリオについて説明します。

ユースケース キャッシュ対象 コストへの影響 パフォーマンスへの影響 ノート
外部表に対する対話型のBIまたはダッシュボード ダッシュボードにフィードするよく問合せされる外部表またはパーティション クラウド間またはリージョン間の読取りの繰返しを排除します ホット・データをローカルに保持して、応答時間を短縮し、コールド・スタートを回避します。 これは最も一般的なシナリオです。
マルチクラウド分析(S3やGCS、Azureを読むOCI上のAutonomous AI Databaseなど) OCI以外のオブジェクト・ストアからアクセスされるホット・データセット クロス・クラウド・エグレスを削減し、プロバイダ・リクエスト料金を削減 リモートI/Oおよびネットワーク待機時間を削除します。 コストとレイテンシを一緒にコールアウト
@catalog構文で問い合せたマウント済カタログ表 [schema].table@catalog_nameまたはtable@catalog_nameを介してアクセスされる、頻繁に問合せされる表またはホット・パーティション リモート読取りおよびエグレスを繰り返し削減します。 ネイティブ・データベース表にデータをコピーすることなく、問合せのレイテンシが繰り返される DBMS_CATALOGメタデータ・キャッシュとは別にキャッシュします。
クロス・リージョン(同じクラウド)アクセス 別のリージョンの外部データ リピート・スキャンのリージョン間のエグレスを回避 読取りをローカライズして待機時間を短縮します。 マルチクラウドと同じ理屈。
外部データに対するマテリアライズド・ビューのリフレッシュ マテリアライズド・ビューのソース外部表 スケジュールされたリフレッシュの繰返しエグレスが少なくなります マテリアライズド・ビューのリフレッシュを安定化および高速化して、リモート・スキャン時間を短縮 ほぼリアルタイムの集計に最適
最新のファイル・パイプライン(ランディング・ゾーン) ADD_LATEST_FILESを使用したファイルの過去N時間または日数   最新データは常にホット  
小規模だが頻繁に結合される参照データ 結合に使用される小さい外部表 多数の小さいリクエストによるオーバーロードの防止 結合のローカル参照データを保持します 小規模なディクショナリ・データは常に最新であるため、複雑なETLを維持する必要はありません。
データ・サイエンスと機能エンジニアリング 外部表での再利用されたトレーニングまたは機能セット 反復作業中のリモート読取りの削減 実験中に繰り返されるスキャンの高速化 ノートブック駆動ループで適切に動作します。
バースティまたはスロットルされたオブジェクト・ストア 高トラフィック外部表 多くのユーザーでの再試行回数の削減 ストアのスロットルおよび変数のスループットから問合せを保護します。 SLA予測可能性の向上
アイスバーグまたは大規模なパーティション化された湖 ホット・パーティションまたはスナップショットが頻繁に読み取られる 同じparquetストライプの繰返し読取りを回避します ホット・パーティションのデータ・ページをローカライズし、問合せ時間を短縮します。 Iceberg設定ページへのクロスリンク
大規模なアドホック探索 リピート・アクセスを表示する暫定外部表 探索中にエグレスを返済することを回避 初回パス後にフォローアップ問合せをスナッピーにする パイプラインをコピーしないランプに適しています。

レイク・キャッシュを使用したマウント済カタログ表のキャッシュ

レイク・キャッシュを使用して、カタログSQL構文を介してアクセスするカタログ・バックアップ表をキャッシュする方法について説明します。

Oracle Autonomous AI Databaseでのレイク・キャッシュのサポートにより、カタログSQL構文([schema].object@catalog_nameなど)を介してアクセスされるカタログ・バックアップ表をキャッシュできます。外部表の既存のレイク・キャッシュ機能を、リモート・カタログおよびデータベースに使用されるマウントされたカタログ問合せモデルと組み合せます。

マウントされたカタログ表のキャッシュの利点

Lake Cacheは、頻繁にアクセスされるソース・データをAutonomous AI Database内にローカルに格納することで、パフォーマンスを向上させます。リモート・カタログでは、カタログSQL構文(schema.object@catalog_nameなど)を使用して、カタログ・バックアップ表を直接問い合せることができます。

レイク・キャッシュは、Parquet、ORC、AVRO、CSVおよびIcebergデータ・ソースに基づく外部表をサポートします。マウントされたカタログ表のLake Cacheは、カタログにバックアップされたIceberg表、およびDatabricks Unity Catalog、Snowflake Polaris Catalog、Amazon Glue CatalogなどのCatalog SQL構文を介してアクセスされるマウントされたカタログへのキャッシュ・サポートを拡張します。

マウントされたカタログ表に対してレイク・キャッシュを有効にすることで、外部表で使用可能な同じキャッシュ機能をカタログベースのワークロードに適用できます。DBMS_CATALOG.MOUNT_ICEBERGまたはData Studioを使用してマウントされたカタログは、レイク・キャッシュを使用して、既存のカタログSQL問合せを変更することなく、頻繁にアクセスされるカタログ・バックアップ表をキャッシュできます。これにより、カタログ・ワークロードは、問合せパフォーマンスの向上とデータ転送コストの削減の恩恵を受けることができ、既存のカタログSQL問合せを変更する必要がありません。

次のワークフローは、Apache Icebergカタログをマウントし、Catalog SQL構文で問い合せて、Lake Cacheを作成する方法を示しています。

マウントされたカタログ表キャッシュの前提条件

マウントされたカタログ表のキャッシュを作成する前に、次のことを確認してください。

  • カタログがマウントされます。

  • ターゲット表は、カタログSQL構文を使用して問い合せることができます。

  • 独自のスキーマにレイク・キャッシュを作成します。

  • キャッシュ・オブジェクトおよびキャッシュされたデータに対して十分なスキーマ割当て制限を使用できます。

マウントされたカタログ表のレイク・キャッシュの作成および移入

レイク・キャッシュを使用してマウントされたカタログ表をキャッシュする方法を示します。

  1. DBMS_CATALOG.MOUNT_ICEBERGプロシージャを使用して、サポートされている外部カタログをマウントします。

    次の例では、指定されたRESTエンドポイントおよび資格証明を使用してAutonomous AI Databaseからsales_iceberg_catカタログを問い合せることができるように、外部Apache Icebergカタログをマウントします:

    BEGIN
  DBMS_CATALOG.MOUNT_ICEBERG(
    catalog_name            => 'sales_iceberg_cat',
    endpoint                => 'https://example-catalog-endpoint',
    catalog_credential      => 'ICEBERG_CATALOG_CRED',
    data_storage_credential => 'ICEBERG_DATA_CRED'
  );
END;
/

    次の表では、パラメータについて説明します。

    パラメータ 摘要
    catalog_name データベース内のカタログの名前を指定します。この名前は、問合せおよびその他のDBMS_CATALOGプロシージャでIcebergカタログを参照する場合に使用します。
    endpoint Iceberg RESTカタログ・サービスのURLを指定します。これは、Autonomous AI DatabaseがIcebergデータベース、表およびスナップショットの検出に使用するネットワーク・エンドポイントです。
    catalog_credential Iceberg RESTカタログへのアクセスに必要な認証情報を含むデータベース資格証明の名前を指定します。
    data_storage_credential オブジェクト・ストレージのIceberg表のデータファイルへのアクセスに必要な認証情報を含むデータベース資格証明の名前を指定します。

    詳細は、「DBMS_CATALOGを使用したカタログの管理」を参照してください。

  2. マウントされたカタログを問い合せます。

    カタログをマウントした後、カタログSQL構文を使用してその表を問い合せることができます。次の構文を使用してリモート表を参照します。

    SELECT * FROM sales_schema.orders@sales_iceberg_cat;

    この構文は、sales_iceberg_catとしてマウントされたIcebergカタログのsales_schemaスキーマにあるorders表のすべての行を問い合せます。@sales_iceberg_cat接尾辞は、ローカル・スキーマではなく外部カタログから表を解決するようデータベースに通知します。

  3. DBMS_EXT_TABLE_CACHE.CREATE_CACHEを使用して、マウントされたカタログ表のレイク・キャッシュを作成します。

    DBMS_EXT_TABLE_CACHE.CREATE_CACHEプロシージャを実行して、外部Iceberg表のレイク・キャッシュを定義します。

    BEGIN
  DBMS_EXT_TABLE_CACHE.CREATE_CACHE(
    owner          => 'SALES_SCHEMA',
    table_name     => 'ORDERS@sales_iceberg_cat',
    partition_type => 'FILE'
  );
END;
/

    次の表では、パラメータについて説明します。

    パラメータ 摘要
    owner この外部表のキャッシュ・メタデータを所有するデータベース・スキーマの名前を指定します。この例では、SALES_SCHEMAです。
    table_name カタログ修飾子を含め、キャッシュする外部表の名前を指定します。この例では、ORDERS@sales_iceberg_catです。これは、キャッシュが作成されるIceberg表を識別します。
    partition_type レイク・キャッシュがキャッシュされたデータをパーティション化する方法を指定します。

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

  4. 他のポリシーベースのレイク・キャッシュに使用する既存のDBMS_EXT_TABLE_CACHEプロシージャをキャッシュに移入および管理します。

    DBMS_EXT_TABLE_CACHE.ADD_TABLEプロシージャは、指定された外部表のデータをキャッシュに移入します。

    BEGIN
  DBMS_EXT_TABLE_CACHE.ADD_TABLE(
    owner      => 'SALES_SCHEMA',
    table_name => 'ORDERS@sales_iceberg_cat'
  );
END;
/

    次の表では、パラメータについて説明します。

    パラメータ 摘要
    owner 更新するキャッシュ定義を所有するスキーマを指定します。これは、CREATE_CACHEと同じである必要があります。
    table_name データがキャッシュにロードされるカタログ修飾子を含む外部表を指定します。レイク・キャッシュはIceberg表から読み取り、キャッシュされたデータをマテリアライズして、後続の問合せを高速化します。

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

このワークフローでは、Oracle Autonomous AI DatabaseでマウントされたIcebergカタログを操作するプロセスを示し、データへのアクセスからレイク・キャッシュの作成および管理までを行ってパフォーマンスを向上させ、表へのアクセスを合理化します。