アカウントの使用¶

SNOWFLAKE データベースでは、 ACCOUNT_USAGE スキーマと READER_ACCOUNT_USAGE スキーマを使用して、アカウントとアカウントに関連付けられているすべてのリーダーアカウント（存在する場合）のオブジェクトメタデータと履歴使用状況データをクエリできます。

このトピックの内容:

Account Usageスキーマの概要
Account UsageとInformation Schemaの違い
ACCOUNT_USAGE ビュー
- Account Usageテーブル関数
READER_ACCOUNT_USAGE ビュー
他のロールに対するSnowflakeデータベースの使用の有効化
アカウント使用状況ビューのクエリ

Account Usageスキーマの概要¶

ACCOUNT_USAGE

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

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

各ビューに含まれるドロップ済みオブジェクトの記録。
履歴使用データの保持時間が長くなる。
データの待機時間。

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

READER_ACCOUNT_USAGE

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

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

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

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

Account UsageとInformation Schemaの違い¶

Account Usageビューと Snowflake Information Schema にある対応するビュー（またはテーブル関数）は、同一の構造と命名規則を使用しますが、このセクションに記載されるように、いくつかの重要な違いがあります。

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

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

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

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

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

オブジェクト名の列（例: TABLE_NAME 列）が NULL の場合、そのオブジェクトはドロップされています。この場合は、親オブジェクトの名前と IDs の列（例: DATABASE_NAME 列と SCHEMA_NAME 列）も NULL です。

一部のビューでは、オブジェクトがドロップされた場合でも、オブジェクト名の列にオブジェクトの名前が含まれている場合があることに注意してください。

データの待機時間¶

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

ほとんどのビューでは、待機時間は2時間（120分）です。
残りのビューでは、待機時間は45分～3時間の間になります。

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

対照的に、 Snowflake Information Schema のビュー/テーブル関数には待機時間がありません。

履歴データ保持¶

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

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

ACCOUNT_USAGE ビュー¶

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

ビュー	型	待機時間:sup:[1]	メモ
ACCESS_HISTORY	履歴	3時間	データは1年間保持されます。
AUTOMATIC_CLUSTERING_HISTORY	履歴	3時間	データは1年間保持されます。
COLUMNS	オブジェクト	90分
COMPLETE_TASK_GRAPHS	履歴	45分	データは1年間保持されます。
COPY_HISTORY	履歴	2 時間 ^[2]	データは1年間保持されます。
DATABASES	オブジェクト	3時間
DATABASE_REPLICATION_USAGE_HISTORY	履歴	3時間	データは1年間保持されます。
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 分 ^[2]	データは1年間保持されます。
LOGIN_HISTORY	履歴	2時間	データは1年間保持されます。
MASKING_POLICIES	オブジェクト	2時間
MATERIALIZED_VIEW_REFRESH_HISTORY	履歴	3時間	データは1年間保持されます。
METERING_DAILY_HISTORY	履歴	3時間	データは1年間保持されます。
METERING_HISTORY	履歴	3時間	データは1年間保持されます。
OBJECT_DEPENDENCIES	履歴	3時間
PIPES	オブジェクト	2時間
PIPE_USAGE_HISTORY	履歴	3時間	データは1年間保持されます。
POLICY_REFERENCES	オブジェクト	2時間
QUERY_ACCELERATION_ELIGIBLE	履歴	3時間	データは1年間保持されます。
QUERY_ACCELERATION_HISTORY	履歴	3時間	Query Accelerationサービスプレビューの一部として利用できます。データは1年間保持されます。
QUERY_HISTORY	履歴	45分	データは1年間保持されます。
REFERENTIAL_CONSTRAINTS	オブジェクト	2時間
REPLICATION_GROUP_REFRESH_HISTORY	履歴	3時間	データは1年間保持されます。
REPLICATION_GROUP_USAGE_HISTORY	履歴	3時間	データは1年間保持されます。
REPLICATION_USAGE_HISTORY	履歴	3時間	データは1年間保持されます。
ROLES	オブジェクト	2時間
ROW_ACCESS_POLICIES	オブジェクト	2時間
SCHEMATA	オブジェクト	2時間
SEARCH_OPTIMIZATION_HISTORY	履歴	3時間	データは1年間保持されます。
SEQUENCES	オブジェクト	2時間
SERVERLESS_TASK_HISTORY	履歴	3時間	データは1年間保持されます。
SESSIONS	履歴	3時間	データは1年間保持されます。
STAGES	オブジェクト	2時間
STAGE_STORAGE_USAGE_HISTORY	履歴	2時間	データは1年間保持されます。
STORAGE_USAGE	履歴	2時間	すべてのデータベーステーブルと内部ステージでの使用の組み合わせです。データは1年間保持されます。
TABLES	オブジェクト	90分
TABLE_CONSTRAINTS	オブジェクト	2時間
TABLE_STORAGE_METRICS	オブジェクト	90分
TAG_REFERENCES	オブジェクト	2時間
TAGS	オブジェクト	2時間
TASK_HISTORY	履歴	45分
USERS	オブジェクト	2時間
VIEWS	オブジェクト	90分
WAREHOUSE_EVENTS_HISTORY	履歴	3時間	データは1年間保持されます。
WAREHOUSE_LOAD_HISTORY	履歴	3時間	データは1年間保持されます。
WAREHOUSE_METERING_HISTORY	履歴	3時間	データは1年間保持されます。

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

