スキーマ：: ACCOUNT_USAGE 、 READER_ACCOUNT_USAGE

QUERY_HISTORY ビュー¶

このAccount Usageビューを使用して、過去365日間（1年間）以内のさまざまなディメンション（時間範囲、セッション、ユーザー、ウェアハウスなど）によりSnowflakeクエリ履歴をクエリできます。

ビューは ACCOUNT_USAGE と READER_ACCOUNT_USAGE の両方のスキーマで使用できますが、次の違いがあります。

次の列は、リーダーアカウントビューのみで利用できます。
- READER_ACCOUNT_NAME
- READER_ACCOUNT_DELETED_ON

または、Information Schemaテーブル関数 (QUERY_HISTORYとも呼ばれる) を呼び出すこともできます。ただし、このテーブル関数では結果が過去7日間のアクティビティに制限されるのに対し、Account Usageビューでは365日間クエリできます。 QUERY_HISTORY 関数の説明をご参照ください。

こちらもご参照ください。

クエリ履歴でクエリのアクティビティをモニターする (Snowsight ダッシュボード)

列¶

以下の表の リーダーアカウントの使用状況ビューでのみ使用可能 列は、 QUERY_HISTORY 列が READER_ACCOUNT_USAGE スキーマで使用可能かどうかを示しています。

