Oracle Autonomous AI DatabaseからBigQueryとSnowflakeに対して、SELECT AI - Sidecarを実行する

Last updated at 2025-11-07Posted at 2025-11-07

はじめに
環境準備
【検証その1】ADBからBigQueryへのSidecar
- 【検証その1】準備
- 【検証その1】結果
【検証その2】ADBからSnowflakeへのSidecar
- 【検証その2】準備
- 【検証その2】結果
【検証その3】ADBからBigQueryとSnowflakeの両方へのSidecar
- 【検証その3】準備
- 【検証その3】結果
【補足】Materialized ViewへのSELECT AI
- 【補足】準備
- 【補足】結果
まとめ
参考情報

はじめに

目的
本記事の目的は、ADBの SELECT AI - Sidecar 機能を用いて、SnowflakeとBigQueryに対して自然言語からSQLを自動生成・実行する手順とアーキテクチャを共有することです。
データを移動させることなく既存のDWHにアクセスするパターンを具体的なコード付きで紹介し、実際に試してみて分かったハマりどころやベストプラクティスをまとめることで、マルチクラウド環境でLLMを活用したいエンジニアの方の参考になることを目指します。

High-Level Architecture
高レベルの構成図を示します。
ADBのSELECT AI - Sidecarを使い、LLM が自然言語からSQLを生成して、データを移動させずに Google BigQuery と Snowflake へクエリを実行します。

Low-Level Architecture
詳細なアーキテクチャ図を示します。
product_name列を持つPRODUCTS表と、order_date列などを持つORDERS表に自然文でアクセスするシナリオで検証を行います。
OCI・Snowflake・BigQuery は、いずれも Osakaリージョン上の環境で検証を実施しています。

SELECT AIの機能

SELECT AIには以下のとおり、たくさんの機能があります。
https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/select-ai-features.html

Select AI Conversations：自然言語を用いた対話機能
- runsql：SQLの結果セットを返す
- showsql：生成されたSQLを返す
- explainsql：生成されたSQLの説明を返す
- narrate：会話形式で結果を返す
- chat：一般的なAIチャット
Select AI with Retrieval Augmented Generation (RAG)：ベクトル検索を使用したRAGの実行
Synthetic Data Generation：LLMによる合成データ生成
Feedback：NL2SQL結果に対するユーザー・フィードバックを提供し、将来のクエリを改善
Generate a Summary with Select AI：テキストのサマリーの生成
Translate：LLMを利用してテキストを選択した言語に翻訳

本記事で主に利用するのは、runsql、showsql、narrateの機能です。

補足

ADB：Oracle Autonomous AI Database
BigQuery：Google Cloud BigQuery
SELECT AI：ADBの自然言語を用いたSQL変換機能
Sidecar：ADBをハブとした、Oracle DBや異種DBに対する横串検索

環境準備

ADBやBigQuery、Snowflakeを構築し、サンプルデータの入った表を作成します。

サンプルデータ

以下の表をSQLで作成します。

ORDERS 表
BigQueryに作成する。

PRODUCTS 表
Snowflakeに作成する。

ADBの作成と設定

ADBの作成

以下を参考に、ADBを作成する。
https://docs.oracle.com/ja-jp/iaas/autonomous-database-serverless/doc/autonomous-provision.html#GUID-0B230036-0A05-4CA3-AF9D-97A255AE0C08

本検証では、ネットワーク・アクセスとして「すべての場所からのセキュア・アクセス」を選択しています。
一方で、本番環境などを想定する場合は、FastConnect や IPsec VPN を用いた「許可されたIPおよびVCN限定のセキュア・アクセス」や、「プライベート・エンドポイント・アクセスのみ」とする構成が推奨されます。

DBユーザーの作成

以下を参考に、Database ActionsにAdminとしてアクセスし、新規ユーザーを作成する。
https://docs.oracle.com/ja-jp/iaas/autonomous-database-serverless/doc/manage-users-create.html#ADBSB-GUID-DD0D847B-0283-47F5-9EF3-D8252084F0C1

