クエリエラーのトラブルシューティング

このドキュメントでは、失敗したクエリによって返される最も一般的なエラーのトラブルシューティングに役立つ情報をご提供します。

Avro のスキーマ解決

エラー文字列: Cannot skip stream

このエラーは、スキーマが異なる複数の Avro ファイルを読み込むときに発生する可能性があります。その結果、スキーマ解決に関する問題が発生し、インポートジョブがランダムなファイルで失敗します。

このエラーに対処するには、読み込みジョブの最後のアルファベットファイルに、異なるスキーマのスーパーセット（ユニオン）が含まれていることを確認してください。これは、Avro がスキーマ解決を処理する仕組みに基づく要件です。

同時実行クエリの競合

エラー文字列: Concurrent jobs in the same session are not allowed

このエラーは、複数のクエリがセッションで同時に実行されている場合に発生します。複数クエリの同時実行はサポートされていません。セッションの制限事項をご覧ください。

DML ステートメントの競合

エラー文字列: Could not serialize access to table due to concurrent update

このエラーは、同じテーブルに対して同時に実行されている変更データ操作言語（DML）ステートメントが互いに競合する場合、または変更 DML ステートメントの実行中にテーブルが切り捨てられる場合に発生することがあります。詳細については、DML ステートメントの競合をご覧ください。

このエラーに対処するには、DML オペレーションが重複しないように、1 つのテーブルに影響する DML オペレーションを実行します。

列レベルのアクセス制御の権限が不十分

エラー文字列: Requires raw access permissions on the read columns to execute the DML statements

このエラーは、スキャンする列に対し、列レベルのアクセス制御を使用して列レベルでアクセスを制限するきめ細かい読み取り権限がない状態で、DELETE、UPDATE、MERGE の DML ステートメントを試行した場合に発生します。詳細については、列レベルのアクセス制御からの書き込みへの影響をご覧ください。

スケジュールされたクエリの認証情報が無効

エラー文字列:

Error code: INVALID_USERID
Error code 5: Authentication failure: User Id not found
PERMISSION_DENIED: BigQuery: Permission denied while getting Drive credentials

このエラーは、特に Google ドライブのデータに対してクエリを実行するときなど、古い認証情報が原因でスケジュールされたクエリが失敗した場合に発生する可能性があります。

このエラーに対処するには、スケジュールされたクエリの認証情報を更新します。

サービスアカウントの認証情報が無効

エラー文字列: HttpError 403 when requesting returned: The caller does not have permission

このエラーは、サービスアカウントを使用してスケジュールされたクエリを設定しようとすると表示されることがあります。このエラーを解決するには、認証と権限に関する問題のトラブルシューティング手順をご覧ください

スナップショット時間が無効

エラー文字列: Invalid snapshot time

このエラーは、データセットのタイムトラベル期間外の過去のデータをクエリしようとすると発生することがあります。このエラーに対処するには、データセットのタイムトラベル期間内の過去のデータにアクセスするようにクエリを変更します。

このエラーは、クエリで使用されているテーブルのいずれかが削除され、クエリの開始後に再作成された場合にも発生することがあります。失敗したクエリと同時に実行されていたこのオペレーションを実行するスケジュールされたクエリまたはアプリケーションがあるかどうかを確認します。ある場合は、削除と再作成のオペレーションを実行するプロセスを、そのテーブルを読み取るクエリと競合しない時間に実行してみてください。

ジョブがすでに存在している

エラー文字列: Already Exists: Job <job name>

このエラーは、大規模な配列を評価する必要があり、作成に平均よりも時間がかかるクエリジョブで発生する可能性があります。たとえば、WHERE column IN (<2000+ elements array>) のような WHERE 句を含むクエリなどです。

このエラーに対処するには、次の手順をお試しください。

BigQuery で jobId 値を指定する代わりに、ランダムな値を生成できるようにします。
パラメータ化されたクエリを使用して配列を読み込みます。

ジョブが見つからない

エラー文字列: Job not found

このエラーは、location フィールドに値が指定されていない getQueryResults 呼び出しが原因で発生することがあります。その場合は、location 値を指定して呼び出しを再試行します。

詳細については、同じ共通テーブル式（CTE）を複数回評価することを避けるをご覧ください。

クエリの実行時間が上限を超えている

エラー文字列: Query fails due to reaching the execution time limit

クエリがクエリ実行時間の上限に達している場合は、次のようなクエリで INFORMATION_SCHEMA.JOBS ビューをクエリして、以前のクエリの実行時間を確認します。

SELECT TIMESTAMP_DIFF(end_time, start_time, SECOND) AS runtime_in_seconds
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE statement_type = 'QUERY'
AND query = "my query string";

以前のクエリの実行時間が大幅に短い場合は、クエリパフォーマンスの分析情報を使用して、根本的な原因を特定し、対処します。

クエリのレスポンスが大きすぎる

エラー文字列: responseTooLarge

このエラーは、クエリの結果が最大レスポンスサイズよりも大きいときに返されます。

このエラーに対処するには、responseTooLarge エラーメッセージのガイダンスに従ってください。

DML ステートメントが多すぎる

エラー文字列: Too many DML statements outstanding against <table-name>, limit is 20