列名	データ型	説明	リーダーアカウントの使用状況ビューでのみ使用可能
`reader_account_name`	VARCHAR	SQL ステートメントが実行されたリーダーアカウントの名前。	✔
`query_id`	VARCHAR	SQL ステートメントの内部/システム生成識別子。	✔
`query_text`	VARCHAR	SQL ステートメントのテキスト。制限は10万文字です。10万文字を超える SQL ステートメントは切り捨てられます。
`database_id`	NUMBER	使用されていたデータベースの内部/システム生成識別子。	✔
`database_name`	VARCHAR	コンパイル時にクエリのコンテキストで指定されたデータベース。	✔
`schema_id`	NUMBER	使用されていたスキーマの内部/システム生成識別子。	✔
`schema_name`	VARCHAR	コンパイル時にクエリのコンテキストで指定されたスキーマ。	✔
`query_type`	VARCHAR	DML、クエリなど。クエリに失敗した場合、クエリ型は UNKNOWN になります。
`session_id`	NUMBER	ステートメントを実行したセッション。	✔
`user_name`	VARCHAR	クエリを発行したユーザー。
`role_name`	VARCHAR	クエリの時点でセッションでアクティブだったロール。	✔
`warehouse_id`	NUMBER	使用されていたウェアハウスの内部/システム生成識別子。	✔
`warehouse_name`	VARCHAR	クエリが実行されたウェアハウス（ある場合）。	✔
`warehouse_size`	VARCHAR	このステートメントが実行されたときのウェアハウスのサイズ。	✔
`warehouse_type`	VARCHAR	このステートメントが実行されたときのウェアハウスのタイプ。	✔
`cluster_number`	NUMBER	このステートメントが実行されたクラスター（マルチクラスターウェアハウス内）。	✔
`query_tag`	VARCHAR	QUERY_TAG セッションパラメーターを介してこのステートメントに設定されたクエリタグ。	✔
`execution_status`	VARCHAR	クエリの実行ステータス。有効な値: `success`、 `fail`、 `incident`。	✔
`error_code`	NUMBER	クエリがエラーを返した場合のエラーコード	✔
`error_message`	VARCHAR	クエリがエラーを返した場合のエラーメッセージ	✔
`start_time`	TIMESTAMP_LTZ	ステートメントの開始時間（ローカルタイムゾーン）	✔
`end_time`	TIMESTAMP_LTZ	ステートメントの終了時間（ローカルタイムゾーン）	✔
`total_elapsed_time`	NUMBER	経過時間（ミリ秒単位）。	✔
`bytes_scanned`	NUMBER	このステートメントによってスキャンされたバイト数。	✔
`percentage_scanned_from_cache`	FLOAT	ローカルディスクキャッシュからスキャンされたデータの割合。値は0.0〜1.0の範囲です。真のパーセントを得るために、100を掛けます。
`bytes_written`	NUMBER	書き込まれたバイト数（例：テーブルへのロード時）。
`bytes_written_to_result`	NUMBER	結果オブジェクトに書き込まれるバイト数。たとえば、 `select * from . . .` は、選択範囲の各フィールドを表す表形式の結果のセットを生成します。 . . 一般に、結果オブジェクトはクエリの結果として生成されたものを表し、 BYTES_WRITTEN_TO_RESULT は返された結果のサイズを表します。
`bytes_read_from_result`	NUMBER	結果オブジェクトから読み取ったバイト数。
`rows_produced`	NUMBER	このステートメントによって生成された行の数。ROWS_PRODUCED 列は、将来のリリースで廃止される予定です。ROWS_PRODUCED 列の値は、クエリによって影響を受ける論理的な行数を反映しているとは限りません。Snowflakeは、代わりに ROWS_INSERTED、 ROWS_UPDATED、 ROWS_WRITTEN_TO RESULTS、または ROWS_DELETED 列を使用することを推奨します。	✔
`rows_inserted`	NUMBER	クエリによって挿入された行の数。
`rows_updated`	NUMBER	クエリによって更新された行の数。
`rows_deleted`	NUMBER	クエリによって削除された行の数。
`rows_unloaded`	NUMBER	データのエクスポート中にアンロードされた行の数。
`bytes_deleted`	NUMBER	クエリによって削除されたバイト数。
`partitions_scanned`	NUMBER	スキャンされたマイクロパーティションの数。
`partitions_total`	NUMBER	このクエリに含まれるすべてのテーブルのマイクロパーティション合計。
`bytes_spilled_to_local_storage`	NUMBER	ローカルディスクにスピルしたデータの量。
`bytes_spilled_to_remote_storage`	NUMBER	リモートディスクにスピルしたデータの量。
`bytes_sent_over_the_network`	NUMBER	ネットワーク経由で送信されたデータの量。
`compilation_time`	NUMBER	コンパイル時間（ミリ秒単位）	✔
`execution_time`	NUMBER	実行時間（ミリ秒単位）	✔
`queued_provisioning_time`	NUMBER	ウェアハウスの作成、再開、またはサイズ変更のために、ウェアハウスコンピューティングリソースでのプロビジョニングを待機する、ウェアハウスキューで費やされた時間（ミリ秒単位）。	✔
`queued_repair_time`	NUMBER	ウェアハウス内のコンピューティングリソースの修復を待機する、ウェアハウスキュー内で費やされた時間（ミリ秒単位）。	✔
`queued_overload_time`	NUMBER	ウェアハウスが現在のクエリワークロードによって過負荷になっているために、ウェアハウスキューで費やされた時間（ミリ秒）。	✔
`transaction_blocked_time`	NUMBER	同時 DMLによってブロックされた時間（ミリ秒）。	✔
`outbound_data_transfer_cloud`	VARCHAR	データを別の地域やクラウドにアンロードするステートメントのターゲットクラウドプロバイダー。	✔
`outbound_data_transfer_region`	VARCHAR	データを別のリージョンやクラウドにアンロードするステートメントのターゲットリージョン。	✔
`outbound_data_transfer_bytes`	NUMBER	Snowflakeテーブルからデータをアンロードするステートメントで転送されるバイト数。	✔
`inbound_data_transfer_cloud`	VARCHAR	別の地域やクラウドからデータをロードするステートメントのソースクラウドプロバイダー。	✔
`inbound_data_transfer_region`	VARCHAR	別の地域やクラウドからデータをロードするステートメントのソース地域。	✔
`inbound_data_transfer_bytes`	NUMBER	他のアカウントからの複製操作で転送されたバイト数。ソースアカウントは、現在のアカウントと同じリージョンにある場合もあれば、異なるリージョンにある場合もあります。	✔
`list_external_files_time`	NUMBER	外部ファイルのリストに費やされた時間（ミリ秒単位）。
`credits_used_cloud_services`	NUMBER	クラウドサービスのために使用されたクレジットの数。この値はクラウドサービスの調整を考慮していないため、請求されるクレジットよりも大きくなる場合があります。実際に請求されたクレジット数を調べるには、 METERING_DAILY_HISTORYビューに対してクエリを実行します。	✔
`reader_account_deleted_on`	TIMESTAMP_LTZ	リーダーアカウントが削除された日時（UTC タイムゾーン）。	✔
`release_version`	VARCHAR	`major_release.minor_release.patch_release` の形式のリリースバージョン。
`external_function_total_invocations`	NUMBER	このクエリがリモートサービスを呼び出した回数の合計。重要な詳細については、使用上の注意をご参照ください。
`external_function_total_sent_rows`	NUMBER	このクエリが、すべてのリモートサービスに対してすべての呼び出しで送信した行の総数。
`external_function_total_received_rows`	NUMBER	このクエリが、すべてのリモートサービスに対してすべての呼び出しから受信した行の総数。
`external_function_total_sent_bytes`	NUMBER	このクエリが、すべてのリモートサービスに対してすべての呼び出しで送信したバイトの総数。
`external_function_total_received_bytes`	NUMBER	このクエリが、すべてのリモートサービスに対してすべての呼び出しから受信したバイトの総数。
`query_load_percent`	NUMBER	このクエリ実行に対するウェアハウス内のアクティブなコンピューティングリソースのおおよその割合。
`is_client_generated_statement`	BOOLEAN	クエリがクライアントによって生成されたかどうかを示します。
`query_acceleration_bytes_scanned`	NUMBER	Query Acceleration Service によってスキャンされたバイト数。
`query_acceleration_partitions_scanned`	NUMBER	Query Acceleration Serviceによってスキャンされたパーティションの数。
`query_acceleration_upper_limit_scale_factor`	NUMBER	クエリが受けたであろうメリットの上限スケールファクター。
`transaction_id`	NUMBER	ステートメントを含むトランザクションの ID。ステートメントがトランザクション内で実行されない場合は0。
`child_queries_wait_time`	NUMBER	メモ化可能な関数を呼び出すときに、キャッシュされたルックアップが完了するまでの時間（ミリ秒単位）。
`role_type`	VARCHAR	クエリを実行した APPLICATION、 DATABASE_ROLE、 ROLE のいずれかを指定します。
`query_hash`	VARCHAR	正規化された SQL テキストに基づいて計算されたハッシュ値。
`query_hash_version`	NUMBER	`QUERY_HASH` を計算するために使用されるロジックのバージョン。
`query_parameterized_hash`	VARCHAR	パラメーター化されたクエリに基づいて計算されたハッシュ値。
`query_parameterized_hash_version`	NUMBER	`QUERY_PARAMETERIZED_HASH` を計算するために使用されるロジックのバージョン。
`secondary_role_stats`	VARCHAR	クエリで評価されたセカンダリロールに関する3つのフィールドを含む JSON 形式の文字列: セッションに応じてセカンダリロールのリストまたは `ALL`、セカンダリロールの数のカウント、および各セカンダリロールの内部/システム生成 ID。IDs のカウントと数は最大で50です。
`rows_written_to_result`	NUMBER	結果オブジェクトに書き込まれる行数。CREATE TABLE AS SELECT （CTAS）とすべての DML 操作については、この結果は `1` です。
`query_retry_time`	NUMBER	アクション可能なエラーによるクエリ再試行の実行合計時間（ミリ秒）。詳細については、クエリ再試行列をご参照ください。
`query_retry_cause`	VARIANT	アクション可能なエラーのエラーメッセージの配列。この配列には、クエリの再試行ごとに1つのエラーメッセージが格納されます。クエリの再試行がない場合、配列は空です。詳細については、クエリ再試行列をご参照ください。
`fault_handling_time`	NUMBER	アクション不可能なエラーによるクエリ再試行の実行合計時間（ミリ秒）。詳細については、クエリ再試行列をご参照ください。

