共有の操作

このトピックでは、データプロバイダーのアカウント作成と共有の構成、他の(つまり、コンシューマー)アカウントとの共有の共有、および共有の継続的なメンテナンスの実行に関連するタスクについて説明します。

これらのタスクを実行するには、 ACCOUNTADMIN ロール(またはCREATE SHARES グローバル権限が付与されたロール)を使用する必要があります。CREATE SHARES 権限の詳細については、 ACCOUNTADMIN 以外のロールによる、データ共有タスクの実行の有効化 をご参照ください。

このルールの1つの例外は、共有するオブジェクト(データベース、テーブルなど)の準備です。これは、任意のロールを使用して実行できます。

このトピックの内容:

データ共有とBusiness Criticalアカウント

Business Criticalアカウントをお持ちの場合、他の(つまり、コンシューマー)アカウントとデータを共有するための次の条件に注意します。

プロバイダー

コンシューマー

サポート対象

有効化

メモ

Business Critical ( HIPAAを使用)

から

Business Critical ( HIPAAを使用)

HIPAA アカウントの両方で、相互に署名済みの BAA が必要です。

Business Critical ( HIPAAを使用)

から

他のすべてのエディション

Snowflakeでは、他のアカウントがBusiness Criticalアカウントであっても、 HIPAA アカウントが HIPAA 以外のアカウントとデータを共有することを許可していません。

Business Critical

から

Business CriticalまたはBusiness Critical ( HIPAAを使用)

Business Critical

から

他のすべてのエディション

アカウントを有効にするには、Snowflakeにお問い合わせください。

他のすべてのSnowflakeエディションの場合:

  • VPS (Virtual Private Snowflake)は、地域間でのデータ共有に対する現在の制限により、Secure Data Sharingをサポートしていません。

  • StandardおよびEnterprise Editionは、通常の注意事項を伴う安全なデータ共有をサポートしています。

詳細については、 一般的なデータ共有の考慮事項と使用法 (このトピック内)をご参照ください。

注意

Snowflakeでは、データ共有に携わっている HIPAA アカウントが相互に BAA に署名していることを保証する責任を負いません。これは、データを共有しているアカウントの裁量です。署名済みの BAA がないと、両方のアカウント、 特に プロバイダーアカウントの HIPAA コンプライアンスに影響する可能性があります。

また、Business Criticalアカウントをお持ちの場合、Business Criticalが提供するデータ保護の期待レベルを維持するため、Snowflakeに非Business Criticalアカウントの安全なデータ共有を要求する前に、次の点を考慮するよう 強く お勧めします。

  • 機密データを非Business Criticalアカウントと共有しないでください。

  • 2つ目の非Business Criticalアカウントを作成して、機密性の低いデータを保存し、このデータを非Business Criticalアカウントと共有することを検討します。

  • Business CriticalアカウントでTri-Secret Secureを使用しており、他のアカウントとデータを共有している場合、Snowflakeは、これらのアカウントからのデータアクセスを自分のアカウント内から発生したかのように扱います。具体的には、コンシューマーアカウントへのアクセスを許可するには、Snowflakeが AWS KMSにアクセスする必要がある場合があります。

これらは推奨事項にすぎず、Snowflakeによって強制されるものではありません。データを共有する決定は常にデータプロバイダーの裁量で行われ、Snowflakeは不適切に共有されたデータについて一切責任を負いません。

共有のウェブインターフェイス

ACCOUNTADMIN ロール(または CREATE SHARES 権限が付与されたロール)がある場合、Snowflakeのウェブインターフェイスの Shares Shares tab ページを使用して、共有の作成と管理に関連するほとんどのタスクを実行できます。

Shares page in Snowflake web interface

実行できるタスクは、共有が OutboundInbound かによって異なります。

アウトバウンド共有(プロバイダー)

アウトバウンド共有は、コンシューマーアカウントとデータを共有する目的でアカウントによって作成されます。ウェブインターフェイスでは、アウトバウンド共有に対して次のタスクを実行できます。

  • 作成した共有、またはアクセスする権限がある共有の表示。提供される情報には、共有のデータベースと、共有に追加されたコンシューマーアカウント(存在する場合)が含まれます。

  • 共有の作成。

  • コンシューマーアカウントの共有への追加。アカウントを追加するときに、フルアカウントまたはリーダーアカウントの追加を選択できます。また、その場でリーダーアカウントを作成し、共有に追加することもできます。

  • 以下を含む共有を編集します。

    • 共有内のオブジェクトの表示。

    • テーブルまたは安全なビューを共有に追加、または共有から削除します。

      注釈

      ウェブインターフェイスは現在、外部テーブル、安全なマテリアライズドビュー、安全な UDFs を共有に追加、または共有から削除することをサポートしていません。共有内のオブジェクトの管理すべては、 SQL を使用して実行する必要があります。

      重要

      異なる 地域 または クラウドプラットフォーム のデータコンシューマーとデータを安全に共有することを計画するときは、現在、1つ以上の外部テーブルがデータベースに存在する場合、プライマリデータベースの複製がブロックされることに注意してください。

    • 個々のコンシューマーアカウントによる共有へのアクセスの取り消し。

  • 共有をドロップします。これにより、共有用にコンシューマーによって作成されたすべてのデータベースが直ちに無効になります。