ユーザー名：ADBSNOWBQ（※任意）

権限の付与

Adminユーザーで以下を実行する。

GRANT DB_DEVELOPER_ROLE TO ADBSNOWBQ;
GRANT EXECUTE ON DBMS_CLOUD TO ADBSNOWBQ;
GRANT EXECUTE ON DBMS_CLOUD_AI TO ADBSNOWBQ;
GRANT EXECUTE ON DBMS_CLOUD_ADMIN TO ADBSNOWBQ;
GRANT CREATE DATABASE LINK TO ADBSNOWBQ;
ALTER USER ADBSNOWBQ QUOTA UNLIMITED ON USERS;
GRANT READ, WRITE ON DIRECTORY data_pump_dir TO ADBSNOWBQ;

BigQueryの作成と設定

プロジェクトの作成

以下を参考に、Google Cloud プロジェクトを作成する
https://developers.google.com/workspace/guides/create-project?hl=ja

プロジェクト名：My Project TEST

データセットの作成

以下を参考に、データセットを作成する
https://docs.cloud.google.com/bigquery/docs/datasets?hl=ja

データセット名：datasettest
リージョン：Google Cloud asia-northeast2 (大阪)

テーブルの作成

以下を参考に、テーブルを作成する
https://docs.cloud.google.com/bigquery/docs/tables?hl=ja

テーブル名：ORDERS

SQLを実行し、テーブルを作成する。

CREATE TABLE `datasettest.ORDERS` (
  ORDER_ID    STRING,
  PRODUCT_ID  STRING,
  QUANTITY    INT64,
  ORDER_DATE  DATE
);

SQLを実行し、データを挿入する。

INSERT INTO `datasettest.ORDERS` (
  ORDER_ID,
  PRODUCT_ID,
  QUANTITY,
  ORDER_DATE
)
VALUES
  ('O1001', 'P0001', 2, DATE '2025-11-01'),
  ('O1002', 'P0003', 1, DATE '2025-11-01'),
  ('O1005', 'P0004', 2, DATE '2025-11-03'),
  ('O1006', 'P0001', 1, DATE '2025-11-03'),
  ('O1008', 'P0009', 2, DATE '2025-11-04'),
  ('O1009', 'P0008', 1, DATE '2025-11-04'),
  ('O1010', 'P0010', 5, DATE '2025-11-05');

以下のとおり、ORDERS表が完成する。

Snowflakeの作成と設定

Databaseの作成

Database名：DATABASETEST
リージョン：AWS Asia Pacific (Osaka)

テーブルの作成
NotebookでSQLを実行し、テーブルを作成する。

テーブル名：PRODUCTS

CREATE OR REPLACE TABLE DATABASETEST.PUBLIC.PRODUCTS (
    PRODUCT_ID        VARCHAR(10000),
    PRODUCT_NAME      VARCHAR(10000),
    UNIT_PRICE        NUMBER(38,0),
    PRODUCT_DETAILES  VARCHAR(10000)
);

NotebookでSQLを実行し、データを挿入する。

INSERT INTO DATABASETEST.PUBLIC.PRODUCTS (
    PRODUCT_ID,
    PRODUCT_NAME,
    UNIT_PRICE,
    PRODUCT_DETAILES
)
VALUES
    ('P0001', 'Wireless Mouse', 1980,
     'Ergonomic wireless mouse with 2.4GHz receiver and silent click buttons.'),
    ('P0003', 'USB-C Hub 7-in-1', 3980,
     'USB-C hub with HDMI, USB 3.0 ports, SD card reader, and PD charging.'),
    ('P0004', '27-inch 4K Monitor', 39800,
     'Ultra HD 4K display with IPS panel and adjustable stand for office work.'),
    ('P0005', 'Noise Cancelling Headphones', 12800,
     'Over-ear wireless headphones with active noise cancelling and 30h battery life.'),
    ('P0006', 'Portable SSD 1TB', 15800,
     'High-speed USB 3.2 portable SSD ideal for backups and large file transfers.'),
    ('P0007', 'Laptop Stand', 2980,
     'Aluminum adjustable laptop stand for better posture and heat dissipation.'),
    ('P0009', 'Bluetooth Speaker', 6580,
     'Portable Bluetooth speaker with rich bass and up to 12 hours of playback.'),
    ('P0010', 'Smartphone Charger 65W', 4280,
     'Fast USB-C PD charger suitable for laptops, tablets, and smartphones.');