_{[2] 32以下の DML ステートメントまたは100以下の行を持つテーブルの場合、これらのビューの待機時間は最大1日になる可能性があります。}

Account Usageテーブル関数¶

現在、Snowflakeは ACCOUNT_USAGE テーブル関数を1つサポートしています。

テーブル関数	データ保持	メモ
TAG_REFERENCES_WITH_LINEAGE	N/A	結果は、指定されたオブジェクトにアクセスできるロールに対してのみ返されます。

注釈

Account Usageビューと同様に、このテーブル関数を呼び出すときは待機時間を考慮してください。このテーブル関数の予想待機時間は、 TAG_REFERENCES ビューの待機時間と同様です。

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データベースの使用の有効化¶

デフォルトでは、 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 database_name, database_owner FROM snowflake.account_usage.databases;

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

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

注釈

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

USE SCHEMA snowflake.account_usage;
```
Snowflake固有のビューは変更される可能性があります。これらのビューからすべての列を選択することは避けてください。代わりに、必要な列を選択します。たとえば、 name 列が必要な場合は、 SELECT * ではなく SELECT name を使用します。

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

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

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;

例: ウェアハウスのパフォーマンス¶

このクエリは、1日の間に15分の時間間隔でスループットや遅延などの仮想ウェアハウスのパフォーマンスメトリックを計算します。

以下のコードサンプルでは、 CURRENT_WAREHOUSE() を 'MY_WH' に置き換えて、特定のウェアハウスのメトリックを計算します。さらに、 WITH 句の time_from と time_to の日付を変更します。

WITH
params AS (
SELECT
    CURRENT_WAREHOUSE() AS warehouse_name,
    '2021-11-01' AS time_from,
    '2021-11-02' AS time_to
),

jobs AS (
SELECT
    query_id,
    time_slice(start_time::timestamp_ntz, 15, 'minute','start') as interval_start,
    qh.warehouse_name,
    database_name,
    query_type,
    total_elapsed_time,
    compilation_time AS compilation_and_scheduling_time,
    (queued_provisioning_time + queued_repair_time + queued_overload_time) AS queued_time,
    transaction_blocked_time,
    execution_time
FROM snowflake.account_usage.query_history qh, params
WHERE
    qh.warehouse_name = params.warehouse_name
AND start_time >= params.time_from
AND start_time <= params.time_to
AND execution_status = 'SUCCESS'
AND query_type IN ('SELECT','UPDATE','INSERT','MERGE','DELETE')
),

interval_stats AS (
SELECT
    query_type,
    interval_start,
    COUNT(DISTINCT query_id) AS numjobs,
    MEDIAN(total_elapsed_time)/1000 AS p50_total_duration,
    (percentile_cont(0.95) within group (order by total_elapsed_time))/1000 AS p95_total_duration,
    SUM(total_elapsed_time)/1000 AS sum_total_duration,
    SUM(compilation_and_scheduling_time)/1000 AS sum_compilation_and_scheduling_time,
    SUM(queued_time)/1000 AS sum_queued_time,
    SUM(transaction_blocked_time)/1000 AS sum_transaction_blocked_time,
    SUM(execution_time)/1000 AS sum_execution_time,
    ROUND(sum_compilation_and_scheduling_time/sum_total_duration,2) AS compilation_and_scheduling_ratio,
    ROUND(sum_queued_time/sum_total_duration,2) AS queued_ratio,
    ROUND(sum_transaction_blocked_time/sum_total_duration,2) AS blocked_ratio,
    ROUND(sum_execution_time/sum_total_duration,2) AS execution_ratio,
    ROUND(sum_total_duration/numjobs,2) AS total_duration_perjob,
    ROUND(sum_compilation_and_scheduling_time/numjobs,2) AS compilation_and_scheduling_perjob,
    ROUND(sum_queued_time/numjobs,2) AS queued_perjob,
    ROUND(sum_transaction_blocked_time/numjobs,2) AS blocked_perjob,
    ROUND(sum_execution_time/numjobs,2) AS execution_perjob
FROM jobs
GROUP BY 1,2
ORDER BY 1,2
)
SELECT * FROM interval_stats;

注釈

さまざまなステートメントタイプを個別に分析します（例: INSERT または DELETE または他のステートメントから独立した SELECT ステートメント）。

NUMJOBS 値は、その時間間隔のスループットを表します。
P50_TOTAL_DURATION （中央値）とP95_TOTAL_DURATION （ピーク）の値は待機時間を表します。
SUM_TOTAL_DURATION は、さまざまなジョブステージ（COMPILATION_AND_SCHEDULING、 QUEUED、 BLOCKED、 EXECUTION）の SUM_<ジョブステージ>_TIME 値の合計です。
ロード（NUMJOBS）が増加したときに、<ジョブステージ>_RATIO の値を分析します。比率の変化または平均からの偏差を探します。
- COMPILATION_AND_SCHEDULING_RATIO が高い場合、ウェアハウスは高同時実行性および低待機時間という変更の恩恵を受ける可能性があります。これらの改善は、すべてのリージョンのウェアハウスで利用できます。
- QUEUED_RATIO が高い場合は、ウェアハウスの容量が不足する可能性があります。クラスターを追加するか、ウェアハウスのサイズを増やします。

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

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

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 からの列を結合して、各ユーザーログインイベントのクエリ数を取得します。

注釈

SESSIONS ビューは、2020年7月20～21日以降の情報を記録します。したがって、クエリ結果には、この日付から始まる3つのビューのそれぞれで重複する情報のみが含まれます。

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
;