このエラーは、単一テーブルのキューで、PENDING ステータスのDML ステートメントの上限（20 個）を超えた場合に発生します。このエラーは通常、単一テーブルに対して BigQuery で処理できるより速度も速く DML ジョブを送信したときに発生します。

解決策としては、複数の小規模な DML オペレーションを、大規模で少ない数のジョブにグループ化することが考えられます。小さいジョブをより大きなジョブにグループ化すると、大規模なジョブを実行するためのコストは平均化され、実行は速くなります。同じデータに影響する DML ステートメントを統合すると、通常は DML ジョブの効率が向上し、キューサイズの割り当て上限を超える可能性が低くなります。DML オペレーションの最適化の詳細については、単一行を更新または挿入する DML ステートメントをご覧ください。

DML 効率を改善する別の解決策として、テーブルをパーティション分割またはクラスタ化することもできます。詳しくは、ベストプラクティスをご覧ください。

リソース超過の問題

クエリを完了するためのリソースが不足していると、次の問題が発生します。

クエリで CPU リソースの超過が発生する

エラー文字列: Query exceeded resource limits

このエラーは、スキャンされたデータの量と比べてオンデマンドクエリが使用する CPU が多すぎる場合に発生します。この問題を解決する方法については、リソース超過に関する問題のトラブルシューティングをご覧ください。

クエリでメモリリソースの超過が発生する

エラー文字列: Resources exceeded during query execution: The query could not be executed in the allotted memory

SELECT ステートメントの場合、このエラーはクエリで使用するリソースが多すぎる場合に発生します。このエラーに対処するには、リソース超過に関する問題のトラブルシューティングをご覧ください。

クエリでシャッフルリソースの超過が発生する

エラー文字列: Resources exceeded during query execution: Your project or organization exceeded the maximum disk and memory limit available for shuffle operations

このエラーは、クエリが十分なシャッフルリソースにアクセスできない場合に発生します。

このエラーに対処するには、より多くのスロットをプロビジョニングするか、クエリで処理するデータの量を減らします。この方法の詳細については、シャッフル割り当てが不十分をご覧ください。

この問題を解決する方法の詳細については、リソース超過に関する問題のトラブルシューティングをご覧ください。

クエリが複雑すぎる

エラー文字列: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex

このエラーは、クエリが複雑すぎる場合に発生します。複雑になる主な原因は次のとおりです。

WITH 句が深くネストしているか、繰り返し使用されている。
ビューが深くネストしているか、繰り返し使用されている。
UNION ALL 演算子が繰り返し使用されている。

このエラーに対処するには、次の方法をお試しください。

クエリを複数のクエリに分割し、手続き型言語を使用して、共有状態でこれらのクエリを順番に実行します。
WITH 句ではなく一時テーブルを使用します。
クエリを書き換えて、参照されるオブジェクトと比較の数を減らします。

この問題を解決する方法の詳細については、リソース超過に関する問題のトラブルシューティングをご覧ください。

リソース超過に関する問題のトラブルシューティング

クエリジョブの場合:

クエリを最適化するために、次の手順をお試しください。

ORDER BY 句を削除します。
クエリで JOIN を使用している場合は、サイズが大きいほうのテーブルを句の左側に指定します。
クエリで FLATTEN を使用している場合は、そのユースケースでこれが必要かどうかを判断します。詳しくは、ネストされたデータと繰り返しデータをご覧ください。
クエリで EXACT_COUNT_DISTINCT を使用している場合は、COUNT(DISTINCT) の使用を検討してください。
クエリで使用している COUNT(DISTINCT <value>, <n>) の <n> 値が大きい場合は、GROUP BY の使用を検討してください。詳細については、COUNT(DISTINCT) をご覧ください。
クエリで UNIQUE を使用している場合は、代わりに GROUP BY を使用するか、サブセレクト内でウィンドウ関数を使用することを検討します。
クエリで LIMIT 句を使用して多くの行を実体化している場合は、別の列（ROW_NUMBER() など）でフィルタリングするか、LIMIT 句全体を削除して書き込みの並列化を可能にすることを検討してください。
クエリで深くネストされたビューと WITH 句を使用すると、複雑さが指数関数的に増加し、上限に達する可能性があります。
一時テーブルを WITH 句で置き換えないでください。この句の再計算が複数回必要になることがあります。その場合、クエリが複雑になり、処理速度が遅くなる可能性があります。一時テーブルに中間結果を保存することで複雑さが軽減されます。
UNION ALL クエリは使用しないでください。

詳しくは、次のリソースをご覧ください。

読み込みジョブの場合:

Avro ファイルまたは Parquet ファイルを読み込む場合は、ファイルの行サイズを小さくします。読み込むファイル形式に固有のサイズ制限を確認します。

このエラーが ORC ファイルの読み込み時に発生した場合は、サポートにお問い合わせください。

Storage API の場合:

エラー文字列: Stream memory usage exceeded

Storage Read API の ReadRows 呼び出し時、メモリ使用量が多いストリームでは、このメッセージを伴う RESOURCE_EXHAUSTED エラーが発生することがあります。これは、ワイドテーブルや、複雑なスキーマを含むテーブルから読み取る際に発生することがあります。解決策としては、読み取る列の数を減らす（selected_fields パラメータを使用）か、テーブルスキーマを簡素化することで、結果の行サイズを減らします。