Amazon Aurora DSQL の使用に関する考慮事項

DROP TABLE コマンドを実行した後、解放されたストレージを反映されるまで、ストレージ制限の計算に時間がかかる場合があります。追加のストレージ容量が必要な場合は、「クラスタークォータ」を参照してクォータの更新をリクエストしてください。

Aurora DSQL の大きなテーブルの場合、COUNT(*) オペレーションの代わりにシステムカタログを使用してテーブル行数を取得します。詳細については、「Aurora DSQL でのシステムテーブルとコマンドの使用」を参照してください。

Aurora DSQL は、スキーマレベルの許可を通じてアクセス許可を管理します。管理者ユーザーは、CREATE SCHEMA を使用してスキーマを作成し、GRANT USAGE ON SCHEMA を使用して他のロールへのアクセスを許可します。管理者ユーザーはパブリックスキーマのオブジェクトを管理し、管理者以外のユーザーはユーザーが作成したスキーマ内にオブジェクトを作成します。管理者ロールは、ユーザーが作成したオブジェクトに対するアクセス許可を取得するために、自身に他のロールを付与できます。詳細については、「データベースで SQL を使用するためのデータベースロールの許可」を参照してください。

ドライバーが PG_PREPARED_STATEMENTS を呼び出すと、Aurora DSQL はキャッシュされたプリペアドステートメントのクラスター全体のビューを提供します。同じクラスターと IAM ロールに対して、接続ごとに予想よりも多くのプリペアドステートメントが表示される場合があります。Aurora DSQL は、準備中にステートメント名を動的に管理します。

IPv4 専用インスタンスから接続する場合は、クライアントが IPv4 接続用に設定されていることを確認します。一部の PostgreSQL クライアントは、デュアルスタックモードで IPv4 と IPv6 の両方の接続を試行します。IPv4 接続でスロットリングが発生した場合、クライアントは IPv6 を試行し、IPv4 専用ホストで NetworkUnreachable エラーを返すことがあります。この動作を避けるために IPv4 を明示的に使用するようにクライアントを設定します。

管理者ユーザーが新しいスキーマを作成すると、GRANT および REVOKE の変更は接続有効期間内 (最大 1 時間) に既存の接続に伝播されます。すぐに有効にするには、アクセス許可の変更後に新しい接続を確立します。

まれに発生するマルチリージョンリンククラスター復旧シナリオでは、自動クラスター復旧オペレーションによって高可用性が維持されますが、一時的な同時実行制御または接続エラーが発生する可能性があります。ほとんどの場合、影響を受けるのはワークロードの一部のみです。このような一時的なエラーが発生した場合は、トランザクションを再試行するか、クライアントに再接続してください。

Datagrip などの一部の SQL クライアントは、スキーマ情報を入力するために広範なシステムメタデータをリクエストします。Aurora DSQL は、SQL クエリ機能のコアメタデータを提供します。これらのクライアントのスキーマ表示では、完全な機能セットと比較して、限られた情報が表示される場合があります。

クエリが新しく作成されたスキーマとテーブルを認識するようにするには、データベースオブジェクトを作成または削除した後に接続を更新します。これには、スキーマを削除した後、または別の接続で作成されたオブジェクトをクエリするときに Schema Already Exists エラーが表示されるシナリオが含まれます。切断して再接続するか、SET search_path を再度実行してカタログキャッシュを更新します。

複雑なクエリの場合は、EXPLAIN ANALYZE VERBOSE を使用して高レイテンシーオペレーションを特定し、クエリプランを最適化します。インデックスをカバーすると、完全なテーブルスキャンではなくインデックスのみのスキャンが可能になり、DPU コストを大幅に削減できます。詳細については、「Aurora DSQL EXPLAIN プランの操作」を参照してください。

接続制限はクラスターレベルで管理されます。クォータの更新をリクエストするには、「クラスタークォータ」を参照してください。