共有の消費

プロバイダがオブジェクトを共有したら、受信者が共有を消費するために従う必要があるステップがいくつかあります。

「共有の消費」ページを使用して、次の操作を実行します。
  • 共有の消費の概要:

    データ共有を消費するには、それらにサブスクライブし、共有に含まれる表のビューを作成する必要があります。

  • バージョン管理された共有の消費:

    受信者は、共有プロファイルをダウンロードし、データ共有プロバイダにサブスクライブし、共有を登録して、共有上に外部表を作成する必要があります。データ共有ツールは、アクティブ化メールによって受信者に送信されるJSONプロファイルを使用してアクセスを承認します。アクセス権が付与されると、データ共有ツールが共有オブジェクトをデータ・リンク・ツールにリンクします。このツールでは、コンシューマはデータ・リンク・ジョブを実行し、プロバイダが共有するオブジェクトにアクセスできます。

  • ライブ共有の消費:

    これにより、受信者はデータベースからライブ・データを消費できます。

  • 共有プロバイダ・エンティティ詳細の表示:

    ライブ共有またはデルタ共有プロバイダ・エンティティ・エントリの右側にある「アクション」アイコンを使用して、作成したライブ共有またはデルタ共有プロバイダ・エンティティの詳細を表示します。

共有の消費の概要

「消費共有」ページには、共有プロバイダのリストの概要と、共有プロバイダを検索および追加するオプションが表示されます。

「共有の消費」ページに移動するには、次のいずれかを実行します。
  • Data Studioのメニューで、「データ共有」メニューの「共有の消費」を選択します。
  • 「データ共有」ページで、「プロバイダおよびコンシューマ」セクションにある「共有の消費」ウィジェットをクリックします。

「共有の消費」ページには次のものが含まれます。consume-share-new.pngの説明が続きます
図consume-share-new.pngの説明

  1. 過去7日間の使用可能なライブ共有プロバイダ

    この領域には、過去7日間に作成した使用可能なライブ共有プロバイダのリストが表示されます。必要に応じて任意のフィールドを更新できます。過去7日間の使用可能な共有にリストされている共有の右側にある+記号を使用して、ライブ共有をサブスクライブすることもできます。

  2. 「サブスクライブ済共有プロバイダの検索」フィールド

    作成した共有受信者を検索するには、サブスクライブ済共有プロバイダの名前を入力します。サブスクライブ済共有プロバイダの名前(REVIEW_PROVIDERなど)を入力し、拡大鏡アイコンをクリックして検索を完了します。共有ツールでは、表示領域に検索結果が表示されます。

  3. +共有プロバイダへのサブスクライブを選択して、新しい共有プロバイダにサブスクライブします。このアイコンの詳細は、共有プロバイダへのサブスクライブを参照してください。
  4. 自分の共有ID

    共有IDは、Autonomous Databaseの一意のプロバイダです。このIDをクリップボードにコピーし、「共有受信者の作成」ウィザードの「共有ID」フィールドに貼り付けます。これにより、ライブ共有を共有プロバイダと共有できるようになります。

  5. ツールバー

    ツールバーは、「ソート基準」、「ページ・サイズ」、「リフレッシュ」および「エンティティ・ビュー」オプションで構成されます。

  6. ソート基準設定

    ツールバーの「ソート基準」コントロールを使用してソート値を設定すると、設定がツールバーの下の小さいボックスに表示されます。設定を削除するには、ボックスの「X」アイコンをクリックします。または、ツールバーの「ソート基準」 コントロールに戻って設定を変更できます。

  7. 表示領域

    コンシューマ共有プロバイダの検索フィールドの下の領域には、検索から返され、「フィルタ」パネルに設定したフィルタ基準と一致するエンティティが表示されます。エンティティは、「ソート基準」ボタンをクリックしてソート値を設定することでソートできます。

バージョン管理された共有の消費

Oracle Autonomous Database内で共有バージョン管理データを使用できるようにするには、次のステップに従う必要があります。Delta Sharingを介して共有されるデータは、「Autonomous Database」で自動的には使用可能にならず、検出できません