インバウンド共有(コンシューマー)

インバウンド共有は、プロバイダーアカウントによってアカウントと共有されます。ウェブインターフェイスでは、インバウンド共有に対して次のタスクを実行できます。

  • プロバイダーからのすべての共有の表示(共有の提供者、アカウントでデータベースが作成されたかどうかなど)。

  • 共有からのデータベースの作成。

共有用のデータベースが作成されると、データベースで実行する他のすべてのタスク(データベースのドロップなど)は Databases Databases tab ページから実行されます。

共有用 DDL

共有の作成と管理をサポートするために、Snowflakeは次の一連の特別な DDL コマンドを提供します。

さらに、プロバイダーは、次の標準アクセス制御 DDLを使用して、共有内のデータベースオブジェクトへのアクセスを表示、許可、または取り消すことができます。

一般的なデータ共有に関する考慮事項と使用法

共有を作成および維持するための以下の重要な使用法の詳細に注意します。

  • 地域とクラウドプラットフォーム間でデータを共有します。詳細については、 地域とクラウドプラットフォーム間で安全にデータを共有する をご参照ください。

  • 共有には、複数のデータベースからのデータを含めることができます。詳細については、 複数のデータベースのデータの共有 をご参照ください。

  • データセキュリティとプライバシーの理由から、現時点では、共有では セキュアビュー のみがサポートされています。標準ビューが共有に追加されると、Snowflakeはエラーを返します。

  • アカウントを共有に追加すると、共有はすぐにアカウントで使用できるようになります。

  • 共有内のテーブル(または共有内のビューによって参照されるテーブル)の新しい行と変更された行は、共有からデータベースを作成したすべてのコンシューマーがすぐに利用できます。これらのテーブルを更新するときは、この点に留意します。

  • 共有内のデータベースで作成された新しいオブジェクトは、コンシューマーが自動的に利用することはでき ません

    オブジェクトをコンシューマーが利用できるようにするには、 GRANT <privilege> ...TO SHARE コマンドを使用して、オブジェクトを共有に明示的に追加する必要があります。

    注釈

    これは、データベースからドロップされ、データベース内で同じ名前で再作成されたオブジェクトにも適用されます。再作成されたオブジェクトは新しいオブジェクトとして扱われるため、共有に必要な権限がオブジェクトに明示的に付与されるまではアクセスできません。

共有を作成する準備

共有を作成する前に、共有する予定のSnowflakeオブジェクトを特定することをお勧めします。

  • データベース

  • テーブル

  • 外部テーブル

  • 安全なビュー

  • 安全なマテリアライズドビュー

  • 安全な UDFs

これにより、特にテーブルのデータのサブセットのみを共有することにした場合、追加の計画および管理タスクが必要になる可能性があります。

データベースとテーブル

データベースを共有するための準備はほとんど必要ありません。同様に、データベース内のテーブル全体を共有することを選択した場合の準備は不要です。

ただし、特定の条件に基づいて、またはコンシューマーアカウントによって、テーブル(またはテーブルのセット)のデータをフィルター処理する場合、1つ以上のセキュリティでセキュアビューをテーブルに作成する必要があります。

データコンシューマーが共有テーブルにテーブルストリームを作成できるようにする

注釈

共有テーブルでのテーブルストリームのサポートは、 プレビュー機能 として提供されます。

データコンシューマーが共有テーブルにストリームを作成するには、テーブルで変更の追跡を有効にする必要があります。さらに、テーブルのデータ保持期間を延長する必要があります。

変更の追跡を有効にする

現在、ローカルテーブルの最初のストリームが作成されると、非表示の列のペアがテーブルに自動的に追加され、変更追跡メタデータの保存が開始されます。共有のコンシューマーはソースデータベースを変更できないため、この変更は共有テーブルでは不可能です。代わりに、共有を目的としたテーブルの変更の追跡を有効にするには、各テーブルで ALTER TABLE ... CHANGE_TRACKING = TRUE を実行します。