使用上の注意¶

一般¶

ビューの遅延は最大45分です。

列 EXTERNAL_FUNCTION_TOTAL_INVOCATIONS、 EXTERNAL_FUNCTION_TOTAL_SENT_ROWS、 EXTERNAL_FUNCTION_TOTAL_RECEIVED_ROWS、 EXTERNAL_FUNCTION_TOTAL_SENT_BYTES、および EXTERNAL_FUNCTION_TOTAL_RECEIVED_BYTES の値は、多くの要因の影響を受けます。要因には次のようなものがあります。
- SQL ステートメント内の外部関数の数。
- 各リモートサービスに送信されたバッチあたりの行数。
- 一時エラーによる再試行の数（例: 予期した時間内に応答の受信がなかったため）。

クエリ再試行列¶

クエリが正常に完了するためには、1回または複数回の再試行が必要な場合があります。クエリが再試行される原因には複数が考えられます。これらの原因の中には、 アクション可能 なものがあります。つまり、ユーザーは、特定のクエリについてクエリを変更して再試行を減らす、または排除することができます。たとえば、メモリ不足のエラーによってクエリが再試行された場合、ウェアハウスの設定を変更すると問題が解決する可能性があります。

クエリの再試行には、アクション不可能なフォールトが原因のものもあります。つまり、クエリの再試行を防ぐためにユーザーができる変更はありません。たとえば、ネットワークが停止した場合には、クエリが再試行される可能性があります。この場合、クエリやそれを実行するウェアハウスに変更はなく、クエリの再試行を防ぐことができます。