以下のとおり、PRODUCTS表が完成する。

【検証その1】ADBからBigQueryへのSidecar

ADBからBigQueryへのSidecarの機能や性能を検証します。

【検証その1】準備

はじめに
Google Cloud の OAuth とは、アプリケーションがユーザーやサービスアカウントに代わって、BigQuery や DriveなどのGoogle APIに安全にアクセスするための「認可の仕組み（トークンのやりとりルール）」です。
本検証のSELECT AI - Sidecarで用いるDBMS_CLOUD.CREATE_CREDENTIALには、このOAuthによる認可が必要となります。

OAuthに同意

以下を参考に、OAuthの同意画面を設定する。
https://developers.google.com/workspace/guides/configure-oauth-consent?hl=ja

対象：外部

OAuthクライアントIDの作成

以下を参考に、OAuthクライアントIDを作成する。
https://support.google.com/workspacemigrate/answer/9222992?hl=ja

リダイレクトURL：http://localhost

以下をメモしておく。

クライアント ID
クライアントシークレット

Authorization codeの取得

以下をブラウザに張り付けてアクセスする。

https://accounts.google.com/o/oauth2/v2/auth?
 client_id=[クライアントID]&
 redirect_uri=http://localhost&
 response_type=code&
 scope=https://www.googleapis.com/auth/bigquery&
 access_type=offline&
 prompt=consent

「続行」をクリックします。

以下のような画面になったら、URLをコピーします。

以下のようなURLが取得できる。

http://localhost/?code=<認証コード>&scope=https://www.googleapis.com/auth/bigquery

以下を参考に、<認証コード> <クライアントID> <クライアントシークレット>を使って、コマンドプロンプトなどから以下を実行
https://docs.cloud.google.com/apigee/docs/api-platform/security/oauth/access-tokens?hl=ja

curl -XPOST https://www.googleapis.com/oauth2/v4/token --data "code=[認証コード]&redirect_uri=http://localhost&client_id=[クライアントID]&client_secret=[クライアントシークレット]&scope=&grant_type=authorization_code"

以下のような結果が出たら、成功です。
後続で利用するrefresh_tokenが得られました。

{
  "access_token": "<access_token>",
  "expires_in": 3599,
  "refresh_token": "<refresh_token>",
  "scope": "https://www.googleapis.com/auth/bigquery",
  "token_type": "Bearer"
}

以下のように出たら失敗です。
もう一度、【検証その1】準備からやり直してください。

invalid_grant が出る場合は、

認証コードの使い回し
OAuthクライアントIDの redirect_uri と curl の redirect_uri 不一致
なども原因になり得ます。

{
  "error": "invalid_grant",
  "error_description": "Bad Request"
}

Heterogeneous Connectivityの作成
以下を参考に、Heterogeneous Connectivity（異機種間DBLINK）を作成します。
https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/database-links-other-databases-oracle-managed.html#GUID-9FBC138F-7B22-4D14-96CF-349ADE2959F5

まずは、CREDENTIALを作成します。

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'GOOGLE_BIGQUERY_OAUTH',
    params => JSON_OBJECT(
                 'gcp_oauth2' value JSON_OBJECT(
                        'client_id' value '<client_id>', 
                        'client_secret' value '<client_secret>', 
                        'refresh_token' value '<refresh_token>')));