提供されているデータ共有をサブスクライブしてアクセスするステップは、次のとおりです。
  • JSONプロファイルのダウンロード
  • データ共有プロバイダのサブスクライブ
  • 使用可能にした共有を登録します。
  • 共有の外部表の作成

JSONプロファイルについて

Delta Sharing Profilesは、共有プロバイダに接続し、Delta Sharing Serverにアクセスするのに役立ちます。プロファイル情報は、JSON形式のクライアント資格証明を含むZipファイルに格納されます。共有データにアクセスするには、認可されたJSONプロファイルを使用して共有オブジェクトを登録する必要があります。その後、Delta Sharing Serverで認証するためにJSONプロファイルを使用し、使用可能なデータ共有にアクセスできます。

JSONプロファイルのダウンロード

共有ツールが共有オブジェクトを作成すると、受信者はDelt@共有プロファイルをダウンロードするためのリンクを含む電子メール通知を受信します。データベース・アクション・コンソールからJSONプロファイルをダウンロードすることもできます:

  1. 「共有の指定」ページで、受信者の横にある3つのドットをクリックし、「プロファイル・アクティブ化リンクをクリップボードにコピー」を選択します。

  2. このリンクをWebブラウザで開き、デルタ プロファイル ダウンロード ページにアクセスします。

  3. 「プロファイル情報の取得」をクリックして、Delta Sharing JSONプロファイルを含むZipファイルをダウンロードします。

ノート:

セキュリティ上の理由から、プロファイル情報は一度しかダウンロードできません。ボタンを2回クリックすると、プロファイルのダウンロードに失敗します。詳細は、クイック・スタート・ガイドを参照してください。

JSONプロファイル・タイプ

この図は、JSONプロファイルを示し、DatabricksのbearerTokenおよびOIDCを使用してデルタ共有を使用する方法を示しています。



デルタ共有では、次のプロファイルがサポートされています。

  • BearerTokenを使用したプロファイル・バージョン1

    このJSONファイルには、トークンをリフレッシュできるように、tokenEndpointclientIDおよびclientSecretを含めることができます。

  • Databricks共有でのOIDC (PL/SQLのみ)を使用したプロファイル・バージョン2

    このJSONファイルには、OpenID Connect (OIDC)およびOAuthクライアント資格証明(clientIdclientSecrettokenEndpointなど)が含まれています。Databricks OIDCプロファイルでは、shareCredentialsVersion 2およびtype oauth_client_credentialsが使用されますが、bearerTokenはサポートされていません。Autonomous Databaseでは、tokenEndpointを使用して、有効性が短いアクセス・トークンを取得し、自動的にリフレッシュします。

    プロファイル・バージョン2では、配布する存続期間が長いベアラー・トークンがなく、シークレットのローテーションが簡単で、自動化が強化されるため、セキュリティが向上します。

ノート:

OIDCでは、Databricks endpointおよびIdP tokenEndpointへのアウトバウンド・アクセスを許可する必要があります。

消費共有でデルタ共有プロバイダをサブスクライブする場合、JSONファイル・バージョン1またはバージョン2を使用するか、「共有プロバイダJSON」フィールドに直接Zipファイルをアップロードできます。

例: JSONプロファイル・バージョン1
{
        "shareCredentialsVersion": 1, 
        "endpoint": "https://myhost.us.example.com/ords/prov/_delta_sharing/", 
        "tokenEndpoint": "http://myhost.us.example.com:1234/ords/pdbdba/oauth/token", 
        "bearerToken": "-xxxxxxxxxxxxxxxxxxxxx", 
        "expirationTime": "20XX-01-13T07:53:11.073Z", 
        "clientID": "xxxxxxxxxxxxxxxxxxxxxx..", 
        "clientSecret": "xxxxxxxxxxxxxxxxxxxx.."
}
パラメータは次のとおりです。
  • shareCredentialsVersion: プロファイル・フォーマット・バージョン1を表示します。

  • endpoint: Autonomous Databaseによってホストされるデルタ共有サーバーのベースHTTPS URLを指定します。このRESTエンドポイントをコールして、共有、スキーマ、表を検出し、Parquetファイルの署名付きURLをフェッチできます。

  • tokenEndpoint: トークン・エンドポイントを指定します。共有ツール・クライアントは、Oracleを使用して共有を摂取している場合、トークン・エンドポイントを使用してBearerトークン上のタイムアウトのリフレッシュを行います。

  • bearerToken: これは、ログイン・リクエストに応答することで認証サーバーが生成する暗号化文字列です。通常は有効性が高くなります。

  • expirationTime: 認証の有効期限が切れたまでにかかった時間です。

  • clientID: 認証のためにインスタンスを登録する際、認証サーバーが生成する公開識別子を指定します。
  • clientSecret: 認証サーバーが認可のために生成するシークレット識別子を指定します。
