Amazon Redshift でクエリが中止されたのはなぜですか?

最終更新日: 2021 年 7 月 28 日

以下の理由により、Amazon Redshift でクエリが中止されることがあります。

• Amazon Redshift ワークロード管理 (WLM) クエリモニタリングルールのセットアップ
• ステートメントのタイムアウト値
• リクエストの中止、キャンセル、終了
• ネットワークの問題
• クラスターのメンテナンスのアップグレード
• 内部処理エラー
• アサートエラー

クエリが中止されないようにするには、次の方法を検討してください。

• タイムアウトパラメータを増やします。
• WLM QMR ルールを更新します。
• メンテナンスウィンドウ外で長時間実行されるオペレーションをスケジュールします。

WLM クエリ監視ルール (QMR) を作成して、キューのメトリクスベースのパフォーマンス境界を定義できます。また、クエリが WLM の時間制限を超えた場合に Amazon Redshift が実行するアクションを指定することもできます。たとえば、60 秒を超えるしきい値で実行されるクエリを中止するルールを作成できます。

例 1: クエリ監視ルールで指定された「中止」アクション

クエリ監視ルールで指定された「中止」アクションを原因としてクエリが中止された場合、クエリは次のエラーを返します。

ERROR:  Query (500029) cancelled by WLM abort action of Query Monitoring Rule "testrule".

「中止」アクションを原因としてクエリが中止されたかどうかを識別するには、次のクエリを実行します。

select * from STL_WLM_RULE_ACTION where action = 'abort';

クエリ出力には、「中止」アクションによって中止されたすべてのクエリが一覧表示されます。クエリ ID が出力に一覧表示されている場合は、WLM QMR パラメータで時間制限を増やします。

例 2: ホップされるクエリに使用可能なキューがない

クエリ監視ルールで「ホップ」アクションが指定されている場合は、クエリをホップできます。クエリがホップされる場合、WLM は、WLM キュー割り当てルールに基づいて、次の一致するキューにクエリをルーティングしようとします。クエリがキュー定義と一致しない場合、クエリはキャンセルされます。キャンセルされたクエリは、既定のキューに再割り当てされません。WLM タイムアウト動作の詳細については、wlm_json_configuration パラメータのプロパティを参照してください。

注: クエリをホップできるのは、手動の WLM 設定のみです。

クエリがホップされているが、一致するキューが使用できない場合、キャンセルされたクエリは次のエラーメッセージを返します。

ERROR: Query (500104) canceled on user's request and ran out of wlm queues for restart.

このエラーメッセージでクエリが中止された場合は、ユーザー定義キューを確認します。

select * from stl_wlm_query where query=<query-id>;

出力では、service_class エントリ 6～13 にユーザー定義キューが含まれます。たとえば、service_class 6 は WLM 設定で Queue1 をリストし、service_class 7 は Queue2 をリストする場合があります。

service_class からキューへのマッピングの詳細を取得するには、次のクエリを実行します。

select * from stv_wlm_service_class_config where service_class>5;

キューマッピング情報を取得したら、Amazon Redshift コンソールから WLM 設定を確認します。キューが WLM 設定で定義されているキューと一致しているかどうかを確認します。クエリをホップできるのは、ユーザグループまたはクエリグループの設定で一致するキューがある場合だけです。詳細については、WLM クエリキューのホッピングを参照してください。

statement_timeout 値は、Amazon Redshift がクエリを終了するまでに、クエリが実行できる最大時間です。ステートメントのタイムアウトを超えると、セッション中に送信されたクエリが中止され、次のエラーメッセージが表示されます。

ERROR:  Query (150) cancelled on user's request

ステートメントのタイムアウトを原因としてクエリが中止されたかどうかを確認するには、次のクエリを実行します。

select * from SVL_STATEMENTTEXT where text ilike '%set%statement_timeout%to%' and pid in (select pid from STL_QUERY where query = <queryid>);

ステートメントのタイムアウトは、クラスターパラメータグループでも設定できます。クラスターパラメータグループと statement_timeout 設定を確認して、追加の確認を行います。クラスターパラメータグループおよび statement_timeout 設定の詳細については、パラメータグループの変更を参照してください。

特定のクエリがユーザー (スーパーユーザーなど) によって中止またはキャンセルされたかどうかを確認するには、クエリ ID を指定して次のコマンドを実行します。

select * from SVL_STATEMENTTEXT where text ilike '%cancel%' and xid 
    in (select xid from STL_QUERY where query = <queryid>);
select * from SVL_STATEMENTTEXT where text ilike '%abort%' and xid in (select xid from STL_QUERY where query = <queryid>);

クエリが出力に表示された場合、クエリはユーザーの要求に応じて中止またはキャンセルされています。

注: ユーザーは自分のセッションのみを終了できます。スーパーユーザーはすべてのセッションを終了できます。

クエリは、ユーザーが対応するプロセスをキャンセルまたは終了したときに中止することもできます (クエリが実行されている場合)。次に、クエリをキャンセルまたは中止できる対応するプロセスの例を示します。

• PG_TERMINATE_BACKEND
• PG_CANCEL_BACKEND
• CANCEL

これらのコマンドによってプロセスがキャンセルまたは終了されると、エントリは SVL_TERMINATE に記録されます。対応するセッションが終了したことを原因としてクエリが中止されたかどうかを確認するには、SVL_TERMINATE ログを確認します。

select * from SVL_TERMINATE where pid=(select pid from STL_QUERY where query=500534);

ネットワークの問題を原因としてクエリが中止されることがあります。ネットワークの問題がクエリの中止を引き起こしているかどうかを確認するには、STL_CONNECTION_LOG エントリを確認します。

select * from STL_CONNECTION_LOG where pid in (select pid from STL_QUERY where query = <query_id>);

STL_CONNECTION_LOG は、認証の試行とネットワーク接続または切断を記録します。出力にクエリが表示された場合、ネットワーク接続の問題がクエリの中止を引き起こしている可能性があります。

クエリの実行中にスケジュールされたメンテナンスが実行されると、クエリは終了してロールバックされ、クラスターの再起動が必要になります。長時間実行されるオペレーション (大規模なデータロードや VACUUM オペレーションなど) をスケジュールして、メンテナンスウィンドウを回避します。詳細については、メンテナンスウィンドウを回避したスケジュール設定を参照してください。

Amazon Redshift クラスターでメンテナンスが実行されたかどうかを確認するには、Amazon Redshift コンソールで [Events] (イベント) タブを選択します。

STL_ERROR テーブルには、Amazon Redshift によって生成された内部処理エラーが記録されます。STL_ERROR テーブルには、SQL エラーやメッセージは記録されません。

クエリが内部エラーによって中止されたかどうかを確認するには、STL_ERROR エントリを確認します。

select * from STL_ERROR where userid=<user id>;

ASSERT エラーを原因としてクエリが中止されることがあります。ASSERT エラーは、クエリ自体に問題がある場合に発生する可能性があります。パッチのアップグレード後に ASSERT エラーが発生した場合は、Amazon Redshift を最新のクラスターバージョンに更新してください。次に、クラスターのバージョン履歴を確認します。あるいは、クラスターのバージョンをロールバックできます。