END;
/

続いて、DATABASE_LINKを作成します。

BEGIN
     DBMS_CLOUD_ADMIN.CREATE_DATABASE_LINK(
          db_link_name => 'GOOGLE_BIGQUERY_LINK', 
          hostname => 'example.com', 
          port => '443',
          service_name => 'bigquery_service',
          credential_name => 'GOOGLE_BIGQUERY_OAUTH',
          gateway_params => JSON_OBJECT(
              'db_type'  value 'google_bigquery',
              'project' value '<your project name>')
    );
END;
/

「PL/SQLプロシージャが正常に完了しました。」と表示されると成功です。
上記のGOOGLE_BIGQUERY_LINKを使って、テストします。

SELECT * FROM "datasettest.ORDERS"@GOOGLE_BIGQUERY_LINK;

成功すると、以下のようにADBからBigQueryの結果が確認できます。

失敗するケースは、以下のとおりです。

表を指定する際に、""が抜けている
表名の指定が間違っている（ex.大文字を小文字で記載してしまっている等）

VIEWの作成

GOOGLE_BIGQUERY_LINKを利用して、VIEWを作成します。

CREATE VIEW ADB_BQ_V AS SELECT ORDER_ID, PRODUCT_ID, QUANTITY, ORDER_DATE FROM "datasettest.ORDERS"@GOOGLE_BIGQUERY_LINK;

これで、Sidecarの準備が整いました。

APIキーのダウンロード

ここからは、SELECT AIの準備をします。
以下を参考に、APIキー・ペアを生成し、秘密キーと公開キーをダウンロードします。
https://docs.oracle.com/ja-jp/iaas/Content/Identity/access/to_upload_an_API_signing_key.htm

ocidの確認

以下を参考に、user_ocidとtenancy_ocidを確認します。
https://docs.oracle.com/ja-jp/iaas/Content/API/Concepts/apisigningkey.htm#five

SELECT AI用のCREDENTIALの発行

上記を使って、Database ActionsからADBSNOWBQユーザーで実行します。
以下を参考に、SELECT AI用のCREDENTIALを発行します。
https://docs.oracle.com/ja-jp/iaas/autonomous-database-serverless/doc/select-ai-examples.html#ADBSB-GUID-BD10A668-42A6-4B44-BC77-FE5E5592DE27

BEGIN
    DBMS_CLOUD.CREATE_CREDENTIAL(
        credential_name => 'OCI_GENAI',
        user_ocid       => '<user_ocid>',
        tenancy_ocid    => '<tenancy_ocid>',
        private_key     => '<private_key>',
        fingerprint     => '<fingerprint>'
    );
END;
/

SELECT AI用のプロファイルの作成

SELECT AI用のプロファイルを作成します。
本検証では、OCI Generative AIのcohere.command-r-plus-08-2024というLLMモデルを利用します。

SELECT AI におけるLLMのサポート状況については、以下のドキュメントをご確認ください。
https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/select-ai-about.html#ADBSB-GUID-FDAEF22A-5DDF-4BAE-A465-C1D568C75812
ただし、リージョンごとにサポート状況が異なる場合がありますので、あわせて以下もご確認ください。
https://docs.oracle.com/en-us/iaas/Content/generative-ai/pretrained-models.htm#chat-models

（補足ですが、SELECT AIでサポートされていないcohere.command-a-03-2025でも一応動きました。）

BEGIN
    DBMS_CLOUD_AI.CREATE_PROFILE(
        'GENAI_COHERE',
        '{
            "provider": "oci",
            "credential_name": "OCI_GENAI",
            "model":"cohere.command-r-plus-08-2024",
            "oci_apiformat":"COHERE",
            "region": "ap-osaka-1",
            "object_list": [
                    {"owner": "ADBSNOWBQ", "name": "ADB_BQ_V"}
            ]
        }'
    );
END;
/

これで準備完了です。

【検証その1】結果

