アカウントの使用

.

関連トピック

• Snowflakeでのデータの安全な共有

• クエリ

• クエリ構文

Snowflakeは、 SNOWFLAKEという名前の共有データベースを介して、アカウントのデータディクショナリオブジェクトメタデータと履歴使用データを提供します。

このトピックの内容：

SNOWFLAKE データベースとは何ですか？

SNOWFLAKE は、Snowflakeが提供するシステム定義の読み取り専用共有データベースです。データベースは、 ACCOUNT_USAGEという名前の共有から各アカウントに自動的にインポートされます。 SNOWFLAKE データベースは、 Secure Data Sharing を利用して、アカウントのオブジェクトメタデータおよびその他の使用メトリックを提供するSnowflakeの例です。

SNOWFLAKE データベースには2つのスキーマが含まれています（読み取り専用）。各スキーマにはビューのセットが含まれています。

ACCOUNT_USAGE

アカウントのオブジェクトメタデータと使用メトリックを表示するビュー。

一般的に、これらのビューはSnowflake 情報スキーマ の対応するビューとテーブル関数をミラーリングしますが、次の違いがあります。

• 各ビューに含まれる削除済みのオブジェクトの履歴。

• 履歴使用データの保持時間が長くなる。

• データの待機時間。

詳細については、このトピック内の アカウントの使用と情報スキーマの違い をご参照ください。各ビューの詳細については、このトピック内の ACCOUNT_USAGE ビュー をご参照ください。

READER_ACCOUNT_USAGE

（ Secure Data Sharing（セキュアデータ共有） プロバイダーとして）アカウント用に作成されたすべてのリーダーアカウントのオブジェクトメタデータと使用メトリックを表示するビュー。

これらのビューは、リーダーアカウントに適用される ACCOUNT_USAGE ビューの小さなサブセットです。ただし、 RESOURCE_MONITORS ビューは例外で、 READER_ACCOUNT_USAGE でのみ使用できます。また、このスキーマの各ビューには、リーダーアカウントで結果をフィルタリングするための追加の READER_ACCOUNT_NAME 列が含まれています。

各ビューの詳細については、 READER_ACCOUNT_USAGE ビュー （このトピック内）をご参照ください。

アカウントにリーダーアカウントが作成されていない場合、これらのビューは空になります。

スキーマ内のビューは、Snowflakeの他のビューと同様にクエリできます。

SNOWFLAKE データベースには、すべてのデータベースで自動的に作成される3番目のスキーマ INFORMATION_SCHEMAが含まれています。共有データベースでは、このスキーマは目的を果たさず、無視できます。

注釈

デフォルトでは、アカウント管理者（ACCOUNTADMINロールを持つユーザー）のみがデータベース内のSNOWFLAKEデータベースとスキーマにアクセスしたり、ビューでクエリを実行したりできます。ただし、データベース上の権限をアカウント内の他のロールに付与して、他のユーザーがオブジェクトにアクセスできるようにすることはできます。詳細については、 他のロールのアカウント使用を有効にする （このトピック内）をご参照ください。

Account UsageとInformation Schemaの違い

情報スキーマのアカウント使用ビューと対応するビュー（またはテーブル関数）は、このセクションで説明するように、同一の構造と命名規則を使用しますが、このセクションに記載されるように、いくつかの重要な違いがあります。

差	アカウント の使用	情報 スキーマ
ドロップされたオブジェクトを含む	はい	いいえ
データの待機時間	45分～3時間（ビューに応じて異なる）	なし
履歴データの保持	1年	7日～6か月（ビュー/テーブル関数に応じて異なる）

詳細については、次のセクションをご参照ください。

削除されたオブジェクトレコード

アカウント使用状況ビューには、削除されたすべてのオブジェクトの履歴が含まれます。追加の DELETED 列には、オブジェクトが削除されたときのタイムスタンプが表示されます。

さらに、オブジェクトは同じ名前で削除および再作成できるため、同じ名前のオブジェクト履歴を区別するために、アカウント使用状況ビューには ID 列が含まれ、必要に応じて、生成およびシステムにより各履歴に割り当てられた内部 IDs が表示されます。

データの待機時間

Snowflakeの内部メタデータストアからデータを抽出するプロセスにより、アカウント使用状況ビューには自然な待機時間が発生します。

• ほとんどのビューでは、待機時間は2時間（120分）です。

• 残りのビューでは、待機時間は45分～3時間の間になります。

詳細については、このトピック内の各スキーマのビューのリストをご参照ください。また、これらはすべて最長時間です。ビューがクエリされたときの特定のビューの実際の待機時間は、それよりも短い場合があります。

