レイク・キャッシュを使用した外部表のパフォーマンスの向上

Oracle Autonomous AI Databaseのレイク・キャッシュを使用すると、データベース内の外部表から頻繁にアクセスされるデータをキャッシュできます。

ノート

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

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

レイク・キャッシュは、外部表からのデータを格納する自律型AIデータベース内のストレージ領域です。

外部データはデータベースによって管理されませんが、外部表を使用してデータベース外部のデータを問い合せることができます。外部表に対する問合せは、データベース表に対する問合せほど高速ではありません。データにアクセスするたびに、オブジェクト・ストアに格納されている外部ファイルからフェッチする必要があるためです。

レイク・キャッシュを使用すると、アクセス頻度の高い外部データをローカルに格納できます。キャッシュを使用すると、外部表に対する問合せで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/data1.parquetの場合、FILE$PATH = 'sales/2024/09/' (フォルダ)になります。

レイク・キャッシュを初めて作成する場合、そのメタデータはデータ・ディクショナリに格納されます。ただし、キャッシュ・データには領域は割り当てられません。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表をキャッシュに移入しようとします。

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

デフォルトでは、自動キャッシュは無効になっており、自動キャッシュを有効にすると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_PERCENT20に設定すると、自動外部表キャッシュでは、各ユーザーが割り当てた表領域割当て制限の最大20%を使用できます(たとえば、100 GBの割当て制限を持つユーザーは最大20 GBをキャッシュでき、10 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プロパティは、リフレッシュが実行されるスコープを指定します。

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

キャッシュ動作や外部表のサイズ割当てなど、適切なキャッシュ・プリファレンスを選択する方法について説明します。

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

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

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

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

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

  • 自動キャッシュ管理

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

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

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

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

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

  • 独自のスキーマおよび所有する外部表に対してのみレイク・キャッシュを作成できます。

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

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

外部表に対するポリシーベースのキャッシュの使用

Autonomous AI Databaseの外部表にポリシーベースのキャッシュを使用する方法について説明します。

ポリシーベースのキャッシュでは、外部データがデータベース内でキャッシュ、リフレッシュおよび管理される方法を明示的に制御できます。このアプローチでは、DBMS_EXT_TABLE_CACHEパッケージで使用可能なPL/SQLプロシージャを使用して、キャッシュ・ポリシーを定義し、キャッシュ・ライフサイクル全体を管理します。これらのプロシージャを使用すると、キャッシュの作成と移入、キャッシュからのファイルの削除、キャッシュの有効化または無効化など、様々なキャッシュ・ライフサイクル操作を明示的に実行できます。

このアプローチにより、キャッシュ動作をきめ細かく制御できます。キャッシュする外部表ファイルまたは外部表のデータの割合を指定できるため、ワークロード要件に基づいてキャッシュ領域を最適に使用できます。ADD_BY_LIKEADD_LATEST_FILESなどのプロシージャを使用すると、ファイル名パターン、変更時間、データ鮮度基準など、複数のパラメータに基づいてファイルをフィルタし、キャッシュに移入できます。同様に、CLEARRETIRE_FILESDROP_BY_LIKEなどのプロシージャを使用して、キャッシュからファイルを削除できます。

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

詳細は、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_value5368709120で、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_SIZEMAX_CACHE_PERCENTおよび領域割当てが定義されている場合、MAX_CACHE_PERCENTMAX_CACHE_SIZEより優先されます。

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

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

  • MAX_CACHE_SIZEMAX_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およびネットワーク待機時間を削除します。

コストとレイテンシを一緒にコールアウト

クロス・リージョン(同じクラウド)アクセス

別のリージョンの外部データ

リピート・スキャンのクロスリージョン・エグレスを回避

読取りをローカライズして待機時間を短縮します。

マルチクラウドと同じ理屈。

外部データに対するマテリアライズド・ビューのリフレッシュ

マテリアライズド・ビューのソース外部表

スケジュールされたリフレッシュの繰返しエグレスが少なくなります

マテリアライズド・ビューのリフレッシュを安定化および高速化して、リモート・スキャン時間を短縮

ほぼリアルタイムの集計に最適

最新のファイル・パイプライン(ランディング・ゾーン)

ADD_LATEST_FILESを使用したファイルの過去N時間または日数

 

最新データは常にホット

 

小規模だが頻繁に結合される参照データ

結合に使用される小さい外部表

多数の小さいリクエストによるオーバーロードの防止

結合のローカル参照データを保持します

小規模なディクショナリ・データは常に最新であるため、複雑なETLを維持する必要はありません。

データ・サイエンスと機能エンジニアリング

外部表での再利用されたトレーニングまたは機能セット

反復作業中のリモート読取りの削減

実験中に繰り返されるスキャンの高速化

ノートブック駆動ループで適切に動作します。

バースティまたはスロットルされたオブジェクト・ストア

高トラフィック外部表

多くのユーザーでの再試行回数の削減

ストアのスロットルおよび変数のスループットから問合せを保護します。

SLA予測可能性の向上

アイスバーグまたは大規模なパーティション化された湖

ホット・パーティションまたはスナップショットが頻繁に読み取られる

同じparquetストライプの繰返し読取りを回避します

ホット・パーティションのデータ・ページをローカライズし、問合せ時間を短縮します。

Iceberg設定ページへのクロスリンク

大規模なアドホック探索

リピート・アクセスを表示する暫定外部表

探索中にエグレスを返済することを回避

初回パス後にフォローアップ問合せをスナッピーにする

パイプラインをコピーしないランプに適しています。