では、検証してみたいと思います。

SELECT DBMS_CLOUD_AI.GENERATE(prompt       => 'ADB_BQ_V表のデータ件数はいくつですか？',
                              profile_name => 'GENAI_COHERE',
                              action       => 'runsql')
FROM dual;

# 実行結果（実行時間: 25.325秒）
[
  {
    "COUNT(*)" : 7
  }
]

正しく回答を返してくれました。
別の質問をします。

SELECT DBMS_CLOUD_AI.GENERATE(prompt       => 'ADB_BQ_V表の中でQuantityが1のものをカウントしてください。',
                              profile_name => 'GENAI_COHERE',
                              action       => 'runsql')
FROM dual;

# 実行結果（実行時間: 17.553秒）
  {
    "COUNT(*)" : 3
  }
]

正しく回答を返してくれました。

別の機能（showsql）を使って、生成されたSQLを確認します。

SELECT DBMS_CLOUD_AI.GENERATE(prompt       => 'ADB_BQ_V表の中でQuantityが1のものをカウントしてください。',
                              profile_name => 'GENAI_COHERE',
                              action       => 'showsql')
FROM dual;

# 実行結果（実行時間: 9.701秒）
SELECT COUNT(*)
FROM "ADBSNOWBQ"."ADB_BQ_V"
WHERE UPPER("QUANTITY") = 1

SQLを理解できました。
本来UPPERは不要ですが、今回の検証ではそのままでも実行できました。

別の機能（narrate）を使って、会話形式で結果を返してもらいます。

SELECT DBMS_CLOUD_AI.GENERATE(prompt       => 'ADB_BQ_V表の中でQuantityが1のものをカウントしてください。',
                              profile_name => 'GENAI_COHERE',
                              action       => 'narrate')
FROM dual;

# 実行結果（実行時間: 10.686秒）
ADB_BQ_V 表には、数量が 1 の製品が 3 つあります。

「自然言語で問いかけ、自然言語で結果を説明する」ことができ、SQLの知識が不足している方も使えることがわかりました！
先が長そうなので、ADBからBigQueryへのSidecar検証はこのくらいにしておきます...。

【検証その2】ADBからSnowflakeへのSidecar

続いて、ADBからSnowflakeへのSidecarの機能や性能を検証します。
BigQueryへのSidecarと比較すると、そこまで難しくないはずです。

【検証その2】準備

Snowflake情報の確認

Sidecarに必要な情報として、Accont/Server URLとLogin nameを確認します。（※Login時に使用するPasswordも必要です。）

account detailsに入ります。

hostnameとLogin nameを確認します。

Credentialの作成

Database actionsにADBSNOWBQユーザーとして入り、CREDENTIALを作成します。
確認したLogin nameとpasswordを利用します。

BEGIN
    DBMS_CLOUD.CREATE_CREDENTIAL( 
        credential_name => 'SNOWFLAKE_CRED', 
        username => '<Login name>', 
        password => '<Password>');
END;
/

Database Linkの作成

確認したAccont/Server URLを利用して、DATABASE LINKを作成します。

service_name：snowflakeで作成したデータベース名

BEGIN
    DBMS_CLOUD_ADMIN.CREATE_DATABASE_LINK(
        db_link_name => 'SNOWFLAKE_LINK', 
        hostname => '<Accont/Server URL>', 
        port => '443', 
        service_name => 'DATABASETEST',
        ssl_server_cert_dn => null, 
        credential_name => 'SNOWFLAKE_CRED', 
        gateway_params => JSON_OBJECT( 'db_type' value 'snowflake'));
END;
/

「PL/SQLプロシージャが正常に完了しました。」と表示されると成功です。
上記のSNOWFLAKE_LINKを使って、テストします。

SELECT * FROM PRODUCTS@SNOWFLAKE_LINK;

成功すると、以下のようにADBからSnowflakeのPRODUCTS表が確認できます。

VIEWの作成