例: JSONプロファイル・バージョン2
{
        "shareCredentialsVersion": 2, 
        "endpoint": "https://myhost.us.example.com/ords/prov/_delta_sharing/", 
        "tokenEndpoint": "http://myhost.us.example.com:1234/ords/pdbdba/oauth/token", 
        "type": "oauth_client_credentials",
        "clientId": "xxxxxxxxxxxxxxxxxxxxxx..", 
        "clientSecret": "xxxxxxxxxxxxxxxxxxxx..",
        "tokenScope": "xxxxxxxxxx"
}
パラメータは次のとおりです。
  • shareCredentialsVersion: プロファイル形式バージョン2を表示します。

  • endpoint: Autonomous Databaseによってホストされるデルタ共有サーバーのベースHTTPS URLを指定します。このRESTエンドポイントをコールして、共有、スキーマ、表を検出し、Parquetファイルの署名付きURLをフェッチできます。

  • tokenEndpoint: トークン・エンドポイントを指定します。

  • type: 使用する認証フロー。ここでは、OAuth 2.0クライアント資格証明付与です。

  • clientId: 認証のためにインスタンスを登録する際、認証サーバーが生成する公開識別子を指定します。
  • clientSecret: 認証サーバーが認可のために生成するシークレット識別子を指定します。
  • tokenScope: トークン取得時にリクエストするOAuthスコープ(多くの場合、スペース区切り)。共有検出およびデータ取得に付与されるアクセス・レベルを決定します。

両方のプロファイルのクライアントIDの場合の違いに注意してください。プロファイル1にはclientIDがあり、プロファイル2にはclientIdがあります。

セキュリティの機能拡張

共有受信者として、共有プロバイダのマシンに対するアクセス制御リスト(ACL)を設定する必要があります。これには、ADMINユーザーまたは別の権限を持つユーザーとしてAPPEND_HOST_ACEプロシージャを使用します。これにより、インターネット経由で共有にアクセスできます。

ノート:

これは、「共有プロバイダの追加」ウィザードで、ホストのアクセス制御リスト(ACL) (つまり、共有プロバイダ)にアクセス制御エントリ(ACE)を追加する前に行う必要があります。ホスト名は前のステップでダウンロードしたJSONプロファイルから検索できます。

たとえば、データベース・ユーザー、A_SHARE_USERに指定したホスト(共有プロバイダ)のエンドポイントへのアクセスを許可する場合に、SQLワークシート・エディタで管理者として実行するPL/SQLプロシージャのサンプルを次に示します。前提条件として、前述の例に示すように、デルタ共有JSONプロファイルのエンドポイント・プロパティからホスト名を抽出します。例のホスト名はmyhost.us.example.comです。

BEGIN 
        dbms_network_acl_admin.append_host_ace(    
        host =>'myhost.us.example.com', 
        lower_port=>443,    
        upper_port=>443,
        ace => xs$ace_type(      
        privilege_list => xs$name_list('http', 'http_proxy'),      
        principal_name =>'A_SHARE_USER',
        principal_type => xs_acl.ptype_db)); 
        COMMIT;
        END;        
/