対照的に、 情報スキーマ のビュー/テーブル関数には待機時間がありません。

履歴データ保持

特定のアカウント使用状況ビューは、使用状況の履歴メトリックを提供します。これらのビューの保持期間は1年（365日）です。

対照的に、 情報スキーマ の対応するビューおよびテーブル関数は、ビューに応じて、7日～6か月の範囲の非常に短い保持期間となります。

ACCOUNT_USAGE ビュー

ACCOUNT_USAGE スキーマには次のビューが含まれます。

ビュー	型	待機時間:sup:[1]	メモ
AUTOMATIC_CLUSTERING_HISTORY	履歴	3時間	データは1年間保持されます。
COLUMNS	オブジェクト	90分
COPY_HISTORY	履歴	2時間	データは1年間保持されます。
DATABASES	オブジェクト	3時間
DATABASE_STORAGE_USAGE_HISTORY	履歴	3時間	データは1年間保持されます。
DATA_TRANSFER_HISTORY	履歴	2時間	データは1年間保持されます。
FILE_FORMATS	オブジェクト	2時間
FUNCTIONS	オブジェクト	2時間
GRANTS_TO_ROLES	オブジェクト	2時間
GRANTS_TO_USERS	オブジェクト	2時間
LOAD_HISTORY	履歴	90分	データは1年間保持されます。
LOGIN_HISTORY	履歴	2時間	データは1年間保持されます。
MASKING_POLICIES	オブジェクト	2時間
MATERIALIZED_VIEW_REFRESH_HISTORY	履歴	3時間	データは1年間保持されます。
METERING_DAILY_HISTORY	履歴	3時間	データは1年間保持されます。
METERING_HISTORY	履歴	3時間	データは1年間保持されます。
PIPES	オブジェクト	2時間
PIPE_USAGE_HISTORY	履歴	3時間	データは1年間保持されます。
POLICY_REFERENCES	オブジェクト	2時間
QUERY_HISTORY	履歴	45分	データは1年間保持されます。
REFERENTIAL_CONSTRAINTS	オブジェクト	2時間
REPLICATION_USAGE_HISTORY	履歴	3時間	データは1年間保持されます。
ROLES	オブジェクト	2時間
SCHEMATA	オブジェクト	2時間
SEARCH_OPTIMIZATION_HISTORY	履歴	3時間	データは1年間保持されます。
SEQUENCES	オブジェクト	2時間
SESSIONS	履歴	3時間	データは1年間保持されます。
STAGES	オブジェクト	2時間
STAGE_STORAGE_USAGE_HISTORY	履歴	2時間	データは1年間保持されます。
STORAGE_USAGE	履歴	2時間	すべてのデータベーステーブルと内部ステージでの使用の組み合わせです。データは1年間保持されます。
TABLES	オブジェクト	90分
TABLE_CONSTRAINTS	オブジェクト	2時間
TABLE_STORAGE_METRICS	オブジェクト	90分
TASK_HISTORY	履歴	45分
USERS	オブジェクト	2時間
VIEWS	オブジェクト	90分
WAREHOUSE_LOAD_HISTORY	履歴	3時間	データは1年間保持されます。
WAREHOUSE_METERING_HISTORY	履歴	3時間	データは1年間保持されます。

_{[1] すべての待機時間は概算です。状況に応じて、実際の待機時間は短くなる場合があります。}

READER_ACCOUNT_USAGEビュー

READER_ACCOUNT_USAGE スキーマには次のビューが含まれます。

ビュー	型	待機時間:sup:[1]	メモ
LOGIN_HISTORY	履歴	2時間	データは1年間保持されます。
QUERY_HISTORY	履歴	45分	データは1年間保持されます。
RESOURCE_MONITORS	オブジェクト	2時間
STORAGE_USAGE	履歴	2時間	すべてのデータベーステーブルと内部ステージでの使用の組み合わせです。データは1年間保持されます。
WAREHOUSE_METERING_HISTORY	履歴	3時間	データは1年間保持されます。

_{[1] すべての待機時間は概算です。状況に応じて、実際の待機時間は短くなる場合があります。}

他のロールのアカウント使用を有効にする

デフォルトでは、 SNOWFLAKE データベースは ACCOUNTADMIN ロールでのみ使用可能です。

他のロールがデータベースとスキーマにアクセスし、ビューをクエリできるようにするには、 ACCOUNTADMIN ロールを持つユーザーが目的のロールに次のデータ共有権限を付与する必要があります。

IMPORTED PRIVILEGES

例：

USE ROLE ACCOUNTADMIN;

GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE SYSADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE customrole1;

USE ROLE customrole1;

SELECT * FROM snowflake.account_usage.databases;

アカウント使用状況ビューのクエリ

このセクションでは、 ACCOUNT_USAGE スキーマのビューを使用した一般的/有用なクエリの例を示します。

注釈

これらの例では、 SNOWFLAKE データベースと ACCOUNT_USAGE スキーマが現在のセッションで使用されていると想定しています。この例では、 ACCOUNTADMIN ロール（またはデータベースで IMPORTED PRIVILEGES が付与されたロール）が使用されていることも想定しています。使用されていない場合は、例にあるクエリを実行する前に次のコマンドを実行します。

USE ROLE ACCOUNTADMIN;

USE SCHEMA snowflake.account_usage;

例：ユーザーログインメトリック

ユーザーによるログイン失敗の試行間の平均秒数（今月現在）：

select user_name,
       count(*) as failed_logins,
       avg(seconds_between_login_attempts) as average_seconds_between_login_attempts
from (
      select user_name,
             timediff(seconds, event_timestamp, lead(event_timestamp)
                 over(partition by user_name order by event_timestamp)) as seconds_between_login_attempts
      from login_history
      where event_timestamp > date_trunc(month, current_date)
      and is_success = 'NO'
     )
group by 1
order by 3;

ユーザーによるログインの失敗（今月）：

select user_name,
       sum(iff(is_success = 'NO', 1, 0)) as failed_logins,
       count(*) as logins,
       sum(iff(is_success = 'NO', 1, 0)) / nullif(count(*), 0) as login_failure_rate
from login_history
where event_timestamp > date_trunc(month, current_date)
group by 1
order by 4 desc;

ユーザーおよび接続クライアントによるログインの失敗（今月現在）：

select reported_client_type,
       user_name,
       sum(iff(is_success = 'NO', 1, 0)) as failed_logins,
       count(*) as logins,
       sum(iff(is_success = 'NO', 1, 0)) / nullif(count(*), 0) as login_failure_rate
from login_history
where event_timestamp > date_trunc(month, current_date)
group by 1,2
order by 5 desc;

例：ウェアハウスクレジットの使用状況

アカウントの各ウェアハウスで使用されているクレジット（今月現在）：

select warehouse_name,
       sum(credits_used) as total_credits_used
from warehouse_metering_history
where start_time >= date_trunc(month, current_date)
group by 1
order by 2 desc;

アカウント内の各ウェアハウスで経時的に使用されたクレジット（今月現在）：

select start_time::date as usage_date,
       warehouse_name,
       sum(credits_used) as total_credits_used
from warehouse_metering_history
where start_time >= date_trunc(month, current_date)
group by 1,2
order by 2,1;

例：データストレージの使用量

アカウントに経時的に保存される請求可能なテラバイト：

select date_trunc(month, usage_date) as usage_month
  , avg(storage_bytes + stage_bytes + failsafe_bytes) / power(1024, 4) as billable_tb
from storage_usage
group by 1
order by 1;

例：ユーザークエリの合計と実行時間

アカウントで実行されたジョブの合計（今月現在）：

select count(*) as number_of_jobs
from query_history
where start_time >= date_trunc(month, current_date);

アカウントの各ウェアハウスで実行されたジョブの合計（今月）：

select warehouse_name,
       count(*) as number_of_jobs
from query_history
where start_time >= date_trunc(month, current_date)
group by 1
order by 2 desc;

ユーザーごとの平均クエリ実行時間（今月）：

select user_name,
       avg(execution_time) as average_execution_time
from query_history
where start_time >= date_trunc(month, current_date)
group by 1
order by 2 desc;

クエリタイプおよびウェアハウスサイズごとの平均クエリ実行時間（当月初めから今日まで）：

select query_type,
       warehouse_size,
       avg(execution_time) as average_execution_time
from query_history
where start_time >= date_trunc(month, current_date)
group by 1,2
order by 3 desc;

例：すべてのログインイベントのクエリ数を取得する

LOGIN_HISTORY、 QUERY_HISTORY、および SESSIONS の列を結合して、各ユーザーログインイベントのクエリ数を取得します。

select l.user_name,
       l.event_timestamp as login_time,
       l.client_ip,
       l.reported_client_type,
       l.first_authentication_factor,
       l.second_authentication_factor,
       count(q.query_id)
from snowflake.account_usage.login_history l
join snowflake.account_usage.sessions s on l.event_id = s.login_event_id
join snowflake.account_usage.query_history q on q.session_id = s.session_id
group by 1,2,3,4,5,6
order by l.user_name
;