SNOWFLAKE_LINKを利用して、VIEWを作成します。

CREATE VIEW ADB_SNOW_V AS SELECT * FROM PRODUCTS@SNOWFLAKE_LINK;

これで、Sidecarの準備が整いました。

SELECT AI用のプロファイルの作成

BigQueryへのSidecarで作成したOCI_GENAIクレデンシャルを使って、Snowflake用のSELECT AIのプロファイルを作成します。
同様にOCI Generative AIのcohere.command-r-plus-08-2024というLLMモデルを利用します。
注意点としては、OCI_GENAIクレデンシャルは使いまわしてもよいですが、Snowflake用のプロファイル名はBigQuery用と重複しないようにしましょう。（※ここでは、GENAI_COHERE_SNOWを使用）

BEGIN
    DBMS_CLOUD_AI.CREATE_PROFILE(
        'GENAI_COHERE_SNOW',
        '{
            "provider": "oci",
            "credential_name": "OCI_GENAI",
            "model":"cohere.command-r-plus-08-2024",
            "oci_apiformat":"COHERE",
            "region": "ap-osaka-1",
            "object_list": [
                    {"owner": "ADBSNOWBQ", "name": "ADB_SNOW_V"}
            ]
        }'
    );
END;
/

これで準備完了です。

【検証その2】結果

では、検証してみたいと思います。

SELECT DBMS_CLOUD_AI.GENERATE(prompt       => 'ADB_SNOW_V表のデータ件数はいくつですか？',
                              profile_name => 'GENAI_COHERE_SNOW',
                              action       => 'runsql')
FROM dual;

# 実行結果（実行時間: 16.046秒）
[
  {
    "COUNT(*)" : 8
  }
]

正しく回答を返してくれました。
ADBからSnowflakeへのSidecar検証は終わりです。

【検証その3】ADBからBigQueryとSnowflakeの両方へのSidecar

では、BigQueryとSnowflakeの両方に対して一気にSidecarを実行してみたいと思います。

【検証その3】準備

2つのDBLINKからVIEWの作成

BigQueryのDBLINKとSNOWFLAKEのDBLINKからVIEWを作ります。

CREATE OR REPLACE VIEW ADB_BQ_SNOW_V AS
SELECT
    od.ORDER_ID,          
    od.PRODUCT_ID,        
    od.QUANTITY,          
    od.ORDER_DATE,        
    p.PRODUCT_NAME,       
    p.UNIT_PRICE,        
    p.PRODUCT_DETAILES   
FROM
    "datasettest.ORDERS"@GOOGLE_BIGQUERY_LINK od
    INNER JOIN
    PRODUCTS@SNOWFLAKE_LINK p
        ON od.PRODUCT_ID = p.PRODUCT_ID;

成功すると、以下のようにADBからBigQueryとSnowflakeのVIEWが確認できます。

完璧にINNER JOINできていました！

SELECT AI用のプロファイルの作成

BigQueryとSnowflake用のSELECT AIのプロファイルを作成します。
同様にOCI Generative AIのcohere.command-r-plus-08-2024というLLMモデルを利用します。

BEGIN
    DBMS_CLOUD_AI.CREATE_PROFILE(
        'GENAI_COHERE_BQ_SNOW',
        '{
            "provider": "oci",
            "credential_name": "OCI_GENAI",
            "model":"cohere.command-r-plus-08-2024",
            "oci_apiformat":"COHERE",
            "region": "ap-osaka-1",
            "object_list": [
                    {"owner": "ADBSNOWBQ", "name": "ADB_BQ_SNOW_V"}
            ]
        }'
    );
END;
/

これで準備完了です。

【検証その3】結果

では、検証してみたいと思います。

SELECT DBMS_CLOUD_AI.GENERATE(prompt       => 'ADB_BQ_SNOW_V表のデータ件数はいくつですか？',
                              profile_name => 'GENAI_COHERE_BQ_SNOW',
                              action       => 'runsql')