次に、パラメータとその説明を示します。

  • host- ホストの名前またはIPアドレスを指定します。ホストまたはドメイン名は大/小文字が区別されません。
  • lower port- オプションのTCPポート範囲の下側のポートを指定します。
  • upper port- オプションのTCPポート範囲の上側のポートを指定します。
  • ace- アクセス制御エントリ。
  • privilege list- 付与または拒否するネットワーク権限のリストを指定します。
  • principal_name- 権限が付与または拒否される主体(データベース・ユーザーまたはロール)です。大/小文字が区別されます。
  • principal_type- 使用するプリンシパルのタイプを指定します。

DBMS_NETWORK_ACL_ADMINパッケージ・サブプログラムの詳細は、PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスのドキュメントを参照してください。

ローカルORDSエンドポイントでユーザーにACLを付与します。ローカルに作成された共有でベアラー・トークンを生成するには、これが必要です。
PRIV_ORDS_ACL             CONSTANT PLS_INTEGER := 8;

プライベート・エンドポイントでのデルタ共有のアウトバウンド・アクセスの許可

コンシューマAutonomous AI Databaseでプライベート・エンドポイントが使用されている場合は、デルタ共有プロバイダをサブスクライブし、共有データ用の外部表を作成する前にアウトバウンド・アクセスを構成します。

デルタ共有では、プロバイダendpointを使用し、存在する場合はtokenEndpointを使用して共有を検出し、アクセス・トークンを取得します。コンシューマ・データベースは、Delta Sharingサーバーによって返された署名付きURLを使用して、共有Parquetファイルをオブジェクト・ストレージから直接読み取ります。したがって、デルタ共有プロバイダ・エンドポイントと、署名付きURLによって参照されるオブジェクト・ストレージ・ホストの両方に対してアウトバウンド接続を構成します。

前提条件

  • コンシューマAutonomous AI Databaseは、プライベート・エンドポイント・アクセスを使用します。

  • ADMINとしてデータベースに接続できます。

  • プロバイダからのDelta Sharing JSONプロファイルがあります。

  • 共有ファイルが、ファイアウォールまたはIPルールによって保護されているパブリック・ストレージ・エンドポイントの背後に格納されているか、プライベート・ストレージ・エンドポイントの背後に格納されているかがわかります。

アウトバウンド・アクセスの構成

  1. ADMINとしてコンシューマ・データベースに接続します。

  2. 現在のアウトバウンド・ルーティング・モードを確認します。

    SELECT property_name, property_value
    FROM database_properties
    WHERE property_name = 'ROUTE_OUTBOUND_CONNECTIONS';

    問合せで行が返されない場合、プロパティは設定されません。この場合、パブリック・エンドポイントへのアウトバウンド接続では、サービスVCN NATゲートウェイが使用されます。

  3. ROUTE_OUTBOUND_CONNECTIONSが設定されていない場合は、パブリック・エンドポイントに対してコンシューマ・データベースで使用されるアウトバウンドIPアドレスを決定します。

    SELECT cloud_identity
    FROM v$pdbs;

    JSON出力でOUTBOUND_IP_ADDRESSフィールドを見つけます。

    • 署名付きURLがファイアウォールまたはIPルールによって保護されているパブリック・ストレージ・エンドポイントを参照する場合は、コンシューマ・データベースOUTBOUND_IP_ADDRESSをストレージ・サービス許可リストに追加します。

    • 共有ファイルでプライベート・ストレージ・エンドポイントを使用する場合は、パブリックIP許可リストではなくプライベート接続およびDNSを構成します。これにより、コンシューマ・データベースはプライベート・ネットワーク・パスを介してストレージ・アカウントに到達できます。

  4. デルタ共有トラフィックをプライベート・エンドポイント経由でルーティングします。

    ALTER DATABASE PROPERTY
    SET ROUTE_OUTBOUND_CONNECTIONS = 'ENFORCE_PRIVATE_ENDPOINT';

    ノート:

    Oracleでは、PRIVATE_ENDPOINTの制限が含まれ、DBMS_CLOUDパッケージおよび外部表によって行われたアウトバウンド接続にも適用されるため、ENFORCE_PRIVATE_ENDPOINTを使用することをお薦めします。

    このプロパティが設定されている場合、アウトバウンド接続は、プライベート・エンドポイントに関連付けられたVCNセキュリティ・リストまたはネットワーク・セキュリティ・グループ(NSG)で構成されたプライベート・エンドポイント・エグレス・ルールに準拠する必要があります。

    デフォルトの動作をリストアするには、次を実行します。

    ALTER DATABASE PROPERTY
    SET ROUTE_OUTBOUND_CONNECTIONS = '';
  5. コンシューマ・データベースが、必要なすべてのホスト(つまり、次のホスト)を解決してアクセスできるようにします。

    • デルタ共有のエンドポイント

    • tokenEndpoint (存在する場合)

    • 問合せ時に返された署名付きURLによって参照されるオブジェクト・ストレージ・ホスト

