Consideraciones para trabajar con Amazon Aurora DSQL

Los cálculos del límite de almacenamiento pueden tardar un tiempo en reflejar el almacenamiento liberado después de ejecutar un comando DROP TABLE. Si necesita capacidad de almacenamiento adicional, consulte Cuotas de clúster para solicitar actualizaciones de la cuota.

Para tablas grandes en Aurora DSQL, utilice el catálogo del sistema para recuperar el recuento de filas de la tabla en lugar de operaciones COUNT(*). Para obtener más información, consulte Uso de tablas y comandos del sistema en Aurora DSQL.

Aurora DSQL administra los permisos a través de concesiones a nivel de esquema. Los usuarios administradores crean esquemas utilizando CREATE SCHEMA y conceden acceso a otros roles utilizando GRANT USAGE ON SCHEMA. Los usuarios administradores gestionan objetos en el esquema público, mientras que los usuarios no administradores crean objetos en esquemas creados por los usuarios. El rol de administrador puede otorgarse a sí mismo cualquier otro rol para obtener permisos sobre los objetos creados por los usuarios. Para obtener más información, consulte Autorización de roles de base de datos para utilizar SQL en la base de datos.

Cuando los controladores llaman a PG_PREPARED_STATEMENTS, Aurora DSQL proporciona una vista de todo el clúster de las instrucciones preparadas en caché. Es posible que vea más instrucciones preparadas por conexión de lo esperado para el mismo clúster y el mismo rol de IAM. Aurora DSQL administra los nombres de las instrucciones de forma dinámica durante la preparación.

Cuando se conecte desde instancias de solo IPv4, asegúrese de que su cliente esté configurado para conexiones IPv4. Algunos clientes de PostgreSQL intentan conexiones IPv4 e IPv6 en modo de pila doble. Si la conexión IPv4 sufre limitaciones, el cliente puede intentar IPv6 y devolver un error NetworkUnreachable en hosts de solo IPv4. Configure su cliente para que utilice IPv4 explícitamente y así evitar este comportamiento.

Después de que un usuario administrador crea un nuevo esquema, los cambios GRANT y REVOKE se propagan a las conexiones existentes dentro del tiempo de vida de la conexión (hasta una hora). Para que surta efecto inmediato, establezca una nueva conexión después de los cambios de permiso.

En casos excepcionales de recuperación de clústeres vinculados entre varias regiones, las operaciones de recuperación automática de clústeres mantienen una alta disponibilidad, pero es posible que se produzcan errores transitorios de control de simultaneidad o de conexión. En la mayoría de los casos, solo se ve afectado un porcentaje de la carga de trabajo. Cuando encuentre estos errores transitorios, vuelva a intentar la transacción o vuelva a conectarse con su cliente.

Algunos clientes de SQL, como Datagrip, solicitan metadatos extensos del sistema para completar la información del esquema. Aurora DSQL proporciona metadatos básicos para la funcionalidad de consultas SQL. La visualización del esquema en estos clientes puede mostrar información limitada en comparación con su conjunto completo de características.

Para garantizar que las consultas reconozcan los esquemas y tablas recién creados, actualice su conexión después de crear o eliminar objetos de la base de datos. Esto incluye situaciones en las que aparecen los errores Schema Already Exists después de eliminar un esquema o al consultar objetos creados en otra conexión. Desconecte y vuelva a conectarse, o vuelva a ejecutar SET search_path para actualizar la caché del catálogo.

Para consultas complejas, utilice EXPLAIN ANALYZE VERBOSE para identificar operaciones de alta latencia y optimizar los planes de consulta. Los índices de cobertura pueden reducir significativamente los costos de DPU al permitir escaneos solo de índices en lugar de escaneos completos de tablas. Para obtener más información, consulte Trabajo con planes EXPLAIN de Aurora DSQL.

Los límites de conexión se administran a nivel del clúster. Consulte Cuotas de clúster para solicitar actualizaciones de cuotas.