FROM dual;

# 実行結果（実行時間: 17.337秒）
[
  {
    "COUNT(*)" : 6
  }
]

正しく回答を返してくれました。

ちょいと複雑なシナリオもやってみます。（※はじめにのLow-Level Architectureで示したシナリオです。）

SELECT DBMS_CLOUD_AI.GENERATE(prompt       => 'ADB_BQ_SNOW_V表からBlutooth　SpeakerのORDER_DATEを取ってきて。',
                              profile_name => 'GENAI_COHERE_BQ_SNOW',
                              action       => 'runsql')
FROM dual;


# 実行結果（実行時間: 19.956秒）
[
  {
    "ORDER_DATE" : "2025-11-04T00:00:00"
  }
]

これも正しく回答を返してくれました。

ADBからBigQueryとSnowflakeの両方に対して一気にSidecarを実行することも可能でした。

【補足】Materialized ViewへのSELECT AI

ADBからいろんなソースに対してデータコピーなく、自然言語問い合わせを実行できました!!...
が、とはいえ、レイテンシも気になりますよね？？
やはり、距離的に離れている分、Internet経由だと10秒以上くらいのレスポンスタイムがかかってしまいます。
そんなときは、Materialized Viewを使用しましょう！
単なる「データ移行」だと、そのとき一回でコピーして終わりですが、「DBリンク経由のマテリアライズド・ビュー」だと、コピーに加えて継続的な同期（リフレッシュ）を、DBの機能で実施できます。

【補足】準備

Materialized Viewの作成
以下を参考にMaterialized Viewを作成します。
https://docs.oracle.com/en/database/oracle/oracle-database/26/heter/heterogeneous-replication.html?utm_source=chatgpt.com#GUID-4460493F-1360-40DA-8209-969A4AB23DF1

SnowflakeへのDBLINKに対して、Materialized Viewを作成します。
注意点として、Oracle以外への異機種間DBリンク経由のMaterialized ViewではFAST REFRESH
（マテリアライズド・ビューへの変更を増分的に適用）はサポートされず、
COMPLETE REFRESH（マテリアライズド・ビューの定義問合せを再計算する）前提となります。

CREATE MATERIALIZED VIEW ADB_SNOW_MV
  BUILD IMMEDIATE
  REFRESH COMPLETE
  ON DEMAND
AS
SELECT *
  FROM PRODUCTS@SNOWFLAKE_LINK;

自動リフレッシュを導入したい場合、以下のように作成します。（1時間ごとにリフレッシュ）

CREATE MATERIALIZED VIEW ADB_SNOW_AUTO_REF_MV
  BUILD IMMEDIATE
  REFRESH COMPLETE
  START WITH SYSDATE
  NEXT SYSDATE + 1/24 
AS
SELECT *
  FROM PRODUCTS@SNOWFLAKE_LINK;

補足

BigQueryのDBLINK（または、VIEW）からMaterialized VIEWを作るのは成功しませんでした。（※原因を調査中）
レイテンシを抑えたい場合は、CTASや通常のテーブル＋マテビューを使って、いったんADB側にデータをステージングするのが現実的なパターンになりそうです。

CREATE TABLE ADB_BQ_T AS
SELECT * FROM "datasettest.ORDERS"@GOOGLE_BIGQUERY_LINK;

SELECT AI用のプロファイルの作成

ADB_SNOW_AUTO_REF_MV用のSELECT AIのプロファイルを作成します。
同様にOCI Generative AIのcohere.command-r-plus-08-2024というLLMモデルを利用します。

BEGIN
    DBMS_CLOUD_AI.CREATE_PROFILE(
        'GENAI_COHERE_SNOW_AUTO_REF_MV',
        '{
            "provider": "oci",
            "credential_name": "OCI_GENAI",
            "model":"cohere.command-r-plus-08-2024",
            "oci_apiformat":"COHERE",
            "region": "ap-osaka-1",
            "object_list": [
                    {"owner": "ADBSNOWBQ", "name": "ADB_SNOW_AUTO_REF_MV"}
            ]
        }'
    );