シェアプロバイダをサブスクライブする前に、コンシューマスキーマ内のプロバイダホストに必要なACLエントリを作成します。

JSONプロファイルのアップロードによる共有プロバイダ・サブスクリプションの作成

このプロセスでは、受信者へのアクセスを有効にするために、プロバイダの構成および資格証明のJSONプロファイルをロードします。

  1. 「共有の消費」ページを開き、「+ 共有プロバイダへのサブスクライブ」をクリックして、ドロップダウンから「デルタ共有プロバイダへのサブスクライブ」を選択します。これにより、「共有プロバイダのサブスクライブ」ウィンドウが開きます。subscribe-share-provider-version-providersettings.pngの説明が続きます
    図subscribe-share-provider-version-providersettings.pngの説明
  2. 「プロバイダ設定」で次を指定します。

    • Share Source: 「Delta Share Provider JSON」を選択します。

    • 共有プロバイダJSON: 次のオプションを使用してJSONプロファイルを共有できます-

      ファイルから: このオプションを選択し、「デルタ共有プロファイルJSON」をクリックして、システム上のJSONプロファイルを参照およびアップロードします。または、JSONプロファイルを含むZipファイルを「プロバイダJSONの共有」フィールドに直接アップロードすることもできます。

      JSON: JSONファイルの内容を指定された領域に貼り付けるには、このオプションを選択します。開始中カッコと終了中カッコを含むコンテンツ全体を必ずコピーしてください。

    • 「共有プロバイダの詳細」で、「プロバイダ名」を入力し、オプションで「説明」を追加します。

    「次」をクリックして、「共有の追加」タブに進みます。
  3. ダイアログの「共有の追加」タブで、使用可能な共有のリストを表示します。「使用可能な共有」から消費する共有をクリックし、使用可能なオプションのいずれかを選択します。subscribe-share-provider-version-addshares.pngの説明が続きます
    図subscribe-share-provider-version-addshares.pngの説明
    • >: このオプションを使用すると、「使用可能な共有」を「選択した共有」に移動できます。
    • <: 選択した共有を「選択した共有」から削除するには、このオプションを選択します。
    • >>: このオプションを使用すると、すべてのシェアを「選択された共有」に移動します。
    • <<: 選択した共有を「選択した共有」からすべて削除するには、このオプションを選択します。
  4. 「サブスクライブ」をクリックして、共有を追加します。プロバイダが正常に作成されると、確認プロンプトが表示されます。プロバイダが正常に作成されると、「データ・ロード」ページの「クラウド・オブジェクトのリンク」画面が表示されます。

  5. 「クラウド・ストレージの場所」フィールドにプロバイダの名前を表示できます。共有は、共有に追加したファイルとともにソース・ファイルの場所に表示されます。link-cloud-object.pngの説明が続きます
    図link-cloud-object.pngの説明

    「共有」フォルダ・カートを展開し、共有するファイルをソースからデータ・リンク・カートにドラッグ・アンド・ドロップします。

    データ・リンク・カートで「開始」を選択して、データ・リンク・ジョブを実行します。

  6. データベース・アクションから作成された表を表示します。
    • ブレッドクラムの「データベース・アクション」をクリックして、データベース・アクションの起動パッドに戻ります。
    • 「SQL」タイルをクリックします。
    • 外部表を選択し、ワークシートにドラッグ・アンド・ドロップします。

      表のSQL Select文が表示されます。このSQL文を実行して、共有データを消費できます。

      xt_sql.pngの説明が続きます
      図xt_sql.pngの説明

