メニュー
Amazon Redshift
データベース開発者ガイド (API Version 2012-12-01)

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

このセクションでは、Amazon Redshift クエリで発生する可能性のある一般的な問題と重大な問題を特定し、それらの問題に対処するためのクイックリファレンスとして追加されました。

これらの提案は、トラブルシューティングの最初のステップです。以下のリソースにはより詳細な情報が記載されていますので、合わせて参照してください。

接続できない

クエリの接続が失敗する理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。

クライアントがサーバーに接続できない

SSL またはサーバー証明書を使用している場合、接続の問題をトラブルシューティングしているときにまずこの複雑さを排除します。その後、解決策を見つけたら、もう一度 SSL またはサーバー証明書を追加します。詳細については、Amazon Redshift Cluster Management Guide の「接続のセキュリティオプションを設定する」を参照してください。

接続が拒否される

一般的に、接続の確立に失敗したことを示すエラーメッセージを受け取った場合、クラスターにアクセスするためのアクセス許可に問題があることを意味します。詳細については、Amazon Redshift Cluster Management Guide の「接続が拒否または失敗する」を参照してください。

クエリがハングする

クエリがハングする、または応答しなくなる理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。

データベースへの接続が中断された

最大送信単位 (MTU) のサイズを小さくします。MTU サイズにより、ネットワーク接続を介して 1 つのイーサネットフレームで転送できるパケットの最大サイズ (バイト単位) が決まります。詳細については、Amazon Redshift Cluster Management Guide の「データベースへの接続が中断された」を参照してください。

データベースへの接続がタイムアウトした

COPY コマンドなどの長いクエリを実行すると、データベースへのクライアント接続がハングまたはタイムアウトしているように見えます。この場合、Amazon Redshift コンソールにはクエリが完了したと表示されますが、クライアントツール自体はまだクエリを実行しているように見えることがあります。接続がいつ停止したかに応じて、クエリの結果がないか、不完全になる可能性があります。この効果は、中間ネットワークコンポーネントによってアイドル接続が終了すると発生します。詳細については、Amazon Redshift Cluster Management Guide の「ファイアウォールタイムアウトの問題」を参照してください。

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 コマンドを実行すると、データが再編成され、ソート順序が維持され、パフォーマンスが復旧されます。詳細については、「テーブルのバキューム処理」を参照してください。

ロードが失敗する

データのロードが失敗する理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。

データソースが別のリージョンにある

デフォルトでは、COPY コマンドで指定された Amazon S3 バケットまたは Amazon DynamoDB テーブルは、クラスターと同じリージョンにある必要があります。データとクラスターが異なるリージョンにある場合、次のようなエラーが発生します。

Copy
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) にする必要があります。詳細については、「クエリの設計のベストプラクティス」を参照してください。

ロード操作で複数の COPY コマンドを使用する

複数の COPY コマンドを同時に使用して複数のファイルから 1 つのテーブルをロードする場合、Amazon Redshift は低速なシリアル化されたロードを実行します。この場合、1 つの COPY コマンドを使用します。

ロードデータが正しくない

COPY 操作がロードするデータが正しくない理由としては、以下が考えられます。以下に示す方法でトラブルシューティングすることをお勧めします。

一部のファイルがロードされない

結果整合性によって、Amazon S3 ListBuckets アクションを使用してリストされたファイルと 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」を参照してください。