テーブルのデータ保持期間を延長する

ローカルテーブルのストリームが定期的に消費されない場合、Snowflakeは古さを回避するために、ソーステーブルのデータ保持期間を一時的に延長します。テーブルのデータ保持期間が14日未満の場合、アカウントの Snowflakeエディション に関係なく、期間はストリームトランザクションオフセット より短く 、または14日(テーブルのデータ保持期間が14日未満の場合)に、バックグラウンドで延長されます。ストリームが消費されると、データ保持期間の延長はテーブルのデフォルト期間に短縮されます。

共有テーブルのストリームは、テーブルのデータ保持期間を延長しません。共有テーブルに対してより長いデータ保持期間を手動で指定するには、 DATA_RETENTION_TIME_IN_DAYS パラメーターを設定します。

CHANGE_TRACKING および DATA_RETENTION_TIME_IN_DAYS パラメータは、テーブルを作成するときに( CREATE TABLE を使用して)または後で( ALTER TABLE を使用して)設定できます。

セキュアオブジェクト(ビュー、セキュアマテリアライズドビュー、 UDFs )

共有データベース内のデータへのアクセスを厳密に制御するには、 セキュアビューセキュアマテリアライズドビュー および/または セキュア UDFs を使用することをお勧めします。例えば、日付やその他の条件でデータをフィルタリングすることを選択したり、単一の共有を使用して異なるコンシューマーアカウントの共有データを分割したりできます。セキュアオブジェクトを使用すると、ベーステーブルとビジネスロジックが公開されないようにしながら、データに適用する細分性のレベルを指定できます。

セキュアオブジェクトは、対応する CREATE <オブジェクト> または ALTER <オブジェクト> コマンドを使用して、標準オブジェクトと同様に定義されます。ただし、次の重要な使用情報に注意します。

  • 完全修飾名(つまり、 <データベース名>.<スキーマ名>.<テーブル名> )でテーブルを参照する安全なオブジェクトは、共有に含めることができます。ただし、参照されるデータベース名が共有のデータベースと 一致 することを確認する必要があります。

  • 定義に CURRENT_USER または CURRENT_ROLE 関数を使用するセキュアオブジェクトを含め ない でください。これらの関数によって返されるコンテキスト値は、コンシューマーのアカウントに関連性がなく、クエリ/使用時にオブジェクトが失敗します。

  • 安全なオブジェクトを定義してコンシューマーアカウントと共有する場合、実行する重要な追加のステップは、表示するデータのみを表示するようにオブジェクトが正しく構成されていることを検証することです。これは、データが共有されるアカウントに基づいてデータアクセスを制限する場合に特に重要です。

    この検証の実行を容易にするために、Snowflakeは、 SIMULATED_DATA_SHARING_CONSUMER セッションパラメーターを提供します。

    現時点では、 SIMULATED_DATA_SHARING_CONSUMER セッションパラメーターは、セキュアビューとセキュアマテリアライズドビューのみをサポートしており、セキュア UDFs はサポートしていません。セッションでこのパラメーターを設定すると、ビューを共有する予定のコンシューマアカウントのいずれかのユーザーとして、セキュアビューのクエリをシミュレートできます。

    たとえば、 xy12345 という名前のコンシューマアカウントの場合は、

    ALTER SESSION SET SIMULATED_DATA_SHARING_CONSUMER = xy12345;
    

詳細な例については、 セキュアオブジェクトを使用したデータアクセスの制御 をご参照ください。

SQLを使用した共有の作成

SQLを使用して共有を作成するには、

  1. CREATE SHARE コマンドを使用して、空の共有を作成します。

  2. GRANT <privilege> ...TO SHARE コマンドを使用してデータベースを共有に追加し、特定のデータベースオブジェクト(スキーマ、テーブル、およびセキュアビュー)へのアクセスを共有に選択的に許可します。

  3. ALTER SHARE コマンドを使用して、共有への1つ以上のアカウントアクセスを追加します。

注釈

次の手順では、 prvdr1 という名前のプロバイダーアカウントが、 xy12345 および yz23456 という名前の2つのコンシューマアカウントとデータを共有していることを前提としています。

ステップ1:空の共有を作成する

次の例では、 sales_s という名前の空の共有を作成します。

CREATE SHARE sales_s;

ステップ2:共有にデータベースおよびオブジェクトへの権限を付与する