バージョン管理された共有のファイル・レベルの変更データ・フィード・アクセスの有効化

Autonomous AI Databaseでは、データが一連の異なるバージョンとして公開されるバージョン管理された共有がサポートされています。公開される各バージョンは、Parquetファイルの特定のセットを参照します。

ファイル・レベルの変更データ・フィードの仕組み

変更データ・フィードを使用すると、コンシューマは、毎回最新のフル・スナップショットを読み取るのではなく、2つの公開済バージョン間で変更されたファイルのみを処理できます。

たとえば、プロバイダは1 TB共有をバージョン3として公開し、データを変更してバージョン4を公開します。1 TBのスナップショット全体を再度読み取るかわりに、コンシューマはバージョン3と4の差異をリクエストし、返された増分ファイルのみを処理できます。

この機能を使用するには、バージョンベースのアクセスを有効にします。

バージョンベース・アクセスの有効化

バージョン管理されたシェアの履歴バージョンおよびファイルレベルの変更にアクセスできるようにするには、受信者とシェアの両方のバージョンアクセスを構成します。

  • VERSION_ACCESS_CURRENTでは、現在のバージョンのみにアクセスできます。

  • VERSION_ACCESS_ANYでは、現在のバージョンおよび廃止されたバージョンにアクセスできます。

次のPL/SQLの例を使用します。

BEGIN
  DBMS_SHARE.UPDATE_RECIPIENT_PROPERTY(
    recipient_name     => 'my_recipient',
    recipient_property => DBMS_SHARE.PROP_RECIPIENT_VERSION_ACCESS,
    new_value          => DBMS_SHARE.VERSION_ACCESS_ANY);

  DBMS_SHARE.UPDATE_SHARE_PROPERTY(
    share_name     => 'my_versioned_share',
    share_property => DBMS_SHARE.PROP_SHARE_VERSION_ACCESS,
    new_value      => DBMS_SHARE.VERSION_ACCESS_ANY);
END;
/

ノート:

バージョンベース・アクセスを有効にするには、両方のプロパティを更新する必要があります。

デルタ共有REST APIを使用した変更データのリクエスト

デルタ共有変更エンドポイントを使用して、表の変更データをリクエストします。

リクエストの例:

GET {prefix}/shares/my_share/schemas/my_schema/tables/my_table/changes?startingVersion=3&endingVersion=4
Authorization: Bearer <token>

レスポンスは改行区切りのJSONで、リクエストされたバージョン範囲のプロトコル、メタデータおよび変更ファイル・アクション・オブジェクトが含まれます。

レスポンス・フラグメントの例:

{"protocol":{"minReaderVersion":1}}
{"metaData":{"format":{"provider":"parquet"}}}
{"add":{"url":"https://.../part-0001.snappy.parquet","id":"file-a","size":573,"version":4}}
{"remove":{"url":"https://.../part-0000.snappy.parquet","id":"file-c","size":573,"version":4}}

これにより、コンシューマは、要求されたバージョン範囲で返されたファイルのみを処理できます。

バージョン範囲の変更されたファイルを読み取り、行数をレポートするOracle固有のDatabricksの例は、Oracle Delta Sharing CDFを参照してください。

ライブ共有の消費

データ共有を通じて共有されるライブ・データは、自動的には消費で使用できるようになりません。

