クエリのトラブルシューティング
このセクションは、Amazon Redshift クエリで発生する可能性のある一般的な問題と重大な問題を特定し、それらの問題に対処するためのクイックリファレンスとして追加しました。
これらの提案は、トラブルシューティングの最初のステップです。以下のリソースにはより詳細な情報が記載されていますので、合わせて参照してください。
接続できない
クエリの接続が失敗する理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。
クライアントがサーバーに接続できない
SSL またはサーバー証明書を使用している場合、接続の問題をトラブルシューティングしているときにまずこの複雑さを排除します。その後、解決策を見つけたら、もう一度 SSL またはサーバー証明書を追加します。詳細については、「Amazon Redshift 管理ガイド」の「接続のセキュリティオプションを設定する」を参照してください。
接続が拒否される
一般的に、接続の確立に失敗したことを示すエラーメッセージを受け取った場合、クラスターにアクセスするためのアクセス許可に問題があることを意味します。詳細については、「Amazon Redshift 管理ガイド」の「接続が拒否または失敗する」を参照してください。
クエリがハングする
クエリがハングする、または応答しなくなる理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。
データベースへの接続が中断された
最大送信単位 (MTU) のサイズを小さくします。MTU サイズにより、ネットワーク接続を介して 1 つのイーサネットフレームで転送できるパケットの最大サイズ (バイト単位) が決まります。詳細については、「Amazon Redshift 管理ガイド」の「The connection to the database is dropped」(データベースへの接続が中断する) を参照してください
データベースへの接続がタイムアウトした
COPY コマンドなどの長いクエリを実行すると、データベースへのクライアント接続がハングまたはタイムアウトしているように見えます。この場合、Amazon Redshift コンソールにはクエリが完了したと表示されますが、クライアントツール自体はまだクエリを実行しているように見えることがあります。接続がいつ停止したかに応じて、クエリの結果がないか、不完全になる可能性があります。この効果は、中間ネットワークコンポーネントによってアイドル接続が終了すると発生します。詳細については、「Amazon Redshift 管理ガイド」の「Firewall Timeout Issue」(ファイアウォールのタイムアウト問題) を参照してください。
ODBC 使用時にクライアント側のメモリ不足エラーが発生する
クライアントアプリケーションが ODBC 接続を使用し、クエリで作成される結果セットが大きすぎてメモリが足りなくなる場合、カーソルを使用して、結果セットをクライアントアプリケーションに渡すことができます。詳細については、「DECLARE」および「カーソルを使用するときのパフォーマンスに関する考慮事項」を参照してください。
JDBC 使用時にクライアント側のメモリ不足エラーが発生する
JDBC 接続で大規模な結果セットを取得しようとすると、クライアント側のメモリ不足エラーが発生する可能性があります。詳細については、「JDBC フェッチサイズパラメータの設定」を参照してください。
デッドロックがある可能性がある
デッドロックがあると考えられる場合は、以下を試してください。
-
STV_LOCKS および STL_TR_CONFLICT システムテーブルで複数のテーブルの更新に起因する競合を見つけます。
-
PG_CANCEL_BACKEND 関数を使用して、1 つ以上の競合しているクエリをキャンセルします。
-
PG_TERMINATE_BACKEND 関数を使用して、セッションを終了します。これにより、終了したセッションで現在実行されているトランザクションがすべてのロックを解除し、トランザクションがロールバックされます。
-
同時書き込み操作のスケジュールを慎重に設定します。詳細については、「同時書き込み操作を管理する」を参照してください。
クエリに時間がかかりすぎる
クエリに時間がかかりすぎる理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。
テーブルが最適化されていない
並列処理を最大限に活用できるようにテーブルのソートキー、分散スタイル、および圧縮エンコードを設定します。詳細については、自動テーブル最適化の使用を参照してください。
クエリがディスクに書き込みを行っている
クエリが少なくともクエリ実行の一部でディスクに書き込みを行っている可能性があります。詳細については、「 クエリパフォーマンスの向上」を参照してください。
クエリが他のクエリの終了を待つ必要がある
クエリキューを作成し、別の種類のクエリを適切なキューに割り当てることで、システムの全体的なパフォーマンスを改善できる可能性があります。詳細については、「ワークロード管理の実装」を参照してください。
クエリが最適化されていない
説明プランを分析して、クエリを書き換えることが可能かどうか、またはデータベースを最適化することが可能かどうかを調べます。詳細については、「クエリプラン」を参照してください。
クエリの実行により多くのメモリが必要である
特定のクエリにより多くのメモリが必要な場合は、wlm_query_slot_countを増やすことによって使用可能なメモリを増やすことができます。
データベースに対して VACUUM コマンドを実行する必要がある
大量の行数を追加、削除、変更した場合、データをソートキー順序でロードしていなければ、VACUUM コマンドを実行します。VACUUM コマンドを実行すると、データが再編成され、ソート順序が維持され、パフォーマンスが復旧されます。詳細については、「テーブルのバキューム処理」を参照してください。
実行時間の長いクエリのトラブルシューティングに役立つその他のリソース
以下は、クエリのチューニングに役立つシステムビューのトピックとその他のドキュメントセクションです。
STV_INFLIGHT システムビューには、クラスターで実行されているクエリが表示されます。STV_RECENTS と一緒に使用すると、現在実行中のクエリや最近完了したクエリを判別できます。
SYS_QUERY_HISTORY はトラブルシューティングに役立ちます。DDL クエリと DML クエリが、関連するプロパティと共に表示されます。例えば、
runningやfailedなどの現在のステータス、それぞれの実行にかかった時間、同時実行スケーリングクラスターに対してクエリが実行されたかどうかなどを確認できます。STL_QUERYTEXT は、SQL コマンドのクエリテキストを取得します。さらに、STL_QUERYTEXT を STV_INFLIGHT に結合する SVV_QUERY_INFLIGHT には、より多くのクエリメタデータが表示されます。
トランザクションロックの競合は、クエリパフォーマンスの問題を引き起こす可能性があります。現在テーブルをロックしているトランザクションについては、「SVV_TRANSACTIONS」を参照してください。
「優先して調整が必要なクエリの特定」には、最近実行したどのクエリが最も時間がかかったかを判断するのに役立つトラブルシューティングクエリが紹介されています。これにより、改善が必要なクエリに集中して取り組むことができます。
クエリ管理の詳細を参照し、クエリキューの管理方法を理解したい場合は、「ワークロード管理の実装」にその方法が記載されています。ワークロード管理は高度な機能であるため、通常は自動ワークロード管理を利用することをお勧めします。
ロードが失敗する
データのロードが失敗する理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。
データソースが別の AWS リージョンにある
デフォルトでは、COPY コマンドで指定された Amazon S3 バケットまたは Amazon DynamoDB テーブルは、クラスターと同じ AWS リージョンに置かれている必要があります。データとクラスターが異なるリージョンにある場合、次のようなエラーが発生します。
The bucket you are attempting to access must be addressed using the specified endpoint.
可能な限り、クラスターとデータソースが同じリージョンに配置されるようにしてください。COPY コマンドで REGION オプションを使用することによって、別のリージョンを指定できます。
注記
クラスターとデータソースが異なる AWS リージョンにある場合、データ転送コストが発生します。レイテンシーも高くなります。
COPY コマンドが失敗する
STL_LOAD_ERRORS にクエリして、特定のロード中に発生したエラーを見つけます。詳細については、「STL_LOAD_ERRORS」を参照してください。
ロードに時間がかかりすぎる
ロード操作に時間がかかりすぎる理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。
COPY が 1 つのファイルからデータをロードする
ロードデータを複数のファイルに分割します。1 つの大容量ファイルからすべてのデータをロードする場合、Amazon Redshift は低速なシリアル化されたロードを実行します。ファイル数は、クラスター内のスライス数の倍数にする必要があり、ファイルはほぼ同じサイズ (圧縮後 1 MB～1 GB) にする必要があります。詳細については、「Amazon Redshift クエリの設計のベストプラクティス」を参照してください。
ロード操作で複数の COPY コマンドを使用する
複数の COPY コマンドを同時に使用して複数のファイルから 1 つのテーブルをロードする場合、Amazon Redshift は低速なシリアル化されたロードを実行します。この場合、1 つの COPY コマンドを使用します。
ロードデータが正しくない
COPY 操作がロードするデータが正しくない理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。
違うファイルがロードされる
オブジェクトプレフィックスを使用してデータファイルを指定すると、不要なファイルが読み取られることがあります。ロードするファイルを正確に指定するには、代わりにマニフェストファイルを使用します。詳細については、COPY コマンドの copy_from_s3_manifest_file オプションと COPY の例の Example: COPY from Amazon S3 using a manifest を参照してください。
JDBC フェッチサイズパラメータの設定
デフォルトでは、JDBC ドライバーはクエリに対して一度にすべての結果を収集します。その結果、JDBC 接続で大きな結果セットを取得しようとすると、クライアント側のメモリ不足エラーが発生する可能性があります。クライアントが 1 つのオールオアナッシングの取得ではなくバッチで結果セットを取得できるようにするには、JDBC フェッチサイズパラメータをクライアントアプリケーションで設定します。
注記
フェッチサイズは ODBC ではサポートされません。
最適なパフォーマンスのためには、メモリ不足エラーが発生しない最大の値にフェッチサイズを設定します。フェッチサイズの値を低く設定すると、サーバートリップが増え、それにより実行時間が長くなります。サーバーは、クライアントが結果セット全体を取得するまで、WLM クエリスロットおよび関連メモリを含むリソースを予約します。そうでない場合、クエリはキャンセルされます。フェッチサイズを適切に調整すると、それらのリソースはより迅速に解放され、他のクエリに利用できるようになります。
注記
大きなデータセットを抽出する必要がある場合は、UNLOAD ステートメントを使用してデータを Amazon S3 に転送することをお勧めします。UNLOAD を使用するときは、コンピューティングノードは並行してデータの転送を高速化します。
JDBC フェッチサイズパラメータの詳細については、PostgreSQL のドキュメントで「Getting results based on a cursor