共有にオブジェクトを含めるには、各オブジェクトに権限を付与します。権限を付与する場合、コンテナーオブジェクトの使用を許可する前に、まずコンテナー内のオブジェクトの使用を許可します。たとえば、データベースに含まれるスキーマの使用を許可する前に、データベースの使用を許可します。

注釈

アカウントを共有に追加する前に、このタスクを実行します。データベースの使用を許可する前にアカウントを追加しようとすると、エラーが発生します。

次の例は、前の手順で作成した sales_s 共有に次のオブジェクトの権限を付与する方法を示しています。

  • sales_db (データベース)

  • aggregates_eula (スキーマ)

  • aggregate_1 (テーブル)

GRANT USAGE ON DATABASE sales_db TO SHARE sales_s;

GRANT USAGE ON SCHEMA sales_db.aggregates_eula TO SHARE sales_s;

GRANT SELECT ON TABLE sales_db.aggregates_eula.aggregate_1 TO SHARE sales_s;

共有の内容を確認するには、

SHOW GRANTS TO SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

これにより、共有が他のアカウントで使用できるようになる前に、共有が正しく構成されます。

ステップ3:アカウントを共有に追加する

注意

Business Criticalアカウントを所有しており、消費者アカウントとデータを共有している場合:

  • Snowflakeは、非Business Criticalアカウントとの機密データの共有をサポートしています(デフォルトでは無効)が、そうすることを推奨 しません

  • HIPAA 要件への準拠を確保するために、Snowflakeは、 HIPAA アカウントが非 HIPAA アカウントとデータを共有することを許可 しません

  • Tri-Secret Secureデータ保護を使用している場合、Snowflakeは、ユーザーアカウントからのデータアクセスを自分のアカウント内から発生したかのように扱います。

これらの推奨事項と制限の詳細については、 データ共有とBusiness Criticalアカウント をご参照ください。

次の例では、2つのアカウントを sales_s 共有に追加します。

ALTER SHARE sales_s ADD ACCOUNTS=xy12345, yz23456;

アカウント xy12345 および yz23456 は共有を表示し、そこからデータベースを作成できるようになりました。

注釈

アカウントを共有に追加するときに、アカウントが存在しない場合、コマンドは正常に完了しますが、共有は更新されません。共有が適切に更新されるようにするには、アカウントが存在し、名前を正しく入力したことを確認します。

SHOW SHARES を使用して共有を確認します。コマンドの出力には、 sales_s 共有がリストされます。 kind 列は、共有が OUTBOUNDであることを示します。これは、この共有が他のSnowflakeアカウントとデータベースを共有していることを意味します。 to 列には、共有が使用可能になったすべてのアカウントがリストされます。

SHOW SHARES;

+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+
| created_on                    | kind     | name                    | database_name         | to               | owner        | comment                                |
|-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------|
| 2016-07-09 19:18:09.821 -0700 | INBOUND  | SFC_SAMPLES.SAMPLE_DATA | SNOWFLAKE_SAMPLE_DATA |                  |              | Sample data sets provided by Snowflake |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S          | SALES_DB              | XY12345, YZ23456 | ACCOUNTADMIN |                                        |
+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+

SQL を使用した共有の維持

共有からデータベースを作成したコンシューマーの表示

共有からデータベースを作成したアカウントを表示するには、 SHOW GRANTS OF SHARE コマンドを使用します。これは、 SHOW SHARESによって返されるアカウントのリストとは異なります。

  • SHOW SHARES アカウントで使用可能なすべての共有と、各共有にアクセスできるアカウントを一覧表示します。

  • SHOW GRANTS OF SHARE 共有からデータベースを作成したすべてのアカウントをリストします。アカウントが共有からデータベースを作成していない場合、結果は空です。

たとえば、次の例に示します。

  • 2つの共有、 prvdr1.sales_s および prvdr1.sales_s2 がアカウント xy12345 および yz23456 で利用可能になりました。

  • アカウント xy12345 は、 prvdr1.sales_s 共有からデータベースを作成しました。

  • prvdr1.sales_s2 共有からデータベースを作成したアカウントはありません。

SHOW SHARES;

+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+
| created_on                    | kind     | name                    | database_name         | to               | owner        | comment                                |
|-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------|
| 2016-07-09 19:18:09.821 -0700 | INBOUND  | SFC_SAMPLES.SAMPLE_DATA | SNOWFLAKE_SAMPLE_DATA |                  |              | Sample data sets provided by Snowflake |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S          | SALES_DB              | XY12345, YZ23456 | ACCOUNTADMIN |                                        |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S2         | SALES_DB              | XY12345, YZ23456 | ACCOUNTADMIN |                                        |
+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+

SHOW GRANTS OF SHARE sales_s;

+-------------------------------+----------------+------------+----------+
| created_on                    | share          | granted_to | account  |
|-------------------------------+----------------+------------+----------|
| 2017-06-15 18:00:03.803 -0700 | PRVDR1.SALES_S | ACCOUNT    | XY12345  |
+-------------------------------+----------------+------------+----------+

SHOW GRANTS OF SHARE sales_s2;

+------------+-------+------------+---------+
| created_on | share | granted_to | account |
|------------+-------+------------+---------|
+------------+-------+------------+---------+

共有へのオブジェクトの追加

GRANT <privilege> ...TO SHARE コマンドを使用して、いつでも既存の共有にオブジェクトを追加できます。共有に追加したオブジェクトは、共有からデータベースを作成したコンシューマーアカウントですぐに利用できます。たとえば、共有にテーブルを追加すると、コンシューマーアカウントのユーザーは、テーブルが共有に追加されるとすぐにテーブル内のデータをクエリできます。

注釈

  • オブジェクトのスキーマが既に共有にある場合は、オブジェクトを追加するだけです。

  • オブジェクトのスキーマがまだ共有にない場合は、最初にスキーマを追加してからオブジェクトを追加する必要があります。

次の例では、 aggregates_eula スキーマの agg_secure という名前のセキュアビューを sales_s 共有に追加します。

SHOW GRANTS TO SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

GRANT SELECT ON VIEW sales_db.aggregates_eula.agg_secure TO SHARE sales_s;

SHOW GRANTS TO SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-17 12:33:15.310 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGG_SECURE  | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

共有からのオブジェクトの削除

REVOKE <privilege> ...FROM SHARE コマンドを使用して、既存の共有からいつでもオブジェクトを削除できます。共有から削除したオブジェクトは、共有からデータベースを作成したコンシューマーアカウントではすぐに使用できなくなります。たとえば、共有からテーブルを削除すると、コンシューマーアカウントのユーザーは、共有からテーブルが削除されるとすぐにテーブル内のデータをクエリできなくなります。

次の例では、 aggregates_eula スキーマの agg_secure という名前のセキュアビューを sales_s 共有から削除します。

SHOW GRANTS TO SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-17 12:33:15.310 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGG_SECURE  | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

REVOKE SELECT ON VIEW sales_db.aggregates_eula.agg_secure FROM SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

共有へのアカウントの追加

ALTER SHARE コマンドを使用して、いつでも既存の共有にアカウントを追加できます。アカウントが共有に追加されると、共有はすぐにアカウントに「表示」され、アカウントは共有からデータベースを作成し、データベース内のSnowflakeオブジェクトのクエリを開始できます。

共有からのアカウントの削除

ALTER SHARE コマンドを使用して、既存の共有からいつでもアカウントを削除できます。共有からアカウントを削除すると、共有から作成したデータベースが即座に無効になります。アカウントのユーザーがデータベースに対して実行するすべてのクエリ、およびその他の操作は機能しなくなります。

共有のアカウントの新しいリストを設定し、目的のアカウントをリストから外して、共有からアカウントを削除します。

共有からアカウントを削除した後、共有に再度追加できます。ただし、以前に共有から作成したデータベースは復元されません。共有から新しいデータベースを作成する必要があります。

注釈

共有からアカウントを削除する前に、アカウントの削除がアカウントに与えるダウンストリームの影響を考慮します。データベースは即座に無効になるため、ユーザー(アカウント内)がデータベースに対して実行するすべてのクエリやその他の操作は機能しなくなり、アカウントのビジネスオペレーションに大きな影響を与える可能性があります。

共有のドロップ

DROP SHARE コマンドを使用して、いつでも共有をドロップできます。共有をドロップすると、共有からコンシューマーアカウントによって作成されたすべてのデータベースが即座に無効になります。これらのデータベースで実行されるすべてのクエリおよびその他の操作は機能しなくなります。

共有をドロップした後、同じ名前で共有を再作成できます。ただし、これにより、コンシューマーアカウントによる共有から作成されたデータベースは復元されません。再作成された共有は新しい共有として扱われ、すべてのコンシューマーアカウントは新しい共有から新しいデータベースを作成する必要があります。

注釈

共有をドロップする前に、共有を使用するすべてのコンシューマーアカウントに与えるダウンストリームの影響を考慮します。

代わりに、共有から個々のオブジェクトを削除することも検討できます。削除されたオブジェクトは、コンシューマーアカウントの側で追加のタスクを必要とせずに共有に追加できます。