ライブのデータ共有を消費するには、そのデータ共有をサブスクライブし、ライブ共有に含まれる表のビューを作成します。ビューは、SQLスクリプトを使用して問い合せることができます。

  1. 「共有の消費」ページを開き、「+ 共有プロバイダへのサブスクライブ」をクリックして、ドロップダウンから「ライブ共有プロバイダへのサブスクライブ」を選択します。これにより、共有プロバイダへのサブスクライブダイアログ・ボックスが開きます。
  2. 「共有プロバイダへのサブスクライブ」ダイアログ・ボックスの「プロバイダ設定」ペインで、次の詳細を指定します。subscribe-live-share-provider.pngの説明が続きます
    図subscribe-live-share-provider.pngの説明

    「ソースの共有」セクションで、「ライブ共有プロバイダからの選択」を選択し、ドロップダウンからプロバイダ選択します。

    「共有プロバイダの詳細」フィールドに、次のように入力します:
    • プロバイダ名: プロバイダ名を指定します。
    • 説明: プロバイダの説明を入力します。

    「次」をクリックして、「共有の追加」タブに進みます。

  3. ダイアログの「共有の追加」タブで、使用可能な共有のリストを表示します。「使用可能な共有」から消費するシェアをクリックし、使用可能なオプションのいずれかを選択します。add-shares.pngの説明が続きます
    図add-shares.pngの説明
    • >: このオプションを使用すると、「使用可能な共有」を「選択した共有」に移動できます。
    • <: 選択した共有を「選択した共有」から削除するには、このオプションを選択します。
    • >>: このオプションを使用すると、すべてのシェアを「選択された共有」に移動します。
    • <<: 選択した共有を「選択した共有」からすべて削除するには、このオプションを選択します。

    「サブスクライブ」をクリックして、共有を追加します。プロバイダが正常に作成されると、確認プロンプトが表示されます。プロバイダが正常に作成されると、「データ・ロード」ページの「クラウド・オブジェクトのリンク」画面が表示されます。

  4. 「クラウド・ストレージの場所」フィールドに共有プロバイダの名前を表示できます。共有は、共有に追加したファイルとともにソース・ファイルの場所に表示されます。link-cloud-object.pngの説明が続きます
    図link-cloud-object.pngの説明

    「共有」フォルダ・カートを展開し、共有するファイルをソースからデータ・リンク・カートにドラッグ・アンド・ドロップします。

    データ・リンク・カートで「開始」を選択して、データ・リンク・ジョブを実行します。

共有プロバイダ・エンティティ詳細の表示

共有プロバイダ・エンティティの詳細を表示するには、共有プロバイダ・エンティティ・エントリの右側にある「アクション」アイコンをクリックし、「詳細の表示」をクリックします。

すべてのエンティティについて、詳細には「系統」セクションと「影響」セクションが含まれます。

特定の共有プロバイダ・エンティティについては、「アクション」コンテキスト・メニューを使用して次のアクションを実行できます。

  • 詳細の表示: 共有プロバイダ・エンティティ詳細の表示を参照してください。
  • 共有の管理: 共有プロバイダの共有の管理ダイアログ・ボックスが開きます。受信者と共有するために選択した共有がリストされます。受信者と共有する共有のリストを編集できます。「OK」をクリックして変更を保存するか、「取消」を選択して編集処理を破棄します。
  • 表へのロード:「共有」タブが選択された状態で「データのロード」ページが表示されます。
  • 表へのリンク:「共有」タブが選択された状態で「データのリンク」ページに移動し、関連するリンク・オブジェクトを表示および実行します。共有データをドラッグ・アンド・ドロップして、データ・リンク・ジョブに追加します。
  • 名前の変更: プロバイダ名を変更します。「はい」を選択して変更するか、「いいえ」をクリックします。
  • エンドポイントのコピー: エンドポイントをコピーします。
  • 削除: 共有プロバイダ・エンティティを削除します。

削除ベクトルを使用したデータブリック表の共有

Autonomous AI Databaseがデルタ共有コンシューマの場合に、Databricks Delta Tablesを共有する方法について説明します。

Autonomous AI Databaseでは、削除ベクトルを含むDatabricks Delta表はサポートされません。共有デルタ表で削除ベクトルが使用されている場合、Autonomous AI Databaseは表の作成中に次のエラーを返します。
ORA-29913: error while processing ODCIEXTTABLEFETCH routine