QUERY_RETRY_TIME、 QUERY_RETRY_CAUSE、 FAULT_HANDLING_TIME 列は、再試行されるクエリを最適化し、クエリパフォーマンスの変動をより良く理解するのに役立ちます。

ハイブリッドテーブル¶

以下のガイダンスは、 QUERY_HISTORY ビューを使用してハイブリッドテーブルに対してクエリを実行する場合に関するものです。

ハイブリッドテーブルに対してのみ動作する短時間実行クエリは、このビューまたは QUERY_HISTORY （Information Schemaテーブル関数）に記録を生成しなくなりました。このようなクエリをモニターするには、 AGGREGATE_QUERY_HISTORY を使用します。このビューにより、高スループットの運用ワークロードの傾向と問題をより簡単にモニターすることができます。
ハイブリッドテーブルに対してのみ動作する短時間クエリでは、 Snowsight で検査できるクエリプロファイルが提供されなくなりました。
ハイブリッドテーブルに対するクエリは、次のいずれかの条件を満たす場合に QUERY_HISTORY ビューとクエリプロファイルに記録を生成します。
- クエリは、ハイブリッドテーブルタイプ以外のテーブル型に対して実行される。この条件により、既存の非Unistoreワークロードの動作に変更がないことが保証されます。
- クエリは、 failed_with_incident の EXECUTION_STATUS で失敗する（QUERY_HISTORY を参照）。この条件により、特定の失敗したクエリを調査して報告し、支援を受けることができるようにします。
- クエリの実行時間が約500ミリ秒より長い。この条件により、遅いクエリのパフォーマンス問題を調査することができるようにします。
- クエリ結果のサイズが大きすぎる。
- クエリはSnowflakeトランザクションに関連付けられている。
- クエリには副作用のあるシステム関数が含まれている。
- クエリは、 SELECT、 INSERT、 DELETE、 UPDATE、または MERGE のステートメント型のいずれでもない。
- クエリは、 SnowSQL、 Snowsight、または従来のコンソールから実行される。この条件により、長時間実行に分類されないクエリであっても、手動で完全なクエリプロファイルを生成して、特定のクエリのパフォーマンス問題を調査することができます。
- クエリが上記の基準を満たさない場合でも、クエリを定期的にサンプルして QUERY_HISTORY ビューに記録を生成し、調査に役立つクエリプロファイルを作成することができます。

PUT および GET コマンド¶

PUT 、 GET コマンドの場合、 QUERY_HISTORY の success の EXECUTION_STATUS は、データファイルが正常にアップロードまたはダウンロードされたことを意味しません。代わりに、ステータスは、Snowflakeがファイル転送を続行するための承認を受けたことを示します。