# Amazon Aurora DSQL の使用に関する考慮事項 Amazon Aurora DSQL を使用する場合は、以下の動作を考慮してください。PostgreSQL の互換性とサポートの詳細については、「[Aurora DSQL での SQL 機能の互換性](working-with-postgresql-compatibility.md)」を参照してください。クォータと制限については、「[Amazon Aurora DSQL のクラスタークォータとデータベース制限](CHAP_quotas.md)」を参照してください。 + `DROP TABLE` コマンドを実行した後、解放されたストレージを反映されるまで、ストレージ制限の計算に時間がかかる場合があります。追加のストレージ容量が必要な場合は、「[クラスタークォータ](CHAP_quotas.md#SECTION_cluster-quotas)」を参照してクォータの更新をリクエストしてください。 + Aurora DSQL の大きなテーブルの場合、`COUNT(*)` オペレーションの代わりにシステムカタログを使用してテーブル行数を取得します。詳細については、「[Aurora DSQL でのシステムテーブルとコマンドの使用](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-systems-tables.html)」を参照してください。 + Aurora DSQL は、スキーマレベルの許可を通じてアクセス許可を管理します。管理者ユーザーは、`CREATE SCHEMA` を使用してスキーマを作成し、`GRANT USAGE ON SCHEMA` を使用して他のロールへのアクセスを許可します。管理者ユーザーはパブリックスキーマのオブジェクトを管理し、管理者以外のユーザーはユーザーが作成したスキーマ内にオブジェクトを作成します。管理者ロールは、ユーザーが作成したオブジェクトに対するアクセス許可を取得するために、自身に他のロールを付与できます。詳細については、「[データベースで SQL を使用するためのデータベースロールの許可](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-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 プランの操作](working-with-explain-plans.md)」を参照してください。 + 接続制限はクラスターレベルで管理されます。クォータの更新をリクエストするには、「[クラスタークォータ](CHAP_quotas.md#SECTION_cluster-quotas)」を参照してください。