データブリック・プロバイダは、Autonomous AI Databaseがデルタ共有コンシューマの場合、次のシナリオでデルタ表を共有できます:

  • シナリオ1 - 表からの削除ベクトルの削除

  • シナリオ2 - ビューを作成し、ビューを共有する

  • シナリオ3 - 将来の表のワークスペース設定での削除ベクトルの無効化

シナリオ1 - 表からの削除ベクトルの削除

特定の表に対するdeletionVectorsの使用を停止する準備ができている場合は、これを使用します。

  1. これをDatabricksで実行します。

    ALTER TABLE table_name 
    DROP FEATURE deletionVectors
  2. table_nameをDelta共有に追加し、Autonomous AI Databaseをコンシューマとして構成します。

このオプションは、保留中の削除をすべて適用し、表からdeletionVectors機能を削除します。表は、deletionVectorsのない通常のDelta表のように動作します。

メリット:
  • ビューの実現に継続的なコストはかかりません。

  • Autonomous AI Databaseでのシンプルな実装。

短所:
  • 大きな表に対する1回かぎりのリライト。

  • Autonomous AI Databaseだけでなく、この表を読み取るすべてのワークロードに影響します。

  • この表での今後の削除に対する削除ベクトルの利点が失われます。

シナリオ2 - ビューの作成およびビューの共有

これは、実表にdeletionVectorsを保持する場合に使用します。

  1. これをDatabricksで実行します。

    CREATE VIEW view_name AS 
    SELECT * FROM table_name;
  2. ビューview_nameを表ではなくDelta共有に追加します。

    Autonomous AI Databaseコンシューマは、次の問合せを実行できます:

    SELECT * 
    FROM "MY_SHARE"."MY_SCHEMA"."view_name";

このシナリオでは、Databricks実表は削除ベクトルを引き続き使用します。Databricksは、ビューの実行時に削除ベクトルを解決するため、Autonomous AI Databaseではそれらが表示されません。Autonomous AI DatabaseなどのDatabricks以外の受信者の場合、Databricksはビューを実体化し、プロバイダにコンピュートおよびストレージの料金を請求する場合があります。プロバイダは、DatabricksでマテリアライズTTLを構成して、コストとデータのリフレッシュ、新しいデータのTTLの短縮または低減、またはコスト効率に優れたTTLの延長または高度のバランスを制御できます。

メリット:
  • 実表に変更はありません。

  • 他のDatabricksワークロードでは、削除ベクトルを引き続き使用できます。

  • フィルタ、マスキングまたは列の投影をビューに追加できます。

短所:
  • プロバイダは、Databricksのビューの実体化および格納のコストを負担します。

  • コスト管理とデータの鮮度に関するTTL設定の管理

  • テーブルを共有するよりも複雑です。

シナリオ3 - 将来の表のワークスペース設定での削除ベクトルの無効化

これを使用して、新規表がデフォルトで削除ベクトルを使用しないようにします。

  1. 「ワークスペース設定」または管理コンソールをDatabricksの管理ユーザーとして開き、「詳細」に移動します。

  2. 「削除ベクトルを自動有効化」を見つけて、「無効」に設定します。

  3. 変更を保存して、実行中のコンピュートを再起動します。

オプションで、特定の表に対してこれを実行します。
ALTER TABLE table_name 
SET TBLPROPERTIES ('delta.enableDeletionVectors' = FALSE);

このシナリオでは、この変更後に作成されたすべての新しい表では、デフォルトで削除ベクトルは有効になりません。ただし、削除ベクトルをすでに使用している既存の表では、前述したシナリオが必要になります。

メリット:
  • 新しい表で削除ベクトルが自動的に使用されないようにします。

  • Autonomous AI Databaseと共有される将来の表の追加メンテナンスはありません。

短所:
  • 削除ベクトルをすでに使用している既存のテーブルは修正されません。

  • ワークスペース全体の設定のメンテナンス。一部の内部ワークロードでは、デフォルトで削除ベクトルが使用される場合があります。

Databricksで削除ベクトルが有効かどうかの確認

Databricksの特定の表で削除ベクトルが有効かどうかを確認するには、次のコマンドを実行します:

SHOW TBLPROPERTIES table_name ('delta.enableDeletionVectors');