END;
/

これで準備完了です。

【補足】結果

では、このADB_SNOW_AUTO_REF_MVに対してSELECT AIを検証してみたいと思います。

SELECT DBMS_CLOUD_AI.GENERATE(prompt       => 'ADB_SNOW_AUTO_REF_MV表のデータ件数はいくつですか？',
                              profile_name => 'GENAI_COHERE_SNOW_AUTO_REF_MV',
                              action       => 'runsql')
FROM dual;

# 実行結果（実行時間: 0.944秒）
[
  {
    "COUNT(*)" : 8
  }
]

実行時間0.9秒で正しい結果を返してくれました！

まとめ

本記事では、Oracle Autonomous AI Database の SELECT AI - Sidecar 機能を使って、次の 3 パターンを検証しました。

ADBからBigQueryへのSidecar
ADBからSnowflakeへのSidecar
BigQueryとSnowflakeをJOINしたVIEWへのSidecar

いずれのケースでも、ユーザーは SQL を直接書かずに自然言語で質問し、runsql、showsql、narrateなどのアクションを通じて、外部 DWH 上のデータを扱えることを確認しました。これにより、SQL に詳しくないユーザーでも、マルチクラウド環境のデータにアクセスしやすくなることが分かりました。

一方で、Sidecar はネットワーク越しに BigQuery / Snowflake へクエリを発行するため、レイテンシの影響は無視できません。そこで本記事では、Snowflake向けのMaterialized ViewやCTASによるステージング表を用意し、SELECT AIの参照先をADBローカルに寄せるパターンも試しました。その結果、同じような質問に対しても、応答時間を短縮できることを確認しています。

アクセス先	パターン	実行時間の目安
BigQuery / Snowflake（リモート）	SELECT AI - Sidecar で直接 `runsql`	約 10〜20秒
ADB Materialized View（ローカル）	SELECT AI でローカル MV を `runsql`	約 1秒弱

※ 実行時間は、筆者の検証環境（Osakaリージョン間＋インターネット経由）での目安値です。ネットワークや環境により変動します。

マルチクラウド環境では、「すべてのデータを1か所に集約する」のは現実的でないケースが増えています。SELECT AI - Sidecar を使うことで、

既存のBigQuery / Snowflakeをそのまま活かしつつ
ADBをハブとした統合的な NL2SQLの入り口を提供し
必要に応じてMaterialized Viewやデータマートへ段階的に寄せていく
といったアーキテクチャを無理なく構成できることが見えてきました。

本記事の手順やサンプルコードが、マルチクラウド環境でNL2SQLを試してみたい方の参考になれば幸いです。

参考情報

Select AIを使用したデータベースとの自然言語対話：SELECT AI ドキュメント
Create Database Links to Non-Oracle Databases with Oracle-Managed Heterogeneous Connectivity：Select AI - Sidecarでサポートされる接続
SnowflakeにADBから自然言語で問い合わせしてみた (SELECT AIを使ったADB Sidecar)：ADBからSnowflakeへのSELECT AI - Sidecar接続

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Oracle Autonomous AI DatabaseからBigQueryとSnowflakeに対して、SELECT AI - Sidecarを実行する

目次

はじめに

環境準備

サンプルデータ

ADBの作成と設定

BigQueryの作成と設定

Snowflakeの作成と設定

【検証その1】ADBからBigQueryへのSidecar

【検証その1】準備

【検証その1】結果

【検証その2】ADBからSnowflakeへのSidecar

【検証その2】準備

【検証その2】結果

【検証その3】ADBからBigQueryとSnowflakeの両方へのSidecar

【検証その3】準備

【検証その3】結果

【補足】Materialized ViewへのSELECT AI

【補足】準備

【補足】結果

まとめ

参考情報