リーダーアカウントの構成¶

タスク1: アカウント管理者としてリーダーアカウントにログインする¶

Log into the reader account using any of the supported interfaces (such as Snowflake CLI, SnowSQL, or the web interface).

The instructions in this topic assume you are using SQL to perform these tasks, either in Snowflake CLI, SnowSQL, or using a worksheet (in the web interface ). However, the tasks can be performed in any supported Snowflake interface.

タスク2: カスタムロールを作成する（オプション）¶

ロールにより、リーダーアカウントのユーザーが実行できるタスクをきめ細かく制御できます。ロールを使用して次のことができます。

• アカウントと共有するデータをクエリできるユーザーの指定。

• 選択したユーザーによる仮想ウェアハウスの制御の許可。

• 選択したユーザーによる管理者のタスクと責任の委任（必要な場合）。

各リーダーアカウントには、標準のシステム定義のロール（SYSADMIN、 SECURITYADMIN、 PUBLIC）が付与されています。これらの役割がアカウントで作成するユーザーのアクセス要件を満たさない場合、追加のカスタム役割を作成できます。

詳細については、 アクセス制御の概要 をご参照ください。

タスク3: ユーザーを作成する¶

リーダーアカウントにログインし、アカウントと共有するデータをクエリするユーザーを作成し、許可するように選択した他のタスクを実行します。

ユーザー作成プロセスの一環として、システム定義またはカスタム（作成した場合）のロールをユーザーに付与することを忘れないでください。ユーザーに割り当てる役割によって、アカウントで何ができるかが決まります。

詳細については、 CREATE USER および GRANT ROLE をご参照ください。

タスク4: リソースモニターを作成する（オプション）¶

リーダーアカウントと共有するデータをクエリするには、仮想ウェアハウスが必要です。実行中、仮想ウェアハウスはクレジットを消費し、プロバイダーアカウントに請求されます。

リーダーアカウントの仮想ウェアハウスで毎月消費されるクレジットの量を制御したい場合は、1つ以上のリソースモニターを作成し、それらが制御するかどうかを指定します。

• アカウント内のすべてのウェアハウス。

• 個々のウェアハウス。

詳細については、 CREATE RESOURCE MONITOR をご参照ください。

タスク5: 仮想ウェアハウスを作成する¶

共有データベース内のオブジェクトのクエリを有効にするには、少なくとも1つの仮想ウェアハウスを作成する必要があります。好きなだけ、または必要なだけウェアハウスを作成できます。ただし、リーダーアカウントのウェアハウスで消費されるすべてのクレジットについては、プロバイダーアカウントが責任を負う必要があることを念頭に、次の点を考慮します。

• ウェアハウスのサイズを適切に設定して、目的のクエリパフォーマンスを目的のクレジット消費量と比較します。

• ウェアハウスが使用されていないときは自動サスペンドに設定されていることを確認してください。

詳細については、 CREATE WAREHOUSE をご参照ください。

タスク6: アカウントと共有される各共有からデータベースを作成する¶

リーダーアカウントには、デフォルトではデータが含まれていません。プロバイダーアカウントから共有されたデータを使用するには、 CREATE DATABASE コマンドを使用して、アカウントと共有されている各共有からデータベースを作成する必要があります。データベースを作成する際に、リーダーアカウントの他のユーザーが共有データをクエリするときに参照する名前を指定します。

たとえば、プロバイダーアカウントの名前が ab12345 で、このリーダーアカウントにおいて share1 および share2 という名前の2つの共有を共有した場合、

CREATE DATABASE shared_db1 FROM SHARE ab12345.share1;

CREATE DATABASE shared_db2 FROM SHARE ab12345.share2;

Copy

タスク7: 仮想ウェアハウスおよびデータベースに対する権限をロールに付与する¶

データプロバイダーは、データベースロールを介してオブジェクトに対する権限を共有に付与してから、データベースロールを共有に付与する（オプション1）か、 あるいは オブジェクトに対する権限を共有に直接付与する（オプション2）かの いずれか により、オブジェクトを共有に追加することを選択できます。このセクションの手順は、データベースプロバイダーが選択したオプションによって異なります。

オプション1:

リーダーアカウントと共有されているデータのクエリを有効にするには、アカウント内の適切なロールを使用して、アカウント内のビジネス機能と連携する共有内のデータベースロールを付与します。たとえば、アカウント内のすべてのユーザーと共有する shared_db1.dr1 という名前のデータベースロールが共有に含まれているとします。この場合は、データベースロールを PUBLIC システムロールに付与します。

GRANT DATABASE ROLE shared_db1.dr1 TO ROLE PUBLIC;

Copy

オプション2:

リーダーアカウントと共有されるデータのクエリを有効にするには、アカウント内のシステム定義またはカスタム（存在する場合）の他のロールに、次の権限を付与します。

• タスク6: アカウントと共有される各共有からデータベースを作成する の共有から作成された各データベースに対する IMPORTED PRIVILEGES （このトピック内）。

たとえば、次のコマンドは、 shared_db1 と shared_db2 という名前の2つのデータベースと testing_vw という名前のウェアハウスに必要な権限を PUBLIC ロールに付与します。アカウント内のすべてのユーザーは自動的に PUBLIC ロールを持っているため、アカウント内のすべてのユーザーがウェアハウスを使用してデータベースをクエリできます。

GRANT IMPORTED PRIVILEGES ON DATABASE shared_db1 TO ROLE PUBLIC;

GRANT IMPORTED PRIVILEGES ON DATABASE shared_db2 TO ROLE PUBLIC;

Copy

さらに、クエリを実行するために作成した仮想ウェアハウスに対する USAGE 権限を付与します。

GRANT USAGE ON WAREHOUSE testing_vw TO ROLE PUBLIC;

必要に応じて、追加の権限を付与できます。ただし、上記の権限は、アカウント内の共有データベースをクエリするために必要な 最小 権限です。

また、 testing_vw ウェアハウスに対する完全な権限を SYSADMIN ロールに付与して、ロールを持つユーザーによるウェアハウスの開始、停止、およびサイズ変更を有効にすることもできます。

GRANT ALL ON WAREHOUSE testing_vs TO ROLE SYSADMIN;

詳細については、 GRANT <権限> ... TO ROLE をご参照ください。

タスク8: ユーザーをログインに招待してパスワードをリセットする¶

最後の構成タスクとして、作成したすべてのユーザーに、アカウントが使用可能であることを通知します。

これを行うための最速/最も簡単な方法は、 ALTER USER コマンドを使用して各ユーザーのパスワードをリセットすることです。これにより、ユーザーごとに一意の URL が生成され、ユーザーに送信/付与されます。URL を使用してパスワードを変更し、アカウントにログインします。

例:

ALTER USER ra_user1 RESET PASSWORD;

ALTER USER ra_user2 RESET PASSWORD;

Copy