# Tareas comunes de los administradores de base de datos (DBA) para Amazon RDS para PostgreSQL
Los administradores de bases de datos (DBA) realizan una variedad de tareas cuando administran una instancia de base de datos de Amazon RDS para PostgreSQL. Si ya está familiarizado con PostgreSQL, debe conocer algunas de las diferencias importantes entre ejecutar PostgreSQL en su hardware y RDS para PostgreSQL. Por ejemplo, debido a que es un servicio administrado, Amazon RDS no permite el acceso mediante shell a las instancias de base de datos. Eso significa que no tiene acceso directo a `pg_hba.conf` y a otros archivos de configuración. En el caso de RDS para PostgreSQL, los cambios que normalmente se realizan en el archivo de configuración de PostgreSQL de una instancia local se realizan en un grupo de parámetros de base de datos personalizado asociado a la instancia de base de datos de RDS para PostgreSQL. Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Tampoco puede acceder a los archivos de registro de la misma manera que lo hace con una instancia de PostgreSQL en las instalaciones. Para obtener más información acerca de los registros, consulte [Archivos de registro de base de datos de RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
Otro ejemplo, no tiene acceso a la cuenta de `superuser` de PostgreSQL. En RDS para PostgreSQL, el rol `rds_superuser` es el más privilegiado, y se concede a `postgres` en el momento de la configuración. Ya sea que esté familiarizado con el uso de PostgreSQL en las instalaciones o completamente nuevo en RDS para PostgreSQL, le recomendamos que aprenda el rol `rds_superuser` y cómo trabajar con roles, usuarios, grupos y permisos. Para obtener más información, consulte [Descripción de los roles y permisos de PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Las siguientes son algunas tareas comunes de DBA para RDS for PostgreSQL.
**Topics**
+ [
# Intercalaciones admitidas en RDS para PostgreSQL
](PostgreSQL-Collations.md)
+ [
# Descripción de los roles y permisos de PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [
# Gestión de conexiones inactivas en PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [
# Uso de autovacuum de PostgreSQL en Amazon RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [
# Administración de recuentos de objetos altos en Amazon RDS para PostgreSQL
](PostgreSQL.HighObjectCount.md)
+ [
# Administración de la contención de TOAST OID en Amazon RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [
## Uso de mecanismos de registro admitidos por RDS for PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [
# Administración de archivos temporales con PostgreSQL
](PostgreSQL.ManagingTempFiles.md)
+ [
## Uso de pgBadger para el análisis de registros con PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [
## Uso de PGSnapper para supervisar PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [
# Gestión de conversiones personalizadas en RDS para PostgreSQL
](PostgreSQL.CustomCasts.md)
+ [
# Prácticas recomendadas para consultas paralelas en RDS para PostgreSQL
](PostgreSQL.ParallelQueries.md)
+ [
# Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Intercalaciones admitidas en RDS para PostgreSQL
Las intercalaciones son un conjunto de reglas que determinan cómo se ordenan y comparan las cadenas de caracteres almacenadas en la base de datos. Las intercalaciones desempeñan un papel fundamental en el sistema de computación y se incluyen como parte del sistema operativo. Las intercalaciones cambian con el tiempo cuando se añaden nuevos caracteres a los lenguajes o cuando cambian las reglas de ordenación.
Las bibliotecas de intercalaciones definen reglas y algoritmos específicos para una intercalación. Las bibliotecas de intercalaciones más populares utilizadas en PostgreSQL son GNU C (glibc) y los componentes de internacionalización de Unicode (ICU). De forma predeterminada, RDS para PostgreSQL utiliza la intercalación glibc, que incluye ordenaciones de caracteres Unicode para secuencias de caracteres de varios bytes.
Al crear una nueva instancia de base de datos en RDS para PostgreSQL, se comprueba en el sistema operativo la intercalación disponible. Los parámetros de PostgreSQL del comando `CREATE DATABASE` `LC_COLLATE` y `LC_CTYPE` se utilizan para especificar una intercalación, que es la intercalación predeterminada en esa base de datos. Como alternativa, también puede utilizar el parámetro `LOCALE` en `CREATE DATABASE` para establecer estos parámetros. Esto determina la intercalación predeterminada de las cadenas de caracteres de la base de datos y las reglas para clasificar los caracteres como letras, números o símbolos. También puede elegir una intercalación para utilizarla en una columna, un índice o una consulta.
RDS para PostgreSQL depende de la biblioteca glibc del sistema operativo para admitir las intercalaciones. La instancia de RDS para PostgreSQL se actualiza periódicamente con las versiones más recientes del sistema operativo. Estas actualizaciones a veces incluyen una versión más reciente de la biblioteca glibc. En raras ocasiones, las versiones más recientes de glibc cambian la ordenación o la intercalación de algunos caracteres, lo que puede provocar que los datos se ordenen de forma diferente o generar entradas de índice no válidas. Si durante una actualización detecta problemas de ordenación para la intercalación, es posible que tenga que volver a generar los índices.
Para reducir el posible impacto de las actualizaciones de glibc, RDS para PostgreSQL incluye ahora una biblioteca de intercalaciones predeterminada independiente. Esta biblioteca de intercalaciones está disponible en RDS para PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23 y versiones secundarias posteriores. Es compatible con glibc 2.26-59.amzn2 y proporciona estabilidad en la ordenación para evitar resultados de consultas incorrectos.
# Descripción de los roles y permisos de PostgreSQL
Al crear una instancia de base de datos de RDS for PostgreSQL utilizando la Consola de administración de AWS, se crea una cuenta de administrador al mismo tiempo. De forma predeterminada su nombre es `postgres`, tal y como se muestra en la siguiente captura de pantalla:
![\[La identidad de inicio de sesión predeterminada para las credenciales en la página Create database (Crear base de datos) es postgres.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Puede elegir otro nombre en lugar de aceptar el valor predeterminado (`postgres`). Si lo hace, el nombre que elija debe empezar por una letra y tener entre 1 y 16 caracteres alfanuméricos. Por simplicidad, nos referimos a esta cuenta de usuario principal por su valor predeterminado (`postgres`) en toda esta guía.
Si utiliza `create-db-instance` de la AWS CLI en lugar de la Consola de administración de AWS, crea el nombre pasándolo con el parámetro `master-username` en el comando. Para obtener más información, consulte [Creación de una instancia de base de datos de Amazon RDS](USER_CreateDBInstance.md).
Ya sea que utilice la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS y si usa el nombre predeterminado `postgres` o elige otro nombre, esta primera cuenta de usuario de la base de datos es miembro del grupo `rds_superuser` y tiene `rds_superuser` privilegios.
**Topics**
+ [
# Descripción del rol rds\$1superuser
](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [
# Control del acceso de los usuarios a la base de datos de PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [
# Delegación y control de la administración de contraseñas de usuario
](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [
# Uso de SCRAM para el cifrado de contraseñas de PostgreSQL
](PostgreSQL_Password_Encryption_configuration.md)
# Descripción del rol rds\$1superuser
En PostgreSQL, un *rol* puede definir un usuario, un grupo o un conjunto de permisos específicos concedidos a un grupo o usuario para varios objetos de la base de datos. Comandos de PostgreSQL para `CREATE USER` y `CREATE GROUP` se han sustituidos por los más generales, `CREATE ROLE` con propiedades específicas para distinguir a los usuarios de bases de datos. Un usuario de base de datos se puede concebir como un rol con el privilegio LOGIN.
**nota**
Los comandos `CREATE USER` y `CREATE GROUP` se pueden seguir utilizando. Para obtener más información, consulte [Roles de base de datos](https://www.postgresql.org/docs/current/user-manag.html) en la documentación de PostgreSQL.
El usuario `postgres` es el usuario de base de datos más privilegiado de la instancia de base de datos de RDS for PostgreSQL. Tiene las características definidas mediante la siguiente instrucción `CREATE ROLE`.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Las propiedades `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` y `VALID UNTIL 'infinity'` son las opciones predeterminadas de CREATE ROLE, a menos que se especifique lo contrario.
De forma predeterminada, `postgres` tiene privilegios otorgados al rol `rds_superuser` y permisos para crear roles y bases de datos. El rol `rds_superuser` permite al usuario `postgres` hacer lo siguiente:
+ Añadir extensiones que estén disponibles para el uso con Amazon RDS. Para obtener más información, consulte [Uso de las características de PostgreSQL admitidas por Amazon RDS para PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Cree roles para los usuarios y conceder privilegios a los usuarios. Para obtener más información, consulte [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) y [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) en la documentación de PostgreSQL.
+ Creación de bases de datos Para obtener más información, consulte [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) en la documentación de PostgreSQL.
+ Conceder privilegios de `rds_superuser` a los roles de usuario que no tengan estos privilegios y revocarlos según sea necesario. Le recomendamos que conceda este rol solo a los usuarios que realizan tareas de superusuario. En otras palabras, puede conceder este rol a los administradores de bases de datos (DBA) o a los administradores del sistema.
+ Conceda (y revoque) el rol `rds_replication` a usuarios de bases de datos que no tengan el rol `rds_superuser`.
+ Conceder (y revocar) el rol `rds_password` a usuarios de bases de datos que no tengan el rol `rds_superuser`.
+ Obtener información de estado sobre todas las conexiones de base de datos mediante la vista `pg_stat_activity`. Cuando sea necesario, `rds_superuser` puede detener cualquier conexión mediante `pg_terminate_backend` o `pg_cancel_backend`.
En la instrucción `CREATE ROLE postgres...`, se puede ver que el rol de usuario `postgres` no permite específicamente permisos `superuser` de PostgreSQL. RDS for PostgreSQL es un servicio administrado, por lo que no puede acceder al sistema operativo host y no puede conectarse con la cuenta `superuser` de PostgreSQL. Muchas de las tareas que requieren acceso `superuser` en un PostgreSQL independiente se administra automáticamente mediante Amazon RDS.
Para obtener más información sobre la concesión de privilegios, consulte [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) en la documentación de PostgreSQL.
El rol `rds_superuser` es uno de varios roles *predefinidos* en un Instancia de base de datos RDS for PostgreSQL.
**nota**
En PostgreSQL 13 y versiones anteriores, los roles *predefinidos* se denominan roles *predeterminados*.
En la siguiente lista encontrará algunos de los otros roles predefinidos que se crean automáticamente para un nuevo Instancia de base de datos RDS para PostgreSQL. Los roles predefinidos y sus privilegios no se pueden cambiar. No se pueden eliminar, cambiar de nombre ni modificar los privilegios de estos roles predefinidos. Intentar realizar una de estas operaciones producirá un error.
+ **rds\$1password**: rol que puede cambiar las contraseñas y configurar restricciones de contraseña para los usuarios de bases de datos. Al rol `rds_superuser` se le otorga este rol de forma predeterminada y puede otorgarlo a los usuarios de la base de datos. Para obtener más información, consulte [Control del acceso de los usuarios a la base de datos de PostgreSQLControl del acceso de los usuarios a PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ En las versiones de RDS para PostgreSQL anteriores a la 14, el rol `rds_password` puede cambiar las contraseñas y establecer restricciones de contraseña para los usuarios de la base de datos y los usuarios con el rol `rds_superuser`. A partir de la versión 14 de RDS para PostgreSQL, el rol `rds_password` puede cambiar las contraseñas y establecer restricciones de contraseña solo para los usuarios de la base de datos. Solo los usuarios con el rol `rds_superuser` pueden realizar estas acciones en otros usuarios con el rol `rds_superuser`.
+ **rdsadmin**: rol creado para administrar muchas de las tareas de administración que el administrador con privilegios de `superuser` realizaría en una base de datos PostgreSQL independiente. Este rol lo utiliza internamente RDS for PostgreSQLpara muchas tareas de administración.
+ **rdstopmgr**: rol que Amazon RDS utiliza internamente para admitir implementaciones multi-AZ.
+ **rds\$1reserved**: función que Amazon RDS utiliza internamente para reservar conexiones a bases de datos.
# Visualización los de roles y sus privilegios
Puede ver los roles predefinidos y sus privilegios en la instancia de base de datos de RDS para PostgreSQL mediante distintos comandos en función de la versión de PostgreSQL. Para ver todos los roles predefinidos, puede conectarse a la instancia de base de datos de RDS para PostgreSQL y ejecutar los siguientes comandos con `psql`.
**Para `psql` 15 y versiones anteriores**
Conéctese a la instancia de base de datos de RDS para PostgreSQL y use el comando `\du` en psql:
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Para `psql` 16 y versiones posteriores**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Para comprobar la pertenencia al rol sin dependencia de versiones, puede utilizar la siguiente consulta SQL:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
En la salida, puede ver que `rds_superuser` no es un rol de usuario de base de datos (no puede iniciar sesión), pero tiene los privilegios de muchos otros roles. También puede ver que el usuario de la base de datos `postgres` es miembro del rol `rds_superuser`. Como se ha mencionado anteriormente, `postgres` es el valor predeterminado de **Create database (Crear base de datos)** de la consola de Amazon RDS. Si ha elegido otro nombre, ese nombre se muestra en la lista de roles.
# Control del acceso de los usuarios a la base de datos de PostgreSQL
Las nuevas bases de datos de PostgreSQL siempre se crean con un conjunto predeterminado de privilegios en el esquema `public` de la base de datos que permite a todos los usuarios y roles de la base de datos crear objetos. Estos privilegios permiten a los usuarios de la base de datos conectarse a la base de datos, or ejemplo, y crear tablas temporales mientras están conectados.
Para controlar mejor el acceso de los usuarios a las instancias de bases de datos que cree en su instancia de base de datos de RDS for PostgreSQL, le recomendamos que revoque estos privilegios de `public` predeterminados. Después de ello, conceda a continuación los privilegios específicos a los usuarios de base de datos de forma más detallada, como se muestra en el siguiente procedimiento.
**Para configurar roles y privilegios para una nueva instancia de base de datos**
Supongamos que está configurando una base de datos en Instancia de base de datos de RDS for PostgreSQL de reciente creación para que lo utilicen varios investigadores, todos los cuales necesitan acceso de lectura y escritura a la base de datos.
1. Use `psql` (o pgAdmin) para conectarse a su instancia de base de datos de RDS for PostgreSQL:
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Escriba la contraseña cuando se le solicite. El cliente `psql` se conecta y muestra la base de datos de conexión administrativa predeterminada, `postgres=>`, como el símbolo del sistema.
1. Para evitar que los usuarios de la base de datos creen objetos en el esquema `public`, realice una de las siguientes opciones:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. A continuación, cree una nueva instancia de base de datos:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Revoque todos los privilegios del esquema `PUBLIC` de esta nueva base de datos.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Cree un rol para los usuarios de bases de datos.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Otorgue a los usuarios de bases de datos que tengan este rol la posibilidad de conectarse a la base de datos.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Conceda a todos los usuarios que tengan el rol `lab_tech` todos los privilegios de esta base de datos.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Cree usuarios de bases de datos de la siguiente manera:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Conceda a estos dos usuarios los privilegios asociados al rol lab\$1tech:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
En este punto,`lab_user1` y `lab_user2` se pueden conectar a la base de datos de `lab_db`. En este ejemplo no se siguen las prácticas recomendadas para el uso empresarial, que pueden incluir la creación de varias instancias de base de datos, distintos esquemas y la concesión de permisos limitados. Para obtener más información y escenarios adicionales, consulte [Administración de usuarios y roles de PostgreSQL](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Para obtener más información sobre los privilegios en las bases de datos de PostgreSQL, consulte el comando [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) en la documentación de PostgreSQL.
# Delegación y control de la administración de contraseñas de usuario
Como DBA, es posible que desee delegar la administración de contraseñas de usuario. O bien, puede que desee evitar que los usuarios de la base de datos cambien sus contraseñas o reconfiguren las restricciones de contraseña, como la duración de la contraseña. Para asegurarse de que solo los usuarios de la base de datos que elija puedan cambiar la configuración de contraseñas, puede activar la función de administración de contraseñas restringidas. Cuando activa esta función, solo pueden administrar contraseñas aquellos usuarios de base de datos a los que se les haya concedido el rol `rds_password`.
**nota**
Para utilizar la administración de contraseñas restringida, su instancia de base de datos RDS for PostgreSQL debe estar ejecutando para 10.6 o una versión posterior.
De forma predeterminada, esta función es `off`, tal y como se muestra en el ejemplo siguiente:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Para activar esta función, utilice un grupo de parámetros personalizado y cambie la configuración de `rds.restrict_password_commands` a 1. Asegúrese de reiniciar su Instancia de base de datos de RDS for PostgreSQL para que la configuración surta efecto.
Con esta función activa, se necesitan privilegios de `rds_password` para los siguientes comandos SQL:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Cambiar el nombre de un rol (`ALTER ROLE myrole RENAME TO newname`) también está restringido si la contraseña utiliza el algoritmo hash MD5.
Con esta función activa, intentar cualquiera de estos comandos SQL sin los permisos de rol `rds_password`, genera el siguiente error:
```
ERROR: must be a member of rds_password to alter passwords
```
Recomendamos que otorgar el `rds_password` solamente a unos cuantos roles que utilice únicamente para la administración de contraseñas. Si concede privilegios de `rds_password` a usuarios de bases de datos que no tengan privilegios de `rds_superuser`, también debe otorgarles el atributo `CREATEROLE`.
Asegúrese de que comprueba los requisitos de las contraseñas del lado del cliente, como el vencimiento y la complejidad necesaria. Si utiliza su propia utilidad del lado del cliente para cambios relacionados con la contraseña, la utilidad debe ser miembro de `rds_password` tener privilegios de `CREATE ROLE`.
# Uso de SCRAM para el cifrado de contraseñas de PostgreSQL
El mecanismo de autenticación mediante *desafío-respuesta discontinuo (SCRAM)* es una alternativa al algoritmo de resumen de mensajes (MD5) predeterminado de PostgreSQL para cifrar contraseñas. El mecanismo de autenticación SCRAM se considera más seguro que MD5. Para obtener más información sobre estos dos enfoques diferentes para proteger las contraseñas, consulte [Password Authentication](https://www.postgresql.org/docs/14/auth-password.html) (Autenticación de contraseñas) en la documentación de PostgreSQL.
Le recomendamos que utilice SCRAM en lugar de MD5 como esquema de cifrado de contraseñas para su . Instancia de base de datos RDS para PostgreSQL. Es un mecanismo criptográfico de desafío-respuesta que utiliza el algoritmo scram-sha-256 algorithm para la autenticación y el cifrado de contraseñas.
Es posible que deba actualizar las bibliotecas de las aplicaciones cliente para que sean compatibles con SCRAM. Por ejemplo, las versiones de JDBC anteriores a la 42.2.0 no admiten SCRAM. Para obtener más información, consulte [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) (Controlador JDBC de PostgreSQL) en la documentación del controlador JDBC de PostgreSQL. Para ver una lista de otros controladores de PostgreSQL y la compatibilidad con SCRAM, consulte [List of drivers](https://wiki.postgresql.org/wiki/List_of_drivers) (Lista de controladores) en la documentación de PostgreSQL.
RDS para PostgreSQL versión 13.1 y posteriores admite scram-sha-256. Estas versiones también le permiten configurar la instancia de la base de datos para que requiera SCRAM, como se explica en los siguientes procedimientos.
## Configuración de la instancia de base de datos de RDS para PostgreSQL para que requiera SCRAM
puede requerir que la instancia de RDS para PostgreSQL DB acepte únicamente contraseñas que utilicen el algoritmo scram-sha-256.
**importante**
En el caso de los proxies RDS existentes con bases de datos de PostgreSQL, si modifica la autenticación de la base de datos para utilizar únicamente `SCRAM`, el proxy dejará de estar disponible durante un máximo de 60 segundos. Para evitar este problema, lleve a cabo alguna de las siguientes operaciones:
Asegúrese de que la base de datos permita la autenticación `SCRAM` y `MD5`.
Para utilizar únicamente la autenticación `SCRAM`, cree un nuevo proxy, migre el tráfico de la aplicación al nuevo proxy y, a continuación, elimine el proxy previamente asociado a la base de datos.
Antes de realizar cambios en el sistema, asegúrese de entender el proceso completo, como se indica a continuación:
+ Obtenga información sobre todos los roles y el cifrado de las contraseñas de todos los usuarios de la base de datos.
+ Compruebe de nuevo la configuración de los parámetros de la instancia de base de datos de Aurora correspondiente a los parámetros que controlan el cifrado de las contraseñas.
+ Si la instancia de base de datos de RDS para PostgreSQL utiliza un grupo de parámetros predeterminado, deberá crear un grupo de parámetros de base de datos personalizado y aplicarlo a la instancia de base de datos de RDS para PostgreSQL para poder modificar los parámetros cuando sea necesario. Si la instancia de base de datos de RDS para PostgreSQL utiliza un grupo de parámetros personalizado, puede modificar los parámetros necesarios más adelante en el proceso, según sea necesario.
+ Cambie el parámetro `password_encryption` por `scram-sha-256`.
+ Notifique a todos los usuarios de la base de datos que deben actualizar las contraseñas. Haga lo mismo con su cuenta de `postgres`. Las nuevas contraseñas se cifran y almacenan mediante el algoritmo scram-sha-256.
+ Verifique que todas las contraseñas están cifradas con el tipo de cifrado.
+ Si todas las contraseñas utilizan scram-sha-256, puede cambiar el parámetro `rds.accepted_password_auth_method` de `md5+scram` a `scram-sha-256`.
**aviso**
Después de cambiar `rds.accepted_password_auth_method` a scram-sha-256 únicamente, no podrá conectarse ningún usuario (rol) con una contraseña cifrada con `md5`.
### Preparación para requerir SCRAM para su instancia de base de datos de RDS para PostgreSQL
Antes de realizar cambios en la instancia de RDS para PostgreSQL, compruebe todas las cuentas de usuario de base de datos existentes. Compruebe también el tipo de cifrado utilizado para las contraseñas. Puede hacer estas tareas con la extensión `rds_tools`. Para ver qué versiones de PostgreSQL son compatibles con `rds_tools`, consulte [Versiones de extensión para Amazon RDS para PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**Para obtener una lista de usuarios de base de datos (roles) y métodos de cifrado de contraseñas**
1. Use `psql` para conectarse a la instancia de base de datos de RDS para PostgreSQL, tal como se muestra a continuación.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Instale la extensión de `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Obtenga una lista de los roles y el cifrado.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Se muestra una salida similar a la siguiente.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Creación de un grupo de parámetros de base de datos personalizado
**nota**
Si la instancia de base de datos de RDS para PostgreSQL ya utiliza un grupo de parámetros personalizado, no necesita crear uno nuevo.
Para obtener información general sobre los grupos de parámetros para Amazon RDS, consulte [Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
El tipo de cifrado de contraseñas que se usa para las contraseñas se establece a un parámetro, `password_encryption`. El cifrado que permite la instancia de base de datos de RDS para PostgreSQL se establece a otro parámetro, `rds.accepted_password_auth_method`. Para cambiar cualquiera de los valores predeterminados, es necesario crear un grupo de parámetros de base de datos personalizado y aplicarlo a la instancia.
También puede utilizar la Consola de administración de AWS o la API de RDS para crear un grupo de parámetros de base de datos personalizado. Para obtener más información, consulte
Ahora puede asociar el grupo de parámetros personalizado con su instancia de base de datos.
**Para crear un grupo de parámetros de base de datos personalizado**
1. Utilice el comando `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` de la CLI para crear el grupo de parámetros de base de datos personalizado. En este ejemplo se utiliza `postgres13` como origen de este grupo de parámetros personalizado.
Para Linux, macOS o Unix:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Para Windows:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Utilice el comando `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` de la CLI para aplicar este grupo de parámetros personalizado al clúster de base de datos de RDS para PostgreSQL.
Para Linux, macOS o Unix:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Para Windows:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Para volver a sincronizar la instancia de base de datos de RDS para PostgreSQL con el grupo de parámetros de base de datos personalizado, debe reiniciar la instancia principal y todas las demás instancias del clúster. Para minimizar el impacto en sus usuarios, programe esto para que se produzca durante su periodo de mantenimiento regular.
### Configuración del cifrado de contraseñas para utilizar SCRAM
El mecanismo de cifrado de contraseñas que utiliza una instancia de base de datos de RDS para PostgreSQL se establece en el grupo de parámetros de base de datos en el parámetro `password_encryption`. Los valores permitidos son: no establecido, `md5` o `scram-sha-256`. El valor predeterminado depende de la versión de RDS para PostgreSQL del modo que se indica a continuación:
+ RDS para PostgreSQL 14 y versiones posteriores: el valor predeterminado es `scram-sha-256`
+ RDS para PostgreSQL 13: el valor predeterminado es `md5`
Con un grupo de parámetros de base de datos personalizado adjuntado a la instancia de base de datos de RDS para PostgreSQL, puede modificar los valores del parámetro de cifrado de contraseñas.
![\[A continuación, la consola de RDS muestra los valores predeterminados de los parámetros password_encryption de RDS para PostgreSQL.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**Para cambiar la configuración de cifrado de contraseñas a scram-sha-256**
+ Cambie el valor del cifrado de contraseñas a scram-sha-256, como se muestra a continuación. El cambio se puede aplicar inmediatamente porque el parámetro es dinámico, por lo que no se requiere un reinicio para que el cambio surta efecto.
Para Linux, macOS o Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Para Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migración de las contraseñas de los roles de usuario a SCRAM
Puede migrar las contraseñas de los roles de usuario a SCRAM, tal y como se describe a continuación.
**Para migrar las contraseñas de usuario (rol) de base de datos de MD5 a SCRAM**
1. Inicie sesión como usuario administrador (nombre de usuario predeterminado, `postgres`) como se muestra a continuación.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Compruebe la configuración del parámetro `password_encryption` en la instancia de base de datos de RDS para PostgreSQL con el siguiente comando.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Cambie el valor de este parámetro a scram-sha-256. Para obtener más información, consulte [Configuración del cifrado de contraseñas para utilizar SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Compruebe de nuevo el valor para asegurarse de que ahora está establecido en `scram-sha-256`, como se indica a continuación.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Notifique a todos los usuarios de base de datos que deben cambiar la contraseña. Asegúrese de cambiar también su propia contraseña para la cuenta `postgres` (el usuario de base de datos con privilegios `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Repita el proceso para todas las bases de datos del Instancia de base de datos RDS para PostgreSQL.
### Cambio del parámetro para requerir SCRAM
Este es el último paso del proceso. Después de realizar el cambio en el siguiente procedimiento, ninguna cuenta de usuario (rol) que aún utilice el cifrado `md5` para las contraseñas podrá iniciar sesión en el . Instancia de base de datos RDS para PostgreSQL.
Con `rds.accepted_password_auth_method` se especifica el método de cifrado que la instancia de base de datos de RDS para PostgreSQL acepta una contraseña de usuario durante el proceso de inicio de sesión. El valor predeterminado es `md5+scram`, lo que significa que se acepta cualquiera de los dos métodos. En la siguiente imagen, puede encontrar la configuración predeterminada de este parámetro.
![\[Consola de RDS con los valores predeterminados y permitidos para los parámetros rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
Los valores permitidos para este parámetro son:`md5+scram` o `scram` solo. El cambio de este valor de parámetro a `scram` lo convierte en un requisito.
**Para cambiar el valor de parámetro para requerir la autenticación SCRAM para las contraseñas**
1. Verifique que todas las contraseñas de los usuarios de base de datos de la instancia de base de datos de RDS para PostgreSQL utilizan `scram-sha-256` para el cifrado de contraseña. Para ello, consulte `rds_tools` para el rol (usuario) y el tipo de cifrado, de la siguiente manera.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Repita la consulta en todas las instancias de base de datos del Instancia de base de datos RDS para PostgreSQL.
Si todas las contraseñas usan scram-sha-256, puede continuar.
1. Cambie el valor de la autenticación de contraseña aceptada a scram-sha-256, como se indica a continuación.
Para Linux, macOS o Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Para Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Gestión de conexiones inactivas en PostgreSQL
Las conexiones inactivas se producen cuando una sesión de base de datos permanece activa en el servidor a pesar de que la aplicación cliente se haya abandonado o terminado de forma anormal. Esta situación suele producirse cuando los procesos del cliente se bloquean o terminan de forma inesperada sin cerrar correctamente las conexiones de la base de datos ni cancelar las solicitudes en curso.
PostgreSQL identifica y limpia de manera eficiente las conexiones inactivas cuando los procesos del servidor están inactivos o intentan enviar datos a los clientes. Sin embargo, la detección es difícil en el caso de las sesiones que están inactivas, esperan la intervención del cliente o en las que se están ejecutando consultas de forma activa. Para gestionar estos escenarios, PostgreSQL proporciona los parámetros `tcp_keepalives_*`, `tcp_user_timeout`, y `client_connection_check_interval`.
**Topics**
+ [
## Descripción de keepalive de TCP
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [
## Parámetros clave keepalive de TCP en RDS para PostgreSQL
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [
## Casos de uso de la configuración de keepalive de TCP
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [
## Prácticas recomendadas
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Descripción de keepalive de TCP
Keepalive de TCP es un mecanismo en el nivel de protocolo que ayuda a mantener y verificar la integridad de la conexión. Cada conexión TCP mantiene configuraciones en el nivel del kernel que rigen el comportamiento de keepalive. Cuando el temporizador de keepalive expira, el sistema realiza lo siguiente:
+ Envía un paquete de sondeo sin datos y con el indicador ACK activado.
+ Espera una respuesta del punto de conexión remoto de acuerdo con las especificaciones de TCP/IP.
+ Administra el estado de la conexión en función de la respuesta o la falta de respuesta.
## Parámetros clave keepalive de TCP en RDS para PostgreSQL
| Parámetro | Descripción | Valores predeterminados |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Specifies number of seconds of inactivity before sending keepalive message. | 300 |
| tcp\$1keepalives\$1interval | Specifies number of seconds between retransmissions of unacknowledged keepalive messages. | 30 |
| tcp\$1keepalives\$1count | Maximum lost keepalive messages before declaring connection dead | 2 |
| tcp\$1user\$1timeout | Specifies how long (in Milliseconds) unacknowledged data can remain before forcibly closing the connection. | 0 |
| client\$1connection\$1check\$1interval | Sets the interval (in Milliseconds) for checking client connection status during long-running queries. This ensures quicker detection of closed connections. | 0 |
## Casos de uso de la configuración de keepalive de TCP
### Mantenimiento de las sesiones inactivas como activas
Para evitar que los firewalls o enrutadores terminen las conexiones inactivas debido a la inactividad:
+ Configure `tcp_keepalives_idle` para enviar paquetes de keepalive a intervalos regulares.
### Detección de conexiones inactivas
Para detectar rápidamente las conexiones inactivas:
+ Ajuste `tcp_keepalives_idle`, `tcp_keepalives_interval` y `tcp_keepalives_count`. Por ejemplo, con los valores predeterminados de Aurora PostgreSQL, se tarda aproximadamente un minuto (2 sondas × 30 segundos) en detectar una conexión inactiva. Reducir estos valores puede acelerar la detección.
+ Utilice `tcp_user_timeout` para especificar el tiempo máximo de espera para una confirmación.
La configuración de keepalive de TCP ayuda al kernel a detectar conexiones inactivas, pero PostgreSQL puede no actuar hasta que se utilice el socket. Si una sesión está ejecutando una consulta larga, es posible que las conexiones inactivas solo se detecten una vez completada la consulta. En PostgreSQL 14 y versiones posteriores, `client_connection_check_interval` puede acelerar la detección de conexiones inactivas consultando periódicamente el socket durante la ejecución de la consulta.
## Prácticas recomendadas
+ **Establezca intervalos de keepalive razonables:** ajuste `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` y `tcp_keepalives_interval` para equilibrar la velocidad de detección y el uso de recursos.
+ **Optimice para su entorno:** alinee la configuración con el comportamiento de la red, las políticas de firewall y las necesidades de la sesión.
+ **Aproveche las características de PostgreSQL**: utilice `client_connection_check_interval` en PostgreSQL 14 y versiones posteriores para comprobar la conexión de forma eficaz.
# Uso de autovacuum de PostgreSQL en Amazon RDS para PostgreSQL
Le recomendamos que use la característica autovacuum para mantener en buen estado su instancia de base de datos de PostgreSQL. Autovacuum automatiza el comienzo de los comandos VACUUM y ANALYZE. Comprueba las tablas con una gran cantidad de tuplas insertadas, actualizadas o eliminadas. Después de esta verificación, recupera el almacenamiento mediante la eliminación de datos obsoletos o tuplas de la base de datos de PostgreSQL.
De forma predeterminada, autovacuum está activado para las instancias de base de datos de RDS para PostgreSQL que crea por medio de cualquiera de los grupos de parámetros de base de datos de PostgreSQL predeterminados. Otros parámetros de configuración asociados con la característica autovacuum también se establecen de forma predeterminada. Debido a que estos valores predeterminados son algo genéricos, puede beneficiarse de ajustar algunos de los parámetros asociados con la característica autovacuum para su carga de trabajo específica.
A continuación, puede encontrar más información sobre autovacuum y cómo ajustar algunos de sus parámetros en la instancia de base de datos de RDS para PostgreSQL. Para obtener información más específica, consulte [Prácticas recomendadas para trabajar con PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [
## Asignación de memoria para autovacuum
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [
## Reducción de la probabilidad de reinicio del identificador de transacción
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [
# Determinar si las tablas de una base de datos necesitan vacío
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [
# Determinar qué tablas cumplen actualmente los requisitos de autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [
# Determinar si autovacuum se está ejecutando actualmente y durante cuánto tiempo
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [
# Realización de una inmovilización de vacío manual
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [
# Reindexar una tabla cuando autovacuum se está ejecutando
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [
# Administración de autovacuum con índices de gran tamaño
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [
# Otros parámetros que afectan a autovacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [
# Establecimiento de parámetros autovacuum de nivel de tabla
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [
# Registro de actividades de autovacuum y vacuum
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [
# Comportamiento de autovacuum con bases de datos no válidas
](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [
# Identificación y resolución de los bloqueadores de vaciado intensivo en RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Asignación de memoria para autovacuum
Uno de los parámetros más importantes que afectan al desempeño de autovacuum es el parámetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). En las versiones 14 y anteriores de RDS para PostgreSQL, el parámetro `autovacuum_work_mem` se establece en -1, lo que indica que en su lugar se utiliza la configuración de `maintenance_work_mem`. En todas las demás versiones, `autovacuum_work_mem` se determina mediante GREATEST(\$1DBInstanceClassMemory/32768\$1, 65536).
Las operaciones de limpieza manual siempre utilizan la configuración de `maintenance_work_mem`, con la configuración predeterminada de GREATEST (\$1DBInstanceClassMemory/63963136\$11024\$1, 65536), y también se puede ajustar en la sesión mediante el comando `SET` para operaciones manuales de `VACUUM` más específicas.
`autovacuum_work_mem` determina que la memoria de autovacuum conserve los identificadores de tuplas inactivas (`pg_stat_all_tables.n_dead_tup`) para los índices de limpieza.
Cuando realice los cálculos para determinar el valor del parámetro `autovacuum_work_mem`, tenga en cuenta lo siguiente:
+ Si define el parámetro en un valor demasiado bajo, el proceso de limpieza puede tener que examinar la tabla varias veces para completar su trabajo. Esta variedad de análisis puede tener un impacto negativo en el rendimiento. Para instancias mayores, configurar `maintenance_work_mem` o `autovacuum_work_mem` a 1 GB como mínimo puede mejorar el rendimiento de las tablas de limpieza con un número elevado de tuplas inactivas. Sin embargo, en las versiones 16 y anteriores de PostgreSQL, el uso de memoria de la operación de limpieza está limitado a 1 GB, que es suficiente para procesar aproximadamente 179 millones de tuplas inactivas de una sola pasada. Si una tabla tiene más tuplas inactivas que las indicadas, la operación de limpieza tendrá que realizar varias pasadas por los índices de la tabla, lo que aumentará considerablemente el tiempo necesario. A partir de la versión 17 de PostgreSQL, no hay un límite de 1 GB y autovacuum puede procesar más de 179 millones de tuplas mediante árboles radix.
Un identificador de tupla tiene un tamaño de 6 bytes. Con el fin de calcular la memoria necesaria para limpiar un índice de una tabla, realice una consulta a `pg_stat_all_tables.n_dead_tup` para buscar el número de tuplas inactivas y, a continuación, multiplique este número por 6 para determinar la memoria necesaria para limpiar el índice de una sola pasada. Puede utilizar la siguiente consulta:
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ El parámetro `autovacuum_work_mem` funciona en combinación con el parámetro `autovacuum_max_workers`. Cada empleado de `autovacuum_max_workers` puede utilizar la memoria que asigne. Si tiene demasiadas tablas pequeñas, asigne más `autovacuum_max_workers` y menos `autovacuum_work_mem`. Si tiene tablas grandes (de 100 GB o más), asigne más memoria y menos procesos de trabajo. Debe tener suficiente memoria asignada para que funcione en la tabla más grande. Por lo tanto, asegúrese de que la combinación de procesos de trabajo y memoria sea igual a la memoria total que desea asignar.
## Reducción de la probabilidad de reinicio del identificador de transacción
En algunos casos, la configuración de grupos de parámetros relacionada con autovacuum puede no ser lo suficientemente agresiva como para evitar el reinicio del identificador de transacción. Para solucionar esto, RDS para PostgreSQL proporciona un mecanismo que adapta los valores de los parámetros de autovacuum automáticamente. *Autovacuum adaptativo* es una característica para RDS para PostgreSQL. Puede encontrar una explicación detallada sobre el [reinicio del identificador de transacción](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) en la documentación de PostgreSQL.
Autovacuum adaptativo está activado de forma predeterminada para las instancias de RDS para PostgreSQL con el parámetro dinámico `rds.adaptive_autovacuum` establecido en Activado. Le recomendamos encarecidamente que mantenga esta opción activada. Sin embargo, para apagar el ajuste de parámetros autovacuum adaptativo, establezca el parámetro `rds.adaptive_autovacuum` en 0 u OFF.
El reinicio de ID de transacción sigue siendo posible incluso cuando Amazon RDS Amazon RDS ajusta los parámetros de autovacuum. Le animamos a implementar una alarma Amazon CloudWatch para el reinicio de identificador de transacción. Para obtener más información, consulte la publicación [Implement an early warning system for transaction ID wraparound in RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) (Implementar un sistema de alerta temprana para el ajuste de ID de transacción en RDS for PostgreSQL) en el Blog de Base de datos de AWS.
Con el ajuste de parámetros de autovacuum adaptable activado, Amazon RDS comienza a ajustar los parámetros de autovacuum cuando la métrica de CloudWatch `MaximumUsedTransactionIDs` alcanza el valor del parámetro `autovacuum_freeze_max_age` o 500 000 000, el que sea mayor.
Amazon RDS continúa ajustando los parámetros para el autovacuum si una tabla continúa tendiendo hacia el ajuste de ID de transacción. Cada uno de estos ajustes dedica más recursos a autovacuum para evitar el reinicio. Amazon RDS actualiza los siguientes parámetros relacionados con autovacuum:
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS modifica estos parámetros solo si el nuevo valor hace que autovacuum sea más agresivo. Estos parámetros se modifican en la memoria en la instancia de base de datos. Los valores en el grupo de parámetros no han cambiado. Para ver la configuración en memoria actual, utilice el comando de SQL PostgreSQL [SHOW](https://www.postgresql.org/docs/current/sql-show.html) de PostgreSQL.
Cuando Amazon RDS modifica alguno de estos parámetros de autovacuum, genera un evento para la instancia de base de datos afectada. Este evento se puede ver en la Consola de administración de AWS y a través de la API de Amazon RDS. Una vez que la métrica CloudWatch `MaximumUsedTransactionIDs` vuelve por debajo del límite, Amazon RDS restablece los parámetros relacionados con el autovacuum en la memoria a los valores especificados en el grupo de parámetros. Luego, genera otro evento correspondiente a este cambio.
# Determinar si las tablas de una base de datos necesitan vacío
Puede utilizar la siguiente consulta para mostrar el número de transacciones descongeladas en una base de datos. La columna `datfrozenxid` de una fila `pg_database` de una base de datos es un límite inferior en los identificadores de transacción normales que aparecen en esa base de datos. Esta columna es el mínimo de los valores `relfrozenxid` por tabla dentro de la base de datos.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Por ejemplo, los resultados de ejecutar la consulta anterior podrían ser los siguientes.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Cuando la antigüedad de una base de datos llega a los dos mil millones de identificadores de transacción, se produce el reinicio de los TransactionID (XID) y la base de datos cambia al modo de solo lectura. Puede usar esta consulta para generar una métrica y ejecutarla varias veces al día. De manera predeterminada, autovacuum está configurado para mantener la antigüedad de las transacciones en un máximo de 200,000,000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Una estrategia de monitorización de muestra podría ser la siguiente:
+ Establezca el valor `autovacuum_freeze_max_age` en 200 millones de transacciones.
+ Si una tabla llega a 500 millones de transacciones descongeladas, se dispara una alarma de gravedad baja. No es un valor disparatado, pero podría indicar que autovacuum no puede mantener el ritmo.
+ Si una tabla llega a mil millones, se debe interpretar como una alarma para adoptar medidas. En general, conviene mantener las antigüedades más cerca de `autovacuum_freeze_max_age` por motivos de rendimiento. Le recomendamos que investigue utilizando las recomendaciones que siguen.
+ Si una tabla llega a 1500 millones de transacciones sin vaciar, se dispara una alarma de gravedad alta. En función de la velocidad con la que la base de datos use los identificadores de transacción, esta alarma puede indicar que el sistema está agotando el tiempo para ejecutar autovacuum. En ese caso, le recomendamos una solución inmediata.
Si una tabla supera constantemente estos límites, modifique aún más sus parámetros de autovacuum. De manera predeterminada, usar VACUUM manualmente (que tiene deshabilitados los retardos basados en el costo) es un procedimiento más agresivo que usar el autovacuum predeterminado, pero es también más intrusivo para el sistema en su conjunto.
Le recomendamos lo siguiente:
+ Esté atento y active un mecanismo de supervisión para que esté al tanto de la antigüedad de sus transacciones.
A fin de obtener información acerca de la creación de un proceso que advierta sobre el reinicio del ID de transacción, consulte la publicación de blog de la base de datos de AWS sobre la [implementación de un sistema de advertencia temprana para el reinicio de un ID de transacción en Amazon RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/).
+ Para las tablas con más actividad, lleve a cabo una inmovilización manual de vacío con regularidad durante una ventana de mantenimiento además de confiar en autovacuum. Para obtener información acerca de la ejecución de una inmovilización de vacío manual, consulte [Realización de una inmovilización de vacío manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Determinar qué tablas cumplen actualmente los requisitos de autovacuum
A menudo, hay una o dos tablas que necesitan vacío. Autovacuum se dirige siempre a las tablas cuyo valor `relfrozenxid` sea superior al número de transacciones en `autovacuum_freeze_max_age`. De lo contrario, si el número de tuplas obsoletas desde el último VACUUM supera el límite de vacío, la tabla se vacía.
El [umbral de autovacuum](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) se define como:
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
donde el `vacuum base threshold` es `autovacuum_vacuum_threshold`, el `vacuum scale factor` es `autovacuum_vacuum_scale_factor` y el `number of tuples` es `pg_class.reltuples`.
Mientras está conectado a la base de datos, ejecute la siguiente consulta para ver una lista de tablas que autovacuum considera aptas para el vacío.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Determinar si autovacuum se está ejecutando actualmente y durante cuánto tiempo
Si necesita aspirar manualmente una tabla, asegúrese de determinar si el autovacuum se está ejecutando actualmente. Si es así, es posible que deba ajustar los parámetros para que funcione de manera más eficiente o desactivar el autovacuum temporalmente para que pueda ejecutar manualmente VACUUM.
Use la siguiente consulta para determinar si se está ejecutando autovacuum, cuánto tiempo lleva en ejecución y si se encuentra en espera en otra sesión.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Después de ejecutar la consulta, debería ver un resultado similar al siguiente.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Existen varios problemas que pueden provocar una sesión de autovaccum de larga duración (es decir, que tarde varios días). El problema más común es que el valor del parámetro [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) sea demasiado bajo para el tamaño de la tabla o la velocidad de las actualizaciones.
Le recomendamos que utilice la siguiente fórmula para establecer el valor del parámetro `maintenance_work_mem`.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
Las sesiones de autovacuum con una duración corta también pueden indicar problemas:
+ Pueden indicar que no hay un número de `autovacuum_max_workers` suficientemente alto para la carga de trabajo. En ese caso, tendrá que especificar el número de procesos de trabajo.
+ Puede indicar que hay una corrupción de índice (autovacuum falla y se reinicia en la misma relación pero no avanza). En este caso, ejecute un manual `vacuum freeze verbose table` para ver la causa exacta.
# Realización de una inmovilización de vacío manual
Puede ocurrir que desee realizar una operación de vacío manual en una tabla que ya tenga un proceso de vacío en ejecución. Esto resulta útil si se ha identificado una tabla con una antigüedad cercana a dos mil millones de transacciones (o por encima del umbral que esté monitorizando).
Los siguientes pasos son pautas, con varias variaciones en el proceso. Por ejemplo, durante las pruebas, suponga que descubre que el parámetro [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) se definió en un valor demasiado bajo y que tiene que adoptar medidas de forma inmediata en una tabla. Sin embargo, quizás no desea rebotar la instancia en ese momento. Con las consultas de las secciones anteriores, puede determinar qué tabla está causando el problema y comprobar que hay una sesión de autovacuum que lleva mucho tiempo en ejecución. Sabe que tiene que cambiar el ajuste del parámetro `maintenance_work_mem`, pero también tiene que adoptar medidas de inmediato y aplicar el vacío en la tabla afectada. El siguiente procedimiento muestra qué hacer en esa situación.
**Para realizar manualmente una inmovilización de vacío**
1. Abra dos sesiones en la base de datos que contiene la tabla en la que desea ejecutar el vacío. Para la segunda sesión, use "screen" u otra utilidad que mantenga la sesión activa si se interrumpe la conexión.
1. En la sesión uno, obtenga el ID de proceso (PID) de la sesión de autovacuum que se ejecuta en la tabla.
Ejecute la siguiente consulta para obtener el PID de la sesión de autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. En la sesión dos, calcule la cantidad de memoria que necesitará para esta operación. En este ejemplo, determinamos que podemos permitirnos usar un máximo de 2 GB de memoria para esta operación y, por tanto, definimos [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) en 2 GB para la sesión actual.
```
SET maintenance_work_mem='2 GB';
SET
```
1. En la sesión dos, ejecute el comando `vacuum freeze verbose` para la tabla. El ajuste de informe detallado resulta útil porque, aunque PostgreSQL no ofrece actualmente un informe de progreso para esto, se puede ver la actividad.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. En la sesión uno, si la limpieza automática bloqueaba la sesión de vacío, `pg_stat_activity` muestra que la espera es `T` para la sesión de vacío. En este caso, finalice el proceso de limpieza automática de la siguiente manera.
```
SELECT pg_terminate_backend('the_pid');
```
**nota**
Algunas versiones anteriores de Amazon RDS no pueden finalizar un proceso de limpieza automática mediante el comando anterior y producen el siguiente error: `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`.
En este punto, comienza la sesión. La limpieza automática se reinicia inmediatamente, ya que esta tabla es probablemente la que ocupa una posición más alta en la lista de trabajo.
1. Inicie el comando `vacuum freeze verbose` en la sesión dos y luego finalice el proceso de autovacuum en la sesión uno.
# Reindexar una tabla cuando autovacuum se está ejecutando
Si un índice se ha dañado, autovacuum seguirá procesando la tabla y generará errores. Si intenta realizar un vacío manual en esta situación, recibirá un mensaje de error como el siguiente.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Cuando el índice está dañado y autovacuum intenta ejecutarse en la tabla, se enfrenta a una sesión de autovacuum que ya se está ejecutando. Cuando ejecuta un comando [REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html), elimina un bloqueo exclusivo en la tabla. Las operaciones de escritura están bloqueadas y también las operaciones de lectura que usan ese índice específico.
**Para reindexar una tabla cuando autovacuum se está ejecutando en ella**
1. Abra dos sesiones en la base de datos que contiene la tabla que desea vaciar. Para la segunda sesión, use "screen" u otra utilidad que mantenga la sesión activa si se interrumpe la conexión.
1. En la sesión uno, obtenga el PID de la sesión de autovacuum que se ejecuta en la tabla.
Ejecute la siguiente consulta para obtener el PID de la sesión de autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. En la sesión dos, ejecute el comando reindex.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. En la sesión uno, si autovacuum estaba bloqueando, verá en `pg_stat_activity` que la espera es “T” para su sesión de vacío. En este caso, terminará el proceso de autovacuum.
```
SELECT pg_terminate_backend('the_pid');
```
En este punto, comienza la sesión. Es importante tener en cuenta que autovacuum se reiniciará inmediatamente, ya que esta tabla es probablemente la que ocupa una posición más alta en su lista de trabajo.
1. Inicie el comando en la sesión dos y termine a continuación el proceso de autovacuum de la sesión 1.
# Administración de autovacuum con índices de gran tamaño
Como parte de su funcionamiento, *autovacuum* realiza varias [fases de vaciado](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) mientras se ejecuta en una tabla. Antes de limpiar la tabla, primero se vacían todos sus índices. Al eliminar varios índices de gran tamaño, esta fase consume una cantidad importante de tiempo y recursos. Por lo tanto, como práctica recomendada, asegúrese de controlar el número de índices de una tabla y eliminar los no utilizados.
Para este proceso, compruebe primero el tamaño general del índice. A continuación, determine si hay índices que es posible que no se utilicen y que se puedan eliminar, tal y como se muestra en los siguientes ejemplos.
**Para comprobar el tamaño de la tabla y sus índices**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
En este ejemplo, el tamaño de los índices es mayor que el de la tabla. Esta diferencia puede provocar problemas de rendimiento, ya que los índices están sobrecargados o no se utilizan, lo que afecta a las operaciones de autovacuum y de inserción.
**Para comprobar si hay índices no utilizados**
En la vista [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW), puede comprobar la frecuencia con la que se utiliza un índice con la columna `idx_scan`. En el siguiente ejemplo, los índices no utilizados tienen el valor `0` en `idx_scan`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**nota**
Estas estadísticas son incrementales desde el momento en que se restablecen las estadísticas. Supongamos que tiene un índice que solo se usa al final de un trimestre empresarial o solo para un informe específico. Es posible que este índice no se haya utilizado desde que se restablecieron las estadísticas. Para obtener más información, consulte [Statistics Functions](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS) (Funciones de estadísticas). Los índices que se utilizan para garantizar la exclusividad no se analizan y no se deben identificar como índices no utilizados. Para identificar los índices no utilizados, debe tener un conocimiento profundo de la aplicación y sus consultas.
Para comprobar cuándo se restablecieron por última vez las estadísticas de una base de datos, utilice [ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW]( https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW)
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Vaciado de una tabla lo más rápido posible
**RDS para PostgreSQL 12 y versiones posteriores**
Si tiene demasiados índices en una tabla grande, la instancia de base de datos podría estar a punto de reiniciar el identificador de transacción (XID), que es cuando el contador de XID vuelve a ponerse en cero. Si esta casilla no se marca, esta situación podría provocar la pérdida de datos. Sin embargo, puede vaciar rápidamente la tabla sin limpiar los índices. En RDS para PostgreSQL 12 y versiones posteriores, puede usar VACUUM con la cláusula [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html).
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Si ya se está ejecutando una sesión de autovacuum, debe finalizarla para iniciar VACUUM manualmente. Para obtener información acerca de la ejecución de una inmovilización de vacío manual, consulte [Realización de una inmovilización de vacío manual](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**nota**
Omitir la limpieza de índices con regularidad causa una sobrecarga de los índices, lo que degrada el rendimiento del análisis. El índice retiene las filas inactivas y la tabla retiene los punteros de línea inactivos. Como resultado, `pg_stat_all_tables.n_dead_tup` aumenta hasta que se ejecuta el vaciado automático o una operación VACUUM manual con limpieza de índices. Como práctica recomendada, use este procedimiento solo para impedir que el identificador se reinicie.
**RDS para PostgreSQL 11 y versiones anteriores**
Sin embargo, en RDS para PostgreSQL 11 y versiones anteriores, la única forma de hacer que el vacío se realice más rápidamente es reducir el número de índices de una tabla. La eliminación de un índice puede afectar a los planes de consulta. Le recomendamos que primero borre los índices no utilizados y, a continuación, los índices cuando el reinicio de XID sea inminente. Una vez finalizado el proceso de vaciado, puede volver a crear estos índices.
# Otros parámetros que afectan a autovacuum
La siguiente consulta mostrará los valores de algunos de los parámetros que afectan directamente a autovacuum y a su comportamiento. Los [parámetros de autovacuum](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) se describen en detalle en la documentación de PostgreSQL.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
Aunque todos estos parámetros afectan a autovacuum, estos son algunos de los más importantes:
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Establecimiento de parámetros autovacuum de nivel de tabla
Los [parámetros de almacenamiento](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS) relacionados con autovacuum se pueden definir en el nivel de tabla, algo que puede resultar mejor que alterar el comportamiento de toda la base de datos. Para las tablas grandes, podría ser necesario definir unos ajustes agresivos, y es posible que no sea deseable que autovacuum se comporte de esa forma para todas las tablas.
La siguiente consulta mostrará qué tablas tienen habilitadas actualmente las opciones de nivel de tabla.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Un ejemplo en el que esto puede resultar útil es el de las tablas que son mucho más grandes que el resto de las tablas. Supongamos que dispone de una tabla de 300 GB y otras 30 tablas inferior a 1 GB. En ese caso, podría definir algunos parámetros concretos para la tabla grande con el fin de evitar alterar el comportamiento de todo el sistema.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
Al hacer esto, desactiva el retraso de autovacuum basado en costos para esta tabla a expensas de un mayor uso de recursos en su sistema. Normalmente, autovacuum hace una pausa por `autovacuum_vacuum_cost_delay` cada vez que se alcanza `autovacuum_cost_limit`. En la documentación de PostgreSQL, puede obtener información detallada relativa al [vacío basado en el costo](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Registro de actividades de autovacuum y vacuum
La información sobre las actividades de autovacuum se envía a `postgresql.log` basado en el nivel especificado en el parámetro `rds.force_autovacuum_logging_level`. Los siguientes son los valores permitidos para este parámetro y las versiones de PostgreSQL para las que ese valor es la configuración predeterminada:
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 y versiones posteriores)
+ `error`, registro, `fatal`, `panic`
`rds.force_autovacuum_logging_level` funciona con el parámetro `log_autovacuum_min_duration`. El valor del parámetro `log_autovacuum_min_duration` es el límite (en milisegundos) por encima del cual se registran las acciones de autovacuum. Una configuración de `-1` no registra nada, mientras que una configuración de 0 registra todas las acciones. Al igual que con `rds.force_autovacuum_logging_level`, los valores predeterminados para `log_autovacuum_min_duration` dependen de la versión, como se indica a continuación:
+ `10000 ms`: PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 y PostgreSQL 11
+ `(empty)`: no hay valor predeterminado para PostgreSQL 10 y PostgreSQL 9.6
Es recomendable que defina `rds.force_autovacuum_logging_level` como `WARNING`. También recomendamos configurar `log_autovacuum_min_duration` a un valor de 1000 a 5000. Una configuración de 5000 registra la actividad que tarda más de 5000 milisegundos. Cualquier configuración que no sea -1 también registra mensajes si la acción de autovaccum se omite debido a un bloqueo en conflicto o relaciones eliminadas al mismo tiempo. Para más información, visite [Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) (Vacío automático) en la documentación de PostgreSQL.
Para solucionar problemas, puede cambiar el parámetro `rds.force_autovacuum_logging_level` a uno de los niveles de depuración, desde `debug1` hasta `debug5` para obtener la información más detallada. Le recomendamos que utilice la configuración de depuración durante periodos cortos y solo con el objetivo de solucionar problemas. Para más información, visite [When to log](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) (Cuándo registrarse) en la documentación de PostgreSQL.
**nota**
PostgreSQL permite a la cuenta `rds_superuser` consultar sesiones de autovacuum en `pg_stat_activity`. Por ejemplo, podrá identificar y finalizar una sesión de autovacuum que bloquea la ejecución de un comando o que hace que se ejecute más despacio que un comando de vacío emitido manualmente.
# Comportamiento de autovacuum con bases de datos no válidas
Se introduce un nuevo valor `-2` en la columna `datconnlimit` del catálogo `pg_database` para indicar que las bases de datos interrumpidas en mitad de la operación DROP DATABASE no son válidas.
Este nuevo valor está disponible en las siguientes versiones de RDS para PostgreSQL:
+ Versión 15.4 y todas las versiones posteriores
+ Versión 14.9 y posteriores
+ Versión 13.12 y posteriores
+ Versión 12.16 y posteriores
+ Versión 11.21 y posteriores
Las bases de datos no válidas no afectan a la capacidad de autovacuum de bloquear la funcionalidad de las bases de datos válidas. Autovacuum ignora las bases de datos no válidas. Por lo tanto, las operaciones vacuum habituales seguirán funcionando de forma adecuada y eficiente en todas las bases de datos válidas de su entorno de PostgreSQL.
**Topics**
+ [
## Supervisión del ID de transacción
](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [
## Ajustes en la consulta de supervisión
](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [
## Resolución de problemas relacionados con bases de datos no válidas
](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Supervisión del ID de transacción
La función `age(datfrozenxid)` se suele utilizar para supervisar la antigüedad del ID de transacción (XID) de las bases de datos a fin de evitar que este se reinicie.
Como las bases de datos no válidas se excluyen del autovacuum, su contador de ID de transacción (XID) puede alcanzar el valor máximo de `2 billion`, reiniciarse en `- 2 billion` y continuar este ciclo indefinidamente. Una consulta típica para supervisar el reinicio del ID de transacción podría ser así:
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Sin embargo, al introducir el valor -2 para `datconnlimit`, las bases de datos no válidas pueden sesgar los resultados de esta consulta. Como estas bases de datos no son válidas y no deberían formar parte de las comprobaciones de mantenimiento periódicas, pueden provocar falsos positivos y dar la impresión de que `age(datfrozenxid)` es mayor de lo que realmente es.
## Ajustes en la consulta de supervisión
Para garantizar una supervisión precisa, debe ajustar la consulta de supervisión a fin de excluir las bases de datos no válidas. Siga esta consulta recomendada:
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Esta consulta garantiza que solo se tengan en cuenta las bases de datos válidas en el cálculo de `age(datfrozenxid)`, lo que aporta información fiable sobre la antigüedad del ID de transacción en todo el entorno de PostgreSQL.
## Resolución de problemas relacionados con bases de datos no válidas
Al intentar conectarse a una base de datos no válida, es posible que vea un mensaje de error similar al siguiente:
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
Además, si el parámetro `log_min_messages` tiene un valor igual o superior a `DEBUG2`, es posible que vea que las siguientes entradas de registro muestran que el proceso de autovacuum omite la base de datos no válida:
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Para resolver el problema, siga la `HINT` proporcionada durante el intento de conexión. Conéctese a cualquier base de datos válida mediante su cuenta maestra de RDS o una cuenta de base de datos con el rol `rds_superuser` y elimine las bases de datos no válidas.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# Identificación y resolución de los bloqueadores de vaciado intensivo en RDS para PostgreSQL
En PostgreSQL, la limpieza es fundamental para garantizar el buen estado de la base de datos, ya que recupera espacio de almacenamiento y evita problemas relacionados con los [identificadores de transacciones](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND). Sin embargo, hay situaciones que pueden impedir que el vaciado funcione como es debido, lo que puede mermar el rendimiento, provocar una sobrecarga de almacenamiento e incluso afectar a la disponibilidad de la instancia de base de datos debido a la superposición de ID de transacción. Por lo tanto, identificar y resolver estos problemas es esencial para lograr un rendimiento y una disponibilidad óptimos de la base de datos. Consulte [Understanding autovacuum in Amazon RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) si desea conocer mejor la limpieza automática.
La función `postgres_get_av_diag()` ayuda a identificar los problemas que impiden o retrasan el avance de la limpieza agresiva. Se proporcionan sugerencias, entre otras, comandos para resolver el problema si es identificable o indicaciones para realizar diagnósticos adicionales cuando no se puede identificar el problema. Los bloqueadores de limpieza agresiva aparecen cuando su antigüedad supera el umbral de [vacío automático adaptativo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) establecido por RDS, que es de 500 millones de identificadores de transacciones.
**Qué antigüedad tiene el identificador de la transacción?**
La función `age()` de identificadores de transacción calcula el número de transacciones que se han producido desde el identificador de transacción descongelado más antiguo de una base de datos (`pg_database.datfrozenxid`) o tabla (`pg_class.relfrozenxid`). Este valor indica la actividad de la base de datos desde la última operación de limpieza agresiva y resalta la carga de trabajo probable para los próximos procesos de LIMPIEZA.
**Qué es una limpieza agresiva?**
Una operación de LIMPIEZA agresiva lleva a cabo un escaneo exhaustivo de todas las páginas de una tabla, incluidas las que normalmente se omiten durante las limpiezas normales. Este análisis exhaustivo tiene como objetivo congelar los ID de transacción que se acercan a su antigüedad máxima, evitando de forma eficaz una situación conocida como [superposición de identificadores de transacción](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND).
Para que `postgres_get_av_diag()` pueda detectar bloqueadores, el bloqueador debe haber realizado al menos 500 millones de transacciones.
**Topics**
+ [
# Instalación de herramientas de supervisión y diagnóstico de autovacuum en RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [
# Funciones de postgres\$1get\$1av\$1diag() en RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [
# Resolución de bloqueadores de vaciado identificables en RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [
# Resolución de bloqueadores de vaciado no identificables en RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [
# Resolución de problemas de rendimiento de vaciado en RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [
# Explicación de los mensajes de tipo NOTICE en RDS para PostgreSQL
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# Instalación de herramientas de supervisión y diagnóstico de autovacuum en RDS para PostgreSQL
La función `postgres_get_av_diag()` está disponible actualmente en las siguientes versiones de RDS para PostgreSQL:
+ Versión 17.2 y otras versiones 17 superiores
+ Versión 16.7 y otras versiones 16 superiores
+ Versión 15.11 y otras versiones 15 superiores
+ Versión 14.16 y otras versiones 14 superiores
+ Versión 13.19 y otras versiones 13 superiores
Para utilizar `postgres_get_av_diag()`, cree la extensión `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Compruebe que la extensión esté instalada.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Compruebe que la función se haya creado.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# Funciones de postgres\$1get\$1av\$1diag() en RDS para PostgreSQL
La función `postgres_get_av_diag()` recupera información de diagnóstico sobre los procesos de autovacuum que se bloquean o se retrasan en una base de datos de RDS para PostgreSQL. La consulta debe ejecutarse en la base de datos con el ID de transacción más antiguo para obtener resultados precisos. Para obtener más información sobre el uso de la base de datos con el ID de transacción más antiguo, consulte [Not connected to the database with the age of oldest transaction ID](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
La función `postgres_get_av_diag()` devuelve una tabla con la siguiente información:
**blocker**
Especifica la categoría de actividad de la base de datos que bloquea el vaciado.
+ [Instrucción activa](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Inactividad en la transacción](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transacción preparada](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Ranura de replicación lógica](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Réplica de lectura con ranura de replicación física](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Réplica de lectura con replicación de streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tablas temporales](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**database**
Especifica el nombre de la base de datos, si está disponible y es compatible. Esta es la base de datos en la que la actividad está en curso y bloquea o bloqueará el autovacuum. Esta es la base de datos a la que debe conectarse y sobre la que debe actuar.
**blocker\$1identifier**
Especifica el identificador de la actividad que bloquea o bloqueará el autovacuum. El identificador puede ser un ID de proceso junto con una instrucción SQL, una transacción preparada, una dirección IP de una réplica de lectura y el nombre de la ranura de replicación, ya sea lógica o física.
**wait\$1event**
Especifica el [evento de espera](PostgreSQL.Tuning.md) de la sesión de bloqueo y se aplica a los siguientes bloqueadores:
+ Instrucción activa
+ Inactividad en la transacción
**autovacum\$1lagging\$1by**
Especifica el número de transacciones que tiene pendiente el autovacuum según sus trabajos por realizar y por categoría.
**suggestion**
Especifica sugerencias para resolver el bloqueo. Estas instrucciones incluyen el nombre de la base de datos en la que existe la actividad, cuando proceda, el ID de proceso (PID) de la sesión, cuando proceda, y la acción que se debe realizar.
**suggested\$1action**
Sugiere la acción que se debe llevar a cabo para resolver el bloqueo.
# Resolución de bloqueadores de vaciado identificables en RDS para PostgreSQL
Autovacuum lleva a cabo vaciados de forma intensiva y reduce la antigüedad de los ID de transacción hasta situarlos por debajo del umbral especificado por el parámetro `autovacuum_freeze_max_age` de la instancia de RDS. Esta antigüedad se puede consultar mediante la métrica `MaximumUsedTransactionIDs` de Amazon CloudWatch.
Para encontrar la configuración de `autovacuum_freeze_max_age` (que tiene un valor predeterminado de 200 millones de ID de transacción) para una instancia de Amazon RDS, puede utilizar la siguiente consulta:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
Tenga en cuenta que `postgres_get_av_diag()` solo comprueba si hay bloqueadores de vaciado intensivo cuando la antigüedad supera el umbral de [autovacuum adaptativo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) de Amazon RDS de 500 millones de ID de transacción. Para que `postgres_get_av_diag()` detecte los bloqueadores, el bloqueador debe tener al menos 500 millones de transacciones de antigüedad.
La función `postgres_get_av_diag()` identifica los siguientes tipos de bloqueadores:
**Topics**
+ [
## Instrucción activa
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [
## Inactividad en la transacción
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [
## Transacción preparada
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [
## Ranura de replicación lógica
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [
## Réplicas de lectura
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [
## Tablas temporales
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Instrucción activa
En PostgreSQL, una instrucción activa es una instrucción SQL que la base de datos está ejecutando actualmente. Incluye consultas, transacciones o cualquier operación en curso. Al realizar la supervisión mediante `pg_stat_activity`, la columna de estado indica que el proceso con el PID correspondiente está activo.
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando identifica una instrucción que resulta ser una instrucción activa.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Acción sugerida**
Siguiendo las instrucciones de la columna `suggestion`, el usuario puede conectarse a la base de datos en la que se encuentra la instrucción activa y, tal como se especifica en la columna `suggested_action`, se recomienda revisar detenidamente la opción de finalizar la sesión. Si la finalización es segura, se puede utilizar la función `pg_terminate_backend()` para finalizar la sesión. Esta acción la puede realizar un administrador (como la cuenta maestra de RDS) o un usuario con el privilegio `pg_terminate_backend()` necesario.
**aviso**
Al finalizar la sesión, se desharán (`ROLLBACK`) los cambios que haya realizado. En función de sus requisitos, es posible que quiera volver a ejecutar la instrucción. Sin embargo, se recomienda hacerlo únicamente después de que el proceso de autovacuum haya finalizado su operación de vaciado intensivo.
## Inactividad en la transacción
El concepto de inactividad en una instrucción de transacción se refiere a cualquier sesión en la que se haya abierto una transacción explícita (por ejemplo, emitiendo una instrucción `BEGIN`), se haya realizado algún trabajo y se esté esperando a que el cliente pase más trabajo o dé la señal de finalización de la transacción emitiendo una instrucción `COMMIT`, `ROLLBACK` o `END` (lo que daría como resultado un `COMMIT` implícitamente).
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando identifica una instrucción `idle in transaction` como bloqueador.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Acción sugerida**
Como se indica en la columna `suggestion`, puede conectarse a la base de datos en la que se encuentra la sesión de inactividad en la transacción y finalizar la sesión mediante la función `pg_terminate_backend()`. El usuario puede ser su usuario administrador (cuenta maestra de RDS) o un usuario con el privilegio `pg_terminate_backend()`.
**aviso**
Al finalizar la sesión, se desharán (`ROLLBACK`) los cambios que haya realizado. En función de sus requisitos, es posible que quiera volver a ejecutar la instrucción. Sin embargo, se recomienda hacerlo únicamente después de que el proceso de autovacuum haya finalizado su operación de vaciado intensivo.
## Transacción preparada
PostgreSQL permite realizar transacciones que forman parte de una estrategia de confirmación de dos fases denominada [transacciones preparadas](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Se habilitan al establecer el parámetro `max_prepared_transactions` en un valor distinto de cero. Las transacciones preparadas han sido diseñadas para garantizar que una transacción sea duradera y permanezca disponible incluso después de que la base de datos se bloquee, se reinicie o se desconecte del cliente. Al igual que las transacciones normales, se les asigna un identificador de transacción y pueden afectar al autovacuum. Si se deja en un estado preparado, el autovacuum no puede realizar la congelación y podría provocar un reinicio del ID de transacción.
Cuando las transacciones se dejan preparadas indefinidamente sin que las resuelva un administrador de transacciones, se convierten en transacciones preparadas huérfanas. La única forma de solucionar este problema es confirmar o revertir la transacción mediante los comandos `COMMIT PREPARED` o `ROLLBACK PREPARED` respectivamente.
**nota**
Tenga en cuenta que una copia de seguridad realizada durante una transacción preparada seguirá conteniendo esa transacción después de la restauración. Consulte la siguiente información sobre cómo localizar y cerrar dichas transacciones.
La función `postgres_get_av_diag()` muestra el siguiente resultado cuando identifica un bloqueador que es una transacción preparada.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Acción sugerida**
Como se menciona en la columna de sugerencias, conéctese a la base de datos en la que se encuentre la transacción preparada. Sobre la base de la columna `suggested_action`, revise detenidamente si desea enviar una instrucción `COMMIT` o `ROLLBACK`, y realizar la acción correspondiente.
Para supervisar las transacciones preparadas en general, PostgreSQL ofrece una vista de catálogo llamada `pg_prepared_xacts`. Puede utilizar la siguiente consulta para buscar transacciones preparadas.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Ranura de replicación lógica
El propósito de una ranura de replicación es almacenar los cambios no consumidos hasta que se repliquen en un servidor de destino. Para obtener más información, consulte [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) de PostgreSQL.
Existen dos tipos de ranuras de replicación lógica.
**Ranuras de replicación lógica inactivas**
Cuando finaliza la replicación, los registros de transacciones no consumidas no se pueden eliminar y la ranura de replicación queda inactiva. Aunque un suscriptor no utilice actualmente una ranura de replicación lógica inactiva, esta permanece en el servidor, lo que provoca la retención de los archivos WAL y evita la eliminación de los registros de transacciones antiguos. Esto puede aumentar el uso del disco y, específicamente, impedir que autovacuum limpie las tablas del catálogo interno, ya que el sistema debe evitar que se sobrescriba la información de LSN. Si este problema no se soluciona, puede provocar una sobrecarga del catálogo, una degradación del rendimiento y un mayor riesgo de que se produzcan vaciados previos al reinicio, lo que podría causar tiempo de inactividad en las transacciones.
**Ranuras de replicación lógica activas pero lentas**
A veces, la eliminación de las tuplas inactivas del catálogo se retrasa debido a la degradación del rendimiento de la replicación lógica. Este retraso en la replicación ralentiza la actualización de `catalog_xmin` y puede provocar una sobrecarga del catálogo y un vaciado previo al reinicio.
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando encuentra una ranura de replicación lógica que funciona como bloqueador.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Acción sugerida**
Para resolver este problema, compruebe la configuración de la replicación para ver si hay problemas con el esquema o los datos de destino que puedan estar finalizando el proceso de aplicación. Los motivos más comunes son los siguientes:
+ Columnas faltantes
+ Tipos de datos incompatibles
+ Discrepancia de datos
+ Tabla faltante
Si el problema está relacionado con problemas de infraestructura:
+ Problemas de red: [¿cómo resuelvo los problemas con una base de datos de Amazon RDS en un estado de red incompatible?](https://repost.aws/knowledge-center/rds-incompatible-network)
+ La base de datos o la instancia de base de datos no están disponibles por una de las siguientes razones:
+ La instancia de réplica se ha quedado sin espacio de almacenamiento: consulte qué hacer cuando [las instancias de base de datos de Amazon RDS se quedan sin almacenamiento](https://repost.aws/knowledge-center/rds-out-of-storage) para obtener información sobre cómo añadir almacenamiento.
+ Parámetros incompatibles: revise [¿Cómo puedo corregir una instancia de base de datos de Amazon RDS que está estancada en el estado parámetros incompatibles?](https://repost.aws/knowledge-center/rds-incompatible-parameters) para obtener más información acerca de cómo solucionar este problema.
Si la instancia está fuera de la red de AWS o en AWS EC2, consulte a su administrador sobre cómo resolver los problemas relacionados con la disponibilidad o la infraestructura.
**Eliminación de la ranura inactiva**
**aviso**
Precaución: Antes de eliminar una ranura de replicación, asegúrese exhaustivamente de que no tenga ninguna replicación en curso, de que esté inactiva y de que se encuentre en un estado irrecuperable. Si se elimina una ranura de forma prematura, se podría interrumpir la replicación o provocar la pérdida de datos.
Después de confirmar que la ranura de replicación ya no es necesaria, elimínela para permitir que el autovacuum continúe. La condición `active = 'f'` garantiza que solo se eliminará una ranura inactiva.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Réplicas de lectura
Cuando la configuración `hot_standby_feedback` está habilitada para las [réplicas de lectura de Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), evita que el autovacuum de la base de datos principal elimine determinadas filas inactivas que podrían seguir necesitando las consultas que se ejecuten en la réplica de lectura. Esto afecta a todos los tipos de réplicas de lectura físicas, incluidas las que se administran con o sin ranuras de replicación. Este comportamiento es necesario porque las consultas que se ejecutan en la réplica en espera requieren que esas filas permanezcan disponibles en el servidor principal, lo que evita cancelaciones y [conflictos de consultas](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT).
**Réplica de lectura con ranura de replicación física**
Las réplicas de lectura con ranuras de replicación físicas mejoran considerablemente la fiabilidad y la estabilidad de la replicación en RDS para PostgreSQL. Estas ranuras garantizan que la base de datos principal conserve los archivos de registro de escritura anticipada esenciales hasta que la réplica los procese, ya que esto mantiene la coherencia de datos incluso durante las interrupciones de la red.
A partir de la versión 14 de RDS para PostgreSQL, todas las réplicas utilizan ranuras de replicación. En las versiones anteriores, solo las réplicas entre regiones utilizaban ranuras de replicación.
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando encuentra una réplica de lectura con una ranura de replicación física como bloqueador.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Réplica de lectura con replicación de streaming**
Amazon RDS permite configurar réplicas de lectura sin una ranura de replicación física en versiones anteriores, hasta la versión 13. Este enfoque reduce la sobrecarga al permitir que el servidor principal recicle los archivos WAL de forma más intensiva, lo que resulta ventajoso en entornos con limitaciones del espacio en disco y en los que se pueda tolerar un ReplicaLag ocasional. Sin embargo, sin no dispone de una ranura, la réplica en espera debe permanecer sincronizada para evitar que se pierdan archivos WAL. Amazon RDS utiliza archivos WAL archivados para ayudar a la réplica a ponerse al día en caso de que se quede atrás, pero este proceso requiere una supervisión exhaustiva y puede resultar lento.
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando encuentra una réplica de lectura de streaming como bloqueador.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Acción sugerida**
Como se recomienda en la columna `suggested_action`, revise detenidamente estas opciones para desbloquear el autovacuum.
+ **Finalizar la consulta**: de acuerdo con las instrucciones de la columna de sugerencias, puede conectarse a la réplica de lectura, tal y como se especifica en la columna suggested\$1action. Se recomienda revisar detenidamente la opción para finalizar la sesión. Si la finalización se considera segura, se puede utilizar la función `pg_terminate_backend()` para finalizar la sesión. Esta acción la puede realizar un administrador (como la cuenta maestra de RDS) o un usuario con el privilegio pg\$1terminate\$1backend() necesario.
Puede ejecutar el siguiente comando SQL en la réplica de lectura para finalizar la consulta que impide que el proceso de vaciado en el principal pueda limpiar las filas antiguas. El valor de `backend_xmin` se indica en la salida de la función:
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Desactivar la retroalimentación de espera activa**: plantéese deshabilitar el parámetro `hot_standby_feedback` si provoca retrasos significativos en el vaciado.
El parámetro `hot_standby_feedback` permite que una réplica de lectura informe al servidor principal sobre su actividad de consulta, lo que evita que el principal vacíe las tablas o filas que están en uso en la réplica en espera. Si bien esto garantiza la estabilidad de las consultas en la réplica en espera, puede retrasar considerablemente el vaciado en el principal. La desactivación de esta característica permite al servidor principal continuar con el vaciado sin tener que esperar a que la réplica en espera se ponga al día. Sin embargo, esto puede provocar cancelaciones o errores en las consultas en la réplica en espera si intenta acceder a las filas que ha vaciado el principal.
+ **Eliminar la réplica de lectura si no es necesaria**: si la réplica de lectura ya no es necesaria, puede eliminarla. Esto eliminará la sobrecarga de replicación asociada y permitirá que el servidor principal recicle los registros de transacciones sin que la réplica se lo obstaculice.
## Tablas temporales
Las [tablas temporales](https://www.postgresql.org/docs/current/sql-createtable.html), que se crean con la palabra clave `TEMPORARY`, residen en el esquema temporal (por ejemplo, pg\$1temp\$1xxx) y solo la sesión que las haya creado puede acceder a ellas. Las tablas temporales se eliminan al finalizar la sesión. Sin embargo, estas tablas son invisibles para el proceso de autovacuum de PostgreSQL y la sesión que las haya creado debe vaciarlas manualmente. Intentar vaciar la tabla temporal desde otra sesión no tiene ningún efecto.
En circunstancias poco habituales, puede existir una tabla temporal sin que sea propiedad de una sesión activa. Si la sesión propietaria finaliza inesperadamente debido a un bloqueo grave, un problema de red o un suceso similar, es posible que la tabla temporal no se limpie y quede como una tabla “huérfana”. Cuando el proceso de autovacuum de PostgreSQL detecta una tabla temporal huérfana, registra el siguiente mensaje:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
La función `postgres_get_av_diag()` muestra un resultado similar al siguiente cuando identifica una tabla temporal como bloqueador. Para que la función muestre correctamente el resultado relacionado con las tablas temporales, debe ejecutarse en la misma base de datos en la que se encuentren esas tablas.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Acción sugerida**
Siga las instrucciones que aparecen en la columna `suggestion` del resultado para identificar y eliminar la tabla temporal que impide la ejecución del autovacuum. Use el siguiente comando para eliminar la tabla temporal notificada por `postgres_get_av_diag()`. Reemplace el nombre de la tabla en función del resultado proporcionado por la función `postgres_get_av_diag()`.
```
DROP TABLE my_temp_schema.my_temp_table;
```
La siguiente consulta se puede utilizar para identificar tablas temporales:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# Resolución de bloqueadores de vaciado no identificables en RDS para PostgreSQL
En esta sección se analizan otros motivos que pueden impedir que el progreso del vaciado. Actualmente, la función `postgres_get_av_diag()` no puede identificar directamente estos problemas.
**Topics**
+ [
## Páginas no válidas
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [
## Incoherencia en los índices
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [
## Tasa de transacciones excepcionalmente alta
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Páginas no válidas
Se produce un error de página no válida cuando PostgreSQL detecta una discrepancia en la suma de comprobación de una página al acceder a esa página. El contenido resulta ilegible, lo que impide que autovacuum congele las tuplas. Esto detiene de forma efectiva el proceso de limpieza. El siguiente error está escrito en el registro de PostgreSQL:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Determinar el tipo de objeto**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
A partir del mensaje de error, la ruta `base/16403/186752608` proporciona la siguiente información:
+ “base” es el nombre del directorio de datos de PostgreSQL.
+ “16403” es el OID de la base de datos, que puede buscar en el catálogo del sistema `pg_database`.
+ “186752608” es el `relfilenode`, que puede utilizar para buscar el nombre del objeto y el esquema en el catálogo del sistema `pg_class`.
Al comprobar el resultado de la siguiente consulta en la base de datos afectada, puede determinar el tipo de objeto. La siguiente consulta recupera información de objeto para el oid: 186752608. Sustituya este OID por el correspondiente para el error que haya encontrado.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Para obtener más información, consulte la documentación de PostgreSQL sobre [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) para ver todos los tipos de objetos compatibles, indicados en la columna `relkind` de `pg_class`.
**Indicaciones**
La solución más eficaz para este problema depende de la configuración de la instancia específica de Amazon RDS y del tipo de datos afectados por la página incoherente.
**Si el tipo de objeto es un índice:**
Se recomienda volver a crear el índice.
+ **Uso de la opción `CONCURRENTLY`**: antes de la versión 12 de PostgreSQL, la reconstrucción de un índice requería un bloqueo de tabla exclusivo, lo que restringía el acceso a la misma. Con PostgreSQL versión 12 y versiones posteriores, la opción `CONCURRENTLY` permite el bloqueo por filas, lo que mejora significativamente la disponibilidad de la tabla. A continuación, se muestra el comando:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Si bien `CONCURRENTLY` resulta menos disruptivo, puede ser más lento en tablas de uso intensivo. Si es posible, considere la posibilidad de crear el índice durante los períodos de poco tráfico.
Para obtener más información, consulte la documentación de PostgreSQL sobre [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html).
+ **Uso de la opción `INDEX_CLEANUP FALSE`**: si los índices son grandes y se calcula que tardarán mucho en completarse, puede desbloquear el autovacuum ejecutando un `VACUUM FREEZE` manual y excluyendo los índices. Esta funcionalidad está disponible en la versión 12 y posteriores de PostgreSQL.
Omitir los índices le permitirá saltarse el proceso de vaciado del índice incoherente y mitigar el problema del reinicio. Sin embargo, esto no resolverá el problema subyacente de la página no válida. Para solucionar por completo el problema de la página no válida y resolverlo, tendrá que volver a crear el índice.
**Si el tipo de objeto es una vista materializada:**
Si se produce un error de página no válida en una vista materializada, inicie sesión en la base de datos afectada y actualícela para resolver la página no válida:
Actualice la vista materializada:
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Si se produce un error al actualizar, intente volver a crearla:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
Al actualizar o volver a crear la vista materializada, se restaura sin que esto afecte a los datos de la tabla subyacente.
**Para todos los demás tipos de objetos:**
Para todos los demás tipos de objetos, puede ponerse en contacto con el servicio de asistencia de AWS.
## Incoherencia en los índices
Un índice que no sea coherente desde el punto de vista lógico puede impedir que avance el autovacuum. Los siguientes errores u otros similares se registran durante la fase de vaciado del índice o cuando se accede al índice mediante instrucciones SQL.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Indicaciones**
Reconstruya el índice u omita los índices utilizando `INDEX_CLEANUP` con un `VACUUM FREEZE` manual. Para obtener información sobre cómo reconstruir el índice, consulte [Si el tipo de objeto es un índice](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Uso de la opción CONCURRENTLY**: antes de la versión 12 de PostgreSQL, la reconstrucción de un índice requería un bloqueo de tabla exclusivo, lo que restringía el acceso a la misma. Con PostgreSQL versión 12 y versiones posteriores, la opción CONCURRENTLY permite el bloqueo por filas, lo que mejora significativamente la disponibilidad de la tabla. A continuación, se muestra el comando:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Si bien CONCURRENTLY resulta menos disruptivo, puede ser más lento en tablas de uso intensivo. Si es posible, considere la posibilidad de crear el índice durante los períodos de poco tráfico. Para obtener más información, consulte [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) en la documentación de *PostgreSQL*.
+ **Uso de la opción INDEX\$1CLEANUP FALSE**: si los índices son grandes y se calcula que tardarán mucho en completarse, puede desbloquear el autovacuum ejecutando un VACUUM FREEZE manual y excluyendo los índices. Esta funcionalidad está disponible en la versión 12 y posteriores de PostgreSQL.
Omitir los índices le permitirá saltarse el proceso de vaciado del índice incoherente y mitigar el problema del reinicio. Sin embargo, esto no resolverá el problema subyacente de la página no válida. Para solucionar por completo el problema de la página no válida y resolverlo, tendrá que volver a crear el índice.
## Tasa de transacciones excepcionalmente alta
En PostgreSQL, las tasas de transacción altas pueden afectar significativamente al rendimiento de autovacuum, lo que implica una limpieza más lenta de las tuplas inactivas y a un aumento del riesgo de reiniciar los ID de transacción. Puede supervisar la tasa de transacciones midiendo la diferencia en `max(age(datfrozenxid))` entre dos períodos de tiempo, normalmente por segundo. Además, puede utilizar las siguientes métricas de contador de Información de rendimiento de RDS para medir la tasa de transacciones (la suma de xact\$1commit y xact\$1rollback), que es el número total de transacciones.
| Contador | Tipo | Unidad | Métrica |
| --- | --- | --- | --- |
| xact\$1commit | Transacciones | Confirmaciones por segundo | db.Transactions.xact\$1commit |
| xact\$1rollback | Transacciones | Restauraciones por segundo | db.Transactions.xact\$1rollback |
Un aumento rápido indica una alta carga de transacciones, lo que puede ser excesivo para autovacuum y provocar sobrecargas, bloqueos y posibles problemas de rendimiento. Esto puede tener un impacto negativo en el proceso de autovacuum de dos maneras:
+ **Actividad de la tabla:** la tabla específica que se está vaciando podría estar registrando un gran volumen de transacciones, lo que provocaría retrasos.
+ **Recursos del sistema:** el sistema en general puede estar sobrecargado, lo que dificulta que autovacuum acceda a los recursos necesarios para funcionar de manera eficiente.
Plantéese las siguientes estrategias para permitir que autovacuum funcione de manera más eficaz y pueda seguir el ritmo de sus tareas:
1. Reduzca la tasa de transacciones si es posible. Plantéese la posibilidad de agrupar o agrupar transacciones similares cuando sea posible.
1. Utilice tablas que se actualicen con frecuencia mediante la operación `VACUUM FREEZE` manual cada noche, semana o quincena durante las horas de menor actividad.
1. Plantéese la posibilidad de escalar verticalmente su clase de instancia para asignar más recursos del sistema con el fin de administrar el volumen de transacciones elevado y el autovacuum.
# Resolución de problemas de rendimiento de vaciado en RDS para PostgreSQL
En esta sección se analizan los factores que suelen contribuir a reducir el rendimiento del vaciado y cómo abordar estos problemas.
**Topics**
+ [
## Vaciado de índices grandes
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [
## Demasiadas tablas o bases de datos que vaciar
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [
## Se está ejecutando un vaciado intensivo (para evitar el reinicio)
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Vaciado de índices grandes
VACUUM funciona a través de fases secuenciales: inicialización, escaneo del montón, vaciado de índices y montón, limpieza de índices, truncamiento del montón y limpieza final. Durante el escaneo del montón, el proceso elimina las páginas, las desfragmenta y las congela. Después de completar el escaneo del montón, VACUUM limpia los índices, se devuelven las páginas vacías al sistema operativo y se realizan tareas de limpieza final, como el vaciado del mapa del espacio libre y la actualización de las estadísticas.
Es posible que sea necesario realizar varias pasadas para el vaciado de índices cuando `maintenance_work_mem` (o `autovacuum_work_mem`) no es suficiente para procesar el índice. En la versión 16 y anteriores de PostgreSQL, un límite de memoria de 1 GB para almacenar los ID de tuplas inactivas a menudo forzaba varias pasadas en índices grandes. PostgreSQL 17 presenta `TidStore`, que asigna memoria de forma dinámica en lugar de utilizar una matriz de asignación única. Esto elimina la restricción de 1 GB, utiliza la memoria de manera más eficiente y reduce la necesidad de realizar varios análisis de índice por cada índice.
Es posible que los índices grandes aún requieran varias pasadas en PostgreSQL 17 si la memoria disponible no puede acomodar todo el procesamiento del índice de una vez. Por lo general, los índices mayores contienen más tuplas inactivas que requieren varias pasadas.
**Detección de operaciones de limpieza lentas**
La función `postgres_get_av_diag()` puede detectar cuando las operaciones de limpieza se ejecutan lentamente debido a memoria insuficiente. Para obtener más información sobre esta función, consulte [Instalación de herramientas de supervisión y diagnóstico de autovacuum en RDS para PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
La función `postgres_get_av_diag()` emite los siguientes avisos cuando la memoria disponible no es suficiente para completar la limpieza del índice en una sola pasada.
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**nota**
La función `postgres_get_av_diag()` se basa en `pg_stat_all_tables.n_dead_tup` para estimar la cantidad de memoria necesaria para el vaciado de índices.
Cuando la función `postgres_get_av_diag()` identifique una operación de limpieza lenta que requiera múltiples análisis de índice debido a que no hay suficiente `autovacuum_work_mem`, generará el siguiente mensaje:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Indicaciones**
Puede aplicar las siguientes soluciones alternativas utilizando manualmente `VACUUM FREEZE` para acelerar la congelación de la tabla.
**Aumentar la memoria de vaciado**
Como sugiere la función `postgres_get_av_diag()`, se recomienda aumentar el parámetro `autovacuum_work_mem` para abordar las posibles restricciones de memoria en cada instancia. Aunque `autovacuum_work_mem` es un parámetro dinámico, es importante tener en cuenta que, para que la nueva configuración de memoria surta efecto, el daemon de autovacuum debe reiniciar sus procesos de trabajo. Para lograrlo:
1. Confirme que la nueva configuración esté establecida.
1. Finalice los procesos que actualmente estén ejecutando el autovacuum.
Este enfoque garantiza que la asignación de memoria ajustada se aplique a las nuevas operaciones de autovacuum.
Para obtener resultados más inmediatos, considere la posibilidad de realizar manualmente una operación `VACUUM FREEZE` con una configuración de `maintenance_work_mem` mayor durante la sesión:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Si utiliza Amazon RDS y descubre que necesita memoria adicional para poder utilizar valores más altos para `maintenance_work_mem` o `autovacuum_work_mem`, plantéese la posibilidad de actualizar a una clase de instancia con más memoria. Esto puede proporcionarle los recursos necesarios para mejorar las operaciones de vaciado manuales y automáticas, lo que se traduce en una mejora del rendimiento general de vaciado y del de las bases de datos.
**Desactivar INDEX\$1CLEANUP**
El `VACUUM` manual de la versión 12 y posteriores de PostgreSQL permite omitir la fase de limpieza de índices, mientras que el autovacuum de emergencia en la versión 14 y posteriores de PostgreSQL lo hace automáticamente en función del parámetro [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE).
**aviso**
Omitir la limpieza de índices puede provocar una sobrecarga de índices y perjudicar el rendimiento de las consultas. Para mitigar esta situación, considere la posibilidad de volver a indexar o vaciar los índices afectados durante un período de mantenimiento.
Para obtener más información sobre cómo gestionar índices grandes, consulte la documentación en [Administración de autovacuum con índices de gran tamaño](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Vaciado de índices en paralelo**
A partir de PostgreSQL 13, los índices se pueden vaciar y limpiar en paralelo de forma predeterminada utilizando `VACUUM` de forma manual, con un proceso de trabajo de vaciado asignado a cada índice. Sin embargo, para que PostgreSQL determine si una operación de vaciado es apta para su ejecución en paralelo, se deben cumplir criterios específicos:
+ Debe haber al menos dos índices.
+ El parámetro `max_parallel_maintenance_workers` debe estar establecido al menos en 2.
+ El tamaño del índice debe superar el límite `min_parallel_index_scan_size`, que de forma predeterminada es de 512 KB.
Puede ajustar la configuración `max_parallel_maintenance_workers` en función de la cantidad de vCPU disponibles en su instancia de Amazon RDS y la cantidad de índices de la tabla para optimizar el tiempo de respuesta del vaciado.
Para obtener más información, consulte [Parallel vacuuming in Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Demasiadas tablas o bases de datos que vaciar
Como se menciona en la documentación de PostgreSQL sobre [el daemon autovacuum](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM'), este funciona mediante múltiples procesos. Esto incluye un lanzador de autovacuum persistente responsable de iniciar los procesos de trabajo de autovacuum para cada base de datos del sistema. El lanzador programa estos procesos de trabajo para que se inicien aproximadamente cada `autovacuum_naptime` segundos por cada base de datos.
Con “N” bases de datos, un nuevo proceso de trabajo comienza aproximadamente cada [`autovacuum_naptime`/N segundos]. Sin embargo, el número total de procesos de trabajo simultáneos está limitado por la configuración `autovacuum_max_workers`. Si el número de bases de datos o tablas que requieren vaciado supera este límite, la siguiente base de datos o tabla se procesará en cuanto haya un proceso de trabajo disponible.
Cuando muchas tablas o bases de datos grandes requieren un vaciado al mismo tiempo, todos los procesos de trabajo de autovacuum disponibles pueden permanecer ocupados durante un período prolongado, lo que retrasa el mantenimiento de otras tablas y bases de datos. En entornos con altas tasas de transacciones, este cuello de botella puede agravarse rápidamente y provocar posibles problemas de vaciado en su instancia de Amazon RDS.
Cuando `postgres_get_av_diag()` detecta un número elevado de tablas o bases de datos, proporciona la siguiente recomendación:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Indicaciones**
**Aumentar autovacuum\$1max\$1workers**
Para agilizar el vaciado, recomendamos ajustar el parámetro `autovacuum_max_workers` para permitir que haya más procesos de trabajo de autovacuum simultáneos. Si persisten los cuellos de botella en el rendimiento, plantéese la posibilidad de escalar verticalmente su instancia de Amazon RDS a una clase con más vCPU, lo que puede mejorar aún más las capacidades de procesamiento en paralelo.
## Se está ejecutando un vaciado intensivo (para evitar el reinicio)
La antigüedad de la base de datos (MaximumUsedTransactionIDs) en PostgreSQL solo disminuye cuando se completa correctamente un vaciado intensivo (para evitar el reinicio). Hasta que finalice este vaciado, la antigüedad seguirá aumentando en función de la velocidad de transacciones.
La función `postgres_get_av_diag()` genera el `NOTICE` siguiente cuando detecta un vaciado intensivo. Sin embargo, solo activa este resultado después de que el vaciado haya estado activo durante al menos dos minutos.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Para obtener más información sobre el vaciado intensivo, consulte [When an aggressive vacuum is already running](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
Puede comprobar si se está realizando un vaciado intensivo con la siguiente consulta:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
Para determinar si se trata de un vaciado intensivo (para evitar el reinicio), compruebe la columna de consulta del resultado. La expresión “para evitar el reinicio” indica que se trata de un vaciado intensivo.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Por ejemplo, supongamos que hay un bloqueador en el valor de antigüedad de transacciones de 1000 millones y una tabla que requiere un vaciado intensivo para evitar el reinicio a esa misma antigüedad de transacciones. Además, hay otro bloqueador en el valor de antigüedad de transacciones de 750 millones. Tras superar el bloqueador en el valor de antigüedad de transacciones de 1000 millones, la antigüedad no se reducirá inmediatamente a 750 millones. Seguirá siendo alta hasta que se complete la tabla que necesita el vaciado intensivo o cualquier transacción con una antigüedad superior a los 750 millones. Durante este período, la antigüedad de las transacciones de su clúster de PostgreSQL seguirá aumentando. Una vez que se complete el proceso de vaciado, la antigüedad de las transacciones se reducirá a 750 millones, pero volverá a aumentar de nuevo hasta que se finalice todo el vaciado. Este ciclo continuará mientras se mantengan estas condiciones, hasta que la antigüedad de las transacciones finalmente se reduzca hasta el nivel configurado para su instancia de Amazon RDS, especificado por `autovacuum_freeze_max_age`.
# Explicación de los mensajes de tipo NOTICE en RDS para PostgreSQL
La función `postgres_get_av_diag()` proporciona los siguientes mensajes de tipo NOTICE:
**Cuando la antigüedad aún no ha alcanzado aún el umbral de supervisión**
El umbral de supervisión para que `postgres_get_av_diag()` identifique los bloqueadores es de 500 millones de transacciones por defecto. Si `postgres_get_av_diag()` genera el siguiente mensaje NOTICE, indica que la antigüedad de la transacción aún no ha alcanzado este umbral.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**No está conectado a la base de datos que tenga la antigüedad del ID de transacción más antiguo**
La función `postgres_get_av_diag()` proporciona el resultado más preciso cuando se conecta a la base de datos con el ID de transacción más antiguo. En su caso, la base de datos con el ID de transacción más antiguo notificada por `postgres_get_av_diag()` será diferente a “my\$1database”. Si no se ha conectado a la base de datos correcta, se generará el siguiente mensaje tipo NOTICE:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
Conectarse a la base de datos con la antigüedad de transacción más antigua es importante por las siguientes razones:
+ **Identificar los bloqueadores de tablas temporales:** dado que los metadatos de las tablas temporales son específicos de cada base de datos, normalmente se encuentran en la base de datos en la que se crearon. Sin embargo, si una tabla temporal resulta ser la que más bloquea y reside en la base de datos con la transacción más antigua, esta información podría resultar engañosa. La conexión a la base de datos correcta garantiza la identificación precisa del bloqueador de tablas temporal.
+ **Diagnóstico de vaciados lentos:** los metadatos del índice y la información sobre el recuento de tablas son específicos de la base de datos y son necesarios para diagnosticar los problemas de vaciado lento.
**La base de datos con la transacción más antigua se encuentra en una base de datos rdsadmin o template0**
En algunos casos, las bases de datos `rdsadmin` o `template0` pueden identificarse como la base de datos con el ID de transacción más antiguo. Si esto ocurre, `postgres_get_av_diag()` emitirá el siguiente mensaje de tipo NOTICE:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Compruebe que el bloqueador de la lista no se haya originado en ninguna de estas dos bases de datos. Si se notifica que el bloqueador está presente en `rdsadmin` o `template0` de ellas, póngase en contacto con el servicio de asistencia, ya que estas bases de datos no son accesibles para el usuario y requieren intervención.
Es muy poco probable que las bases de datos `rdsadmin` o `template0` contengan un bloqueador principal.
**Cuando ya está en curso un vaciado intensivo**
La función `postgres_get_av_diag()` está diseñada para notificar si se está ejecutando un proceso de vaciado intensivo, pero solo activa esta salida después de que el vaciado haya estado activo durante al menos 1 minuto. Este retraso intencionado ayuda a reducir las probabilidades de que se produzcan falsos positivos. Mediante esta espera, la función garantiza que solo se registren los vaciados efectivos y significativos, lo que permite una supervisión más precisa y fiable de la actividad de vaciado.
La función `postgres_get_av_diag()` genera el siguiente mensaje de tipo NOTICE cuando detecta que se están realizando uno o varios vaciados intensivos.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Como se indica en el mensaje NOTICE, siga supervisando el rendimiento del vaciado. Para obtener más información acerca del vaciado intensivo, consulte [Se está ejecutando un vaciado intensivo (para evitar el reinicio)](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
**Cuando el vaciado intensivo está apagado**
La función `postgres_get_av_diag()` genera el siguiente mensaje NOTICE si el autovacuum está deshabilitado en la instancia de la base de datos:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
Autovacuum es una característica fundamental de la instancia de base de datos de RDS para PostgreSQL que garantiza un funcionamiento fluido de la base de datos. Elimina automáticamente las versiones de filas antiguas, recupera espacio de almacenamiento y evita que las tablas se sobrecarguen, lo que ayuda a mantener la eficiencia de las tablas y los índices para lograr un rendimiento óptimo. Además, protege contra el reinicio de los identificadores de transacciones, lo que puede detener las transacciones en su instancia de Amazon RDS. La desactivación del autovacuum puede provocar una disminución a largo plazo del rendimiento y la estabilidad de la base de datos. Le sugerimos que lo mantenga activado todo el tiempo. Para obtener más información, consulte [Descripción de autovacuum en entornos de RDS para PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
La desactivación de autovacuum no detiene los vaciados intensivos. Seguirán produciéndose una vez que las tablas alcancen el umbral de `autovacuum_freeze_max_age`.
**El número de transacciones pendientes es críticamente bajo**
La función `postgres_get_av_diag()` genera el siguiente mensaje de tipo NOTICE cuando un vaciado previo al reinicio es inminente. Este mensaje NOTICE se emite cuando su instancia de Amazon RDS está a 100 millones de transacciones de la posibilidad de rechazar nuevas transacciones.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
Es necesario realizar acciones inmediatas para evitar el tiempo de inactividad de la base de datos. Debe supervisar de cerca sus operaciones de vaciado y considerar la posibilidad de iniciar manualmente un `VACUUM FREEZE` en la base de datos afectada para evitar errores en las transacciones.
# Administración de recuentos de objetos altos en Amazon RDS para PostgreSQL
Aunque las limitaciones de PostgreSQL son teóricas, tener recuentos de objetos extremadamente altos en una base de datos provocará un impacto notable en el rendimiento de varias operaciones. Esta documentación cubre varios tipos de objetos comunes que, cuando tienen un recuento total alto, pueden tener varios posibles impactos.
En la tabla siguiente, se proporciona un resumen de los tipos de objetos y sus posibles impactos:
**Tipos de objetos e impactos potenciales**
| Tipo de objeto | Limpieza automática | Replicación lógica | Actualización de la versión principal | pg\$1dump/pg\$1restore | Rendimiento general | Reinicio de la instancia |
| --- | --- | --- | --- | --- | --- | --- |
| [Relaciones](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Tablas temporales](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Tablas sin registrar](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Particiones](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [Archivos temporales](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Secuencias](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Objetos grandes](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relaciones
No hay un límite estricto específico en cuanto al número de tablas en una base de datos de PostgreSQL. El límite teórico es extremadamente alto, pero hay otros límites prácticos que deben tenerse en cuenta al diseñar la base de datos.
**Impacto: la limpieza automática se queda atrás**
La limpieza automática puede tener dificultades para mantenerse al día con el crecimiento de ID de transacciones o la sobrecarga de la tabla debido a la falta de personal en comparación con la cantidad de trabajo.
**Acción recomendada:** existen varios factores para ajustar la limpieza automática a fin de que pueda funcionar correctamente con un número determinado de tablas y una carga de trabajo determinada. Consulte [Prácticas recomendadas para trabajar con la limpieza automática de PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) para obtener sugerencias sobre cómo determinar la configuración de limpieza automática adecuada. Utilice la [utilidad postgres\$1get\$1av\$1diag](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html) para supervisar los problemas relacionados con el crecimiento de ID de transacción.
**Impacto: actualización de la versión principal/pg\$1dump y restauración**
Amazon RDS utiliza la opción “--link” durante la ejecución de pg\$1upgrade para evitar tener que hacer copias de los archivos de datos. Aun así, es necesario restaurar los metadatos del esquema en la nueva versión de la base de datos. Incluso con pg\$1restore paralelo, si hay un número significativo de relaciones, esto aumentará la cantidad de tiempo de inactividad.
**Impacto: degradación general del rendimiento**
Degradación general del rendimiento debido al tamaño del catálogo. Cada tabla y sus columnas asociadas se agregarán a las tablas de `pg_attribute`, `pg_class` y `pg_depend` que se utilizan con frecuencia en las operaciones normales de la base de datos. No habrá ningún evento de espera específico visible, pero la eficiencia del búfer compartido se verá afectada.
**Acción recomendada:** compruebe con regularidad la sobrecarga de la tabla para estas tablas específicas y, de vez en cuando, realice una operación `VACUUM FULL` en estas tablas específicas. Tenga en cuenta que `VACUUM FULL` en las tablas del catálogo requiere un bloqueo `ACCESS EXCLUSIVE`, lo que significa que ninguna otra consulta podrá acceder a ellas hasta que se complete la operación.
**Impacto: agotamiento de los descriptores de archivos**
Error: “No hay suficientes descriptores de archivos: hay demasiados archivos abiertos en el sistema; libérelos y vuelva a intentarlo”. El parámetro `max_files_per_process` de PostgreSQL determina cuántos archivos puede abrir cada proceso. Si hay un número elevado de conexiones que se unen a un número elevado de tablas, es posible alcanzar este límite.
**Acción recomendada:**
+ La reducción del valor del parámetro `max_files_per_process` puede ayudar a solventar este error. Cada proceso y subproceso (por ejemplo, una consulta paralela) puede abrir este número de archivos y, si las consultas unen varias tablas, este límite puede agotarse.
+ Reduzca el número total de conexiones y utilice un agrupador de conexiones como [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) u otras soluciones como PgBouncer. Para obtener más información, consulte el sitio web de [PgBouncer](https://www.pgbouncer.org/).
**Impacto: agotamiento de inodos**
Error: “Falta de espacio en el dispositivo”. Si esto se observa cuando hay suficiente espacio libre de almacenamiento, se debe a que se están agotando los inodos. La [Supervisión mejorada de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) proporciona visibilidad de los inodos en uso y del número máximo disponible para el host.
**Umbral aproximado:** [millones](#PostgreSQL.HighObjectCount.Note)
## Tablas temporales
El uso de tablas temporales es útil para datos de prueba o resultados intermedios y es un patrón común que se observa en muchos motores de bases de datos. Hay que entender las implicaciones del uso intensivo de PostgreSQL para evitar algunas de las dificultades. Cada tabla temporal creada y eliminada agregará filas a las tablas del catálogo del sistema, lo que, cuando se sobrecargue, provocará problemas generales de rendimiento.
**Impacto: la limpieza automática se queda atrás**
Las tablas temporales no se aspiran con limpieza automática, sino que conservan los ID de las transacciones durante su existencia y, si no se retiran, pueden quedar ocultas.
**Acción recomendada:** las tablas temporales permanecerán activas mientras dure la sesión en la que se crearon o se pueden eliminar manualmente. Una práctica recomendada consiste en evitar las transacciones de larga duración con tablas temporales para evitar que estas tablas contribuyan al máximo crecimiento de los ID de transacción utilizados.
**Impacto: degradación general del rendimiento**
Degradación general del rendimiento debido al tamaño del catálogo. Cuando las sesiones crean y descartan tablas temporales de forma continua, se agregan a tablas de `pg_attribute`, `pg_class` y `pg_depend` que se utilizan con frecuencia en las operaciones normales de la base de datos. No habrá ningún evento de espera específico visible, pero la eficiencia del búfer compartido se verá afectada.
**Acción recomendada:**
+ compruebe con regularidad la sobrecarga de la tabla para estas tablas específicas y, de vez en cuando, realice una operación `VACUUM FULL` en estas tablas específicas. Tenga en cuenta que `VACUUM FULL` en las tablas del catálogo requiere un bloqueo `ACCESS EXCLUSIVE`, lo que significa que ninguna otra consulta podrá acceder a ellas hasta que se complete la operación.
+ Si se utilizan mucho las tablas temporales, antes de actualizar una versión principal, se recomienda encarecidamente utilizar una operación `VACUUM FULL` de estas tablas de catálogo específicas para reducir el tiempo de inactividad.
**Prácticas recomendadas generales:**
+ reduzca el uso de tablas temporales mediante el uso de expresiones de tablas comunes para obtener resultados intermedios. A veces, esto puede complicar las consultas necesarias, pero se eliminarán los impactos mostrados anteriormente.
+ Reutilice las tablas temporales mediante el comando `TRUNCATE` para borrar el contenido en lugar de realizar los pasos de eliminar o crear. Esto también eliminará el problema del crecimiento del ID de transacción provocado por las tablas temporales.
**Umbral aproximado:** [decenas de miles](#PostgreSQL.HighObjectCount.Note)
## Tablas sin registrar
Las tablas no registradas pueden ofrecer mejoras de rendimiento, ya que no generarán ninguna información de WAL. Se deben usar con cuidado, ya que no ofrecen durabilidad durante la recuperación de un error de la base de datos, ya que se truncarán. Esta es una operación costosa en PostgreSQL, ya que cada tabla no registrada se trunca en serie. Aunque esta operación es rápida para un número reducido de tablas sin registrar, cuando se cuentan por miles, puede empezar a provocar un retraso notable durante el inicio.
**Impacto: replicación lógica**
Por lo general, las tablas no registradas no se incluyen en la replicación lógica, como [implementaciones azul/verde](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), porque la replicación lógica se basa en WAL para capturar y transferir los cambios.
**Impacto: tiempo de inactividad prolongado durante la recuperación**
Durante cualquier estado de la base de datos que implique la recuperación de errores de la base de datos, como el reinicio multi-AZ con conmutación por error, la recuperación en un momento dado de Amazon RDS y la actualización de la versión principal de Amazon RDS, se producirá la operación serializada de truncar las tablas no registradas. Esto puede provocar un tiempo de inactividad mucho mayor de lo esperado.
**Acción recomendada:**
+ minimice el uso de tablas no registradas solo para los datos cuya pérdida es aceptable durante las operaciones de recuperación tras un error de la base de datos.
+ Minimice el uso de tablas no registradas, ya que el comportamiento actual del truncamiento en serie puede provocar que el inicio de una base de datos tarde mucho tiempo.
**Prácticas recomendadas generales:**
+ Las tablas no registradas no son a pruebas de errores. En PostgreSQL, iniciar una recuperación en un momento dado, que implica una recuperación por error, lleva mucho tiempo, ya que se trata de un proceso en serie que trunca cada tabla.
**Umbral aproximado:** [miles](#PostgreSQL.HighObjectCount.Note)
## Particiones
El particionamiento puede aumentar el rendimiento de las consultas y proporcionar una organización lógica de los datos. En situaciones ideales, el particionamiento se organiza de manera que se pueda utilizar la depuración de particiones durante la planificación y ejecución de las consultas. El uso de demasiadas particiones puede tener un impacto negativo en el rendimiento de las consultas y en el mantenimiento de la base de datos. La elección de cómo particionar una tabla debe hacerse con cuidado, ya que un diseño deficiente puede afectar negativamente al rendimiento de la planificación y ejecución de las consultas. Consulte la [documentación de PostgreSQL](https://www.postgresql.org/docs/current/ddl-partitioning.html) para obtener más información sobre las particiones.
**Impacto: degradación general del rendimiento**
A veces, la sobrecarga de tiempo de planificación aumentará y la explicación de los planes para las consultas se volverá más complicada, lo que dificultará la identificación de las oportunidades de ajuste. En el caso de las versiones de PostgreSQL anteriores a la 18, muchas particiones con una gran carga de trabajo pueden provocar esperas de `LWLock:LockManager`.
**Acción recomendada:** determine un número mínimo de particiones que permita completar la organización de los datos y, al mismo tiempo, ejecutar las consultas de forma eficaz.
**Impacto: complejidad del mantenimiento**
Un número muy elevado de particiones provocará dificultades de mantenimiento, como la creación previa y la eliminación. La limpieza automática tratará las particiones como si fueran relaciones normales y tendrá que realizar una limpieza periódica, por lo que necesitará un número suficiente de trabajadores para completar la tarea.
**Acción recomendada:**
+ asegúrese de crear previamente las particiones para que la carga de trabajo no se bloquee cuando se necesite una nueva partición (por ejemplo, particiones mensuales) y se eliminen las particiones antiguas.
+ Asegúrese de tener suficientes trabajadores de limpieza automática para llevar a cabo la limpieza y el mantenimiento normales de todas las particiones.
**Umbral aproximado:** [cientos](#PostgreSQL.HighObjectCount.Note)
## Archivos temporales
A diferencia de las tablas temporales mencionadas anteriormente, PostgreSQL crea los archivos temporales cuando una consulta compleja puede realizar varias operaciones de ordenación y hash al mismo tiempo, y cada una de ellas utiliza memoria de la instancia para almacenar los resultados hasta el valor especificado en el parámetro `work_mem`. Cuando la memoria de la instancia no es suficiente, se crean archivos temporales para almacenar los resultados. Consulte [Administración de archivos temporales](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) para obtener más información sobre los archivos temporales. Si la carga de trabajo genera un número alto de estos archivos, puede haber varios impactos.
**Impacto: agotamiento de los descriptores de archivos**
Error: “No hay suficientes descriptores de archivos: hay demasiados archivos abiertos en el sistema; libérelos y vuelva a intentarlo”. El parámetro `max_files_per_process` de PostgreSQL determina cuántos archivos puede abrir cada proceso. Si hay un número elevado de conexiones que se unen a un número elevado de tablas, es posible alcanzar este límite.
**Acción recomendada:**
+ La reducción del valor del parámetro `max_files_per_process` puede ayudar a solventar este error. Cada proceso y subproceso (por ejemplo, una consulta paralela) puede abrir este número de archivos y, si las consultas unen varias tablas, este límite puede agotarse.
+ Reduzca el número total de conexiones y utilice un agrupador de conexiones como [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) u otras soluciones como PgBouncer. Para obtener más información, consulte el sitio web de [PgBouncer](https://www.pgbouncer.org/).
**Impacto: agotamiento de inodos**
Error: “Falta de espacio en el dispositivo”. Si esto se observa cuando hay suficiente espacio libre de almacenamiento, se debe a que se están agotando los inodos. La [Supervisión mejorada de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) proporciona visibilidad de los inodos en uso y del número máximo disponible para el host.
**Prácticas recomendadas generales:**
+ Supervise el uso de los archivos temporales con [Información de rendimiento](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
+ Ajuste las consultas que generan archivos temporales importantes para ver si es posible reducir el número total de archivos temporales.
**Umbral aproximado:** [miles](#PostgreSQL.HighObjectCount.Note)
## Secuencias
Las secuencias son el objeto subyacente que se utiliza para incrementar automáticamente las columnas en PostgreSQL y proporcionan exclusividad y una clave para los datos. Se pueden usar en tablas individuales sin consecuencias durante las operaciones normales, con una excepción de la replicación lógica.
En PostgreSQL, la replicación lógica actualmente no replica el valor actual de una secuencia a ningún suscriptor. Para obtener más información, consulte [Página de restricciones en la documentación de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Impacto: se prolongó el tiempo de conmutación**
Si planea usar [Implementaciones azules/verdes de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) para cualquier tipo de cambio o actualización de configuración, es importante que comprenda el impacto de un gran número de secuencias en la conmutación. Una de las últimas fases de la conmutación sincronizará el valor actual de las secuencias y, si hay varios miles, aumentará el tiempo total de conmutación.
**Acción recomendada:** si la carga de trabajo de la base de datos permitiera el uso de un UUID compartido en lugar de un enfoque de secuencia por tabla, esto reduciría el paso de sincronización durante una conmutación.
**Umbral aproximado:** [miles](#PostgreSQL.HighObjectCount.Note)
## Objetos grandes
Los objetos grandes se almacenan en una sola tabla del sistema llamada pg\$1largeobject. Cada objeto grande también tiene una entrada en la tabla del sistema pg\$1largeobject\$1metadata. Estos objetos se crean, modifican y limpian de forma muy diferente a las relaciones estándar. Los objetos grandes no se manipulan con limpieza automática y deben limpiarse periódicamente mediante un proceso independiente llamado vacuumlo. Consulte la sección sobre administración de objetos grandes con el módulo lo para ver ejemplos sobre la administración de objetos grandes.
**Impacto: replicación lógica**
Los objetos grandes no se replican actualmente en PostgreSQL durante la replicación lógica. Para obtener más información, consulte [Página de restricciones en la documentación de PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). En una configuración [azul/verde](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), esto significa que los objetos grandes del entorno azul no se replican en el entorno verde.
**Impacto: actualización a la versión principal**
Una actualización puede quedarse sin memoria y fallar si hay millones de objetos grandes y la instancia no puede gestionarlos durante una actualización. El proceso de actualización a la versión principal de PostgreSQL consta de dos amplias fases: el volcado del esquema a través de pg\$1dump y la restauración de este a través de pg\$1restore. Si su base de datos tiene millones de objetos de gran tamaño, debe asegurarse de que la instancia tenga memoria suficiente para gestionar pg\$1dump y pg\$1restore durante una actualización y escalarla a un tipo de instancia más grande.
**Prácticas recomendadas generales:**
+ Use regularmente la utilidad vacuumlo para eliminar cualquier objeto grande huérfano que pueda tener.
+ Considere la posibilidad de utilizar el tipo de datos BYTEA para almacenar los objetos grandes en la base de datos.
**Umbral aproximado:** [millones](#PostgreSQL.HighObjectCount.Note)
## Umbrales aproximados
Los umbrales aproximados que se mencionan en este tema solo se utilizan para proporcionar una estimación de hasta qué punto puede escalar un recurso en particular. Representan el rango general en el que los impactos descritos son más probables, pero el comportamiento real depende de la carga de trabajo, el tamaño de la instancia y la configuración específicos. Aunque es posible superar estas estimaciones, se deben respetar los cuidados y el mantenimiento para evitar los impactos mostrados.
# Administración de la contención de TOAST OID en Amazon RDS para PostgreSQL
TOAST (la técnica de almacenamiento de atributos sobredimensionados) es una característica de PostgreSQL diseñada para gestionar valores de datos de gran tamaño que superan el tamaño típico de un bloque de base de datos de 8 KB. PostgreSQL no permite que las filas físicas abarquen varios bloques. El tamaño del bloque actúa como límite superior del tamaño de las filas. TOAST supera esta restricción al dividir los valores de campo grandes en fragmentos más pequeños. Los almacena de forma independiente en una tabla TOAST específica vinculada a la tabla principal. Para obtener más información, consulte la [documentación de implementación y mecanismo de almacenamiento de PostgreSQL TOAST](https://www.postgresql.org/docs/current/storage-toast.html).
**Topics**
+ [
## Descripción de las operaciones de TOAST
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [
## Identificación de los desafíos de rendimiento
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [
## Recomendaciones
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [
## Supervisión
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## Descripción de las operaciones de TOAST
TOAST realiza la compresión y almacena valores de campo grandes fuera de línea. TOAST asigna un OID (identificador de objeto) único a cada fragmento de datos sobredimensionados almacenados en la tabla TOAST. La tabla principal almacena el ID del valor TOAST y el ID de relación en la página para hacer referencia a la fila correspondiente de la tabla TOAST. Esto permite a PostgreSQL localizar y administrar de forma eficiente estos fragmentos de TOAST. Sin embargo, a medida que crece la tabla de TOAST, el sistema corre el riesgo de agotar los OID disponibles, lo que provoca una degradación del rendimiento y un posible tiempo de inactividad debido al agotamiento de los OID.
### Identificadores de objetos en TOAST
Un identificador de objeto (OID) es un identificador único de todo el sistema que PostgreSQL utiliza para hacer referencia a objetos de bases de datos, como tablas, índices y funciones. Estos identificadores desempeñan un papel fundamental en las operaciones internas de PostgreSQL, ya que permiten a la base de datos localizar y administrar los objetos de forma eficiente.
Para las tablas con conjuntos de datos elegibles para acciones de toast, PostgreSQL asigna los OID para identificar de forma única cada fragmento de datos sobredimensionados almacenado en la tabla TOAST asociada. El sistema asocia cada fragmento con un `chunk_id`, lo que ayuda a PostgreSQL a organizar y ubicar estos fragmentos de manera eficiente dentro de la tabla TOAST.
## Identificación de los desafíos de rendimiento
La administración del OID de PostgreSQL se basa en un contador global de 32 bits para poder agrupar después de generar 4 mil millones de valores únicos. Aunque el clúster de bases de datos comparte este contador, la asignación del OID implica dos pasos durante las operaciones TOAST:
+ **Contador global de asignación**: el contador global asigna un nuevo OID a todo el clúster.
+ **Búsqueda local de conflictos**: la tabla TOAST garantiza que el nuevo OID no entre en conflicto con los OID existentes que ya se utilizan en esa tabla específica.
La degradación del rendimiento puede producirse cuando:
+ La tabla TOAST tiene una alta fragmentación o un uso denso del OID, lo que provoca retrasos en la asignación del OID.
+ Con frecuencia, el sistema asigna y reutiliza los OID en entornos con fragmentos de datos altos o tablas amplias que utilizan TOAST de forma extensiva.
Para obtener más información, consulte los [límites de tamaño de las tablas TOAST de PostgreSQL y la documentación de asignación de OID](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit):
Un contador global genera los OID y los agrupa cada 4000 millones de valores, de modo que, de vez en cuando, el sistema vuelve a generar un valor ya utilizado. PostgreSQL lo detecta y lo vuelve a intentar con el siguiente OID. Se puede producir INSERT lento si hay una serie muy larga de valores OID usados sin espacios en blanco en la tabla TOAST. Estos desafíos se hacen más pronunciados a medida que se va llenando el espacio del OID, lo que hace que las inserciones y actualizaciones sean más lentas.
### Identificación del problema
+ Las instrucciones `INSERT` simples tardan mucho más de lo habitual de forma incoherente y aleatoria.
+ Solo se producen retrasos en las instrucciones `INSERT` y `UPDATE` que implican operaciones de TOAST.
+ Las siguientes entradas de registro aparecen en los registros de PostgreSQL cuando el sistema tiene dificultades para encontrar los OID disponibles en las tablas TOAST:
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ La información de rendimiento indica un número elevado de sesiones activas de media (AAS) asociadas a eventos de espera `LWLock:buffer_io` y `LWLock:OidGenLock`.
Puede ejecutar la siguiente consulta SQL para identificar las transacciones INSERT de larga duración con eventos de espera:
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Ejemplos de resultados de consulta que muestran operaciones INSERT con tiempos de espera prolongados:
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Aislamiento del problema
+ **Pruebe una inserción pequeña**: inserte un registro más pequeño que el umbral `toast_tuple_target`. Recuerde que la compresión se aplica antes del almacenamiento de TOAST. Si esto funciona sin problemas de rendimiento, el problema está relacionado con las operaciones de TOAST.
+ **Pruebe la tabla nueva**: cree una tabla nueva con la misma estructura e ingrese un registro más grande que `toast_tuple_target`. Si esto funciona sin problemas, el problema se localiza en la asignación OID de la tabla original.
## Recomendaciones
Los siguientes enfoques pueden ayudar a resolver los problemas de contención de TOAST OID.
+ **Limpieza y archivado de datos**: revise y elimine cualquier dato obsoleto o innecesario para liberar los OID para su uso futuro o archive los datos. Tenga en cuenta las siguientes restricciones:
+ Escalabilidad limitada, ya que es posible que no siempre sea posible realizar limpiezas en el futuro.
+ Posible operación VACUUM de larga duración para eliminar las tuplas inactivas resultantes.
+ **Escriba en una tabla nueva**: cree una tabla nueva para futuras inserciones y utilice una vista `UNION ALL` para combinar datos antiguos y nuevos para las consultas. Esta vista presenta los datos combinados de las tablas antiguas y nuevas, lo que permite a las consultas acceder a ellos como una sola tabla. Tenga en cuenta las siguientes restricciones:
+ Es posible que las actualizaciones de la tabla antigua sigan agotando los OID.
+ **Partición o fragmento**: particione los datos de la tabla o del fragmento para mejorar la escalabilidad y el rendimiento. Tenga en cuenta las siguientes restricciones:
+ El aumento de la complejidad de la lógica y el mantenimiento de las consultas, y la posible necesidad de realizar cambios en las aplicaciones para gestionar correctamente los datos particionados.
## Supervisión
### Uso de tablas de sistemas
Puede utilizar las tablas del sistema de PostgreSQL para supervisar el aumento del uso de los OID.
**aviso**
En función del número de OID de la tabla de TOAST, puede tardar un tiempo en completarse. Le recomendamos que programe la supervisión fuera del horario laboral para minimizar el impacto.
El siguiente bloque anónimo cuenta el número de OID distintos que se utilizan en cada tabla de TOAST y muestra la información de la tabla principal:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Ejemplo de salida que muestra las estadísticas de uso de los OID por tabla de TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
El siguiente bloque anónimo recupera el OID máximo asignado para cada tabla de TOAST que no esté vacía:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Ejemplo de salida que muestra el número máximo de ID de fragmentos para las tablas de TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Uso de información sobre rendimiento
Los eventos de espera `LWLock:buffer_io` y `LWLock:OidGenLock` aparecen en la información de rendimiento durante las operaciones que requieren la asignación de nuevos identificadores de objeto (OID). El promedio alto de sesiones activas (AAS) de estos eventos suele indicar que hay problemas durante la asignación de los OID y la administración de los recursos. Esto es particularmente común en entornos con una alta cantidad de datos, un uso extensivo de datos de gran tamaño o una creación frecuente de objetos.
#### LWLock:buffer\$1io
`LWLock:buffer_io` es un evento de espera que se produce cuando una sesión de PostgreSQL espera a que se completen las operaciones de E/S en un búfer compartido. Esto suele ocurrir cuando la base de datos lee datos del disco a la memoria o escribe páginas modificadas de la memoria al disco. El evento de espera de `BufferIO` garantiza la coherencia al impedir que varios procesos accedan o modifiquen el mismo búfer mientras las operaciones de E/S están en curso. La alta incidencia de este evento de espera puede indicar cuellos de botella en el disco o una actividad de E/S excesiva en la carga de trabajo de la base de datos.
Durante las operaciones de TOAST:
+ PostgreSQL asigna los OID a los objetos grandes y garantiza su exclusividad escaneando el índice de la tabla de TOAST.
+ Los índices de TOAST de gran tamaño pueden requerir el acceso a varias páginas para verificar la exclusividad de los OID. Esto se traduce en un aumento de la E/S del disco, especialmente cuando el grupo de búferes no puede almacenar en caché todas las páginas requeridas.
El tamaño del índice afecta directamente a la cantidad de páginas del búfer a las que se debe acceder durante estas operaciones. Incluso si el índice no está sobrecargado, su gran tamaño puede aumentar la E/S del búfer, especialmente en entornos de alta concurrencia o alta rotación. Para obtener más información, consulte la [LWLock:BufferIO wait event troubleshooting guide](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html).
#### LWLock:OidGenLock
`OidGenLock` es un evento de espera que se produce cuando una sesión de PostgreSQL está esperando para asignar un nuevo identificador de objetos (OID). Este bloqueo garantiza que los OID se generen de forma secuencial y segura, lo que permite que solo un proceso genere los OID a la vez.
Durante las operaciones de TOAST:
+ **Asignación de OID para los fragmentos de la tabla de TOAST**: PostgreSQL asigna los OID a los fragmentos de las tablas de TOAST al administrar registros de datos de gran tamaño. Cada OID debe ser único para evitar conflictos en el catálogo del sistema.
+ **Alta simultaneidad**: dado que el acceso al generador de OID es secuencial, cuando varias sesiones crean simultáneamente objetos que requieren OID, se puede producir contención para `OidGenLock`. Esto aumenta la probabilidad de que las sesiones esperen a que se complete la asignación de los OID.
+ **Dependencia del acceso al catálogo del sistema**: la asignación de los OID requiere actualizaciones en las tablas del catálogo del sistema compartido, como `pg_class` y `pg_type`. Si estas tablas tienen mucha actividad (debido a las frecuentes operaciones de DDL), puede aumentar la contención de bloqueos para `OidGenLock`.
+ **Alta demanda de asignación del OID**: las cargas de trabajo pesadas de TOAST con registros de datos de gran tamaño requieren una asignación coherente del OID, lo que aumenta la contención.
Factores adicionales que aumentan la contención del OID:
+ **Creación frecuente de objetos**: las cargas de trabajo que crean y descartan objetos con frecuencia, como tablas temporales, aumentan la contención en el contador de OID global.
+ **Bloqueo del contador global**: se accede en serie al contador de OID global para garantizar su exclusividad, lo que crea un único punto de contención en entornos de alta concurrencia.
## Uso de mecanismos de registro admitidos por RDS for PostgreSQL
Hay varios parámetros, extensiones y otros elementos configurables que puede establecer para registrar actividades que ocurren en su instancia de base de datos de PostgreSQL. Estos incluyen los siguientes:
+ El parámetro `log_statement` se puede usar para registrar la actividad del usuario en su base de datos de PostgreSQL. Para obtener más información sobre el registro de RDS for PostgreSQL y cómo monitorear los registros, consulte [Archivos de registro de base de datos de RDS para PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.md).
+ El parámetro `rds.force_admin_logging_level` registra las acciones del usuario interno de Amazon RDS (rdsadmin) en las bases de datos de la instancia de base de datos. Escribe la salida en el registro de errores de PostgreSQL. Los valores permitidos son `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, registro, `fatal`, y `panic`. El valor predeterminado es `disabled`.
+ El parámetro `rds.force_autovacuum_logging_level` se puede configurar para capturar varias operaciones autovacuum en el registro de errores de PostgreSQL. Para obtener más información, consulte [Registro de actividades de autovacuum y vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ La extensión PostgreSQL Audit (pgAudit) se puede instalar y configurar para capturar actividades a nivel de sesión o a nivel de objeto. Para obtener más información, consulte [Uso de pgAudit para registrar la actividad de la base de datos](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ La extensión `log_fdw` le permite acceder al registro del motor de la base de datos mediante SQL. Para obtener más información, consulte [Uso de la extensión log\$1fdw para acceder al registro de base de datos mediante SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ La biblioteca `pg_stat_statements` se especifica como predeterminada para el parámetro `shared_preload_libraries` en la versión 10 y superiores de RDS for PostgreSQL. Es esta biblioteca la que puede usar para analizar consultas en ejecución. Asegúrese de que `pg_stat_statements` se establezca en el grupo de parámetros de base de datos. Para obtener más información sobre cómo supervisar su instancia de base de datos de RDS for PostgreSQL por medio de la información que proporciona esta biblioteca, consulte [Estadísticas de SQL de RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ El parámetro `log_hostname` captura en el registro el nombre de host de cada conexión de cliente. Para RDS para PostgreSQL versión 12 y posteriores, este parámetro se establece como `off` de forma predeterminada. Si lo activa, asegúrese de supervisar los tiempos de conexión de las sesiones. Cuando está activado, el servicio utiliza la solicitud de búsqueda inversa del sistema de nombres de dominio (DNS) para obtener el nombre de host del cliente que realiza la conexión y agregarlo al registro de PostgreSQL. Esto tiene un impacto notable durante la conexión a la sesión. Le recomendamos que active este parámetro solo para resolver problemas.
En términos generales, el objetivo del registro es que el DBA pueda supervisar, ajustar el rendimiento y solucionar problemas. Muchos de los registros se cargan automáticamente en Amazon CloudWatch o en Información sobre rendimiento. Aquí, se ordenan y agrupan para proporcionar métricas completas para su instancia de base de datos. Para obtener más información sobre la supervisión y las métricas de Amazon RDS, visite [Supervisión de métricas en una instancia de Amazon RDS](CHAP_Monitoring.md).
# Administración de archivos temporales con PostgreSQL
En PostgreSQL, una consulta compleja puede realizar varias operaciones de ordenación y hash al mismo tiempo, y cada una de ellas utiliza memoria de la instancia para almacenar los resultados hasta el valor especificado en el parámetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Cuando la memoria de la instancia no es suficiente, se crean archivos temporales para almacenar los resultados. Se escriben en el disco para completar la ejecución de la consulta. Posteriormente, una vez finalizada la consulta, estos archivos se eliminan automáticamente. En RDS para PostgreSQL, estos archivos se almacenan en Amazon EBS en el volumen de datos. Para obtener más información, consulte [Almacenamiento de instancias de base de datos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Puede monitorizar la métrica de `FreeStorageSpace` publicada en CloudWatch para asegurarse de que la instancia de base de datos tenga suficiente espacio de almacenamiento libre. Para obtener más información, consulte [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm)..
Recomendamos utilizar instancias de lecturas optimizadas para Amazon RDS para las cargas de trabajo que implican múltiples consultas simultáneas que aumentan el uso de archivos temporales. Estas instancias utilizan almacenamiento por bloques local basado en unidades de estado sólido (SSD) de memoria rápida no volátil (NVMe) para colocar los archivos temporales. Para obtener más información, consulte [Mejora del rendimiento de las consultas de RDS para PostgreSQL con lecturas optimizadas para Amazon RDS](USER_PostgreSQL.optimizedreads.md).
Puede utilizar los siguientes parámetros y funciones para administrar los archivos temporales de la instancia.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – este parámetro cancela cualquier consulta que supere el tamaño de temp\$1files en KB. Este límite evita que cualquier consulta se ejecute de forma indefinida y consuma espacio en disco con archivos temporales. Puede calcular el valor utilizando los resultados del parámetro `log_temp_files`. Como práctica recomendada, examine el comportamiento de la carga de trabajo y establezca el límite de acuerdo con la estimación. En el siguiente ejemplo, se cancela una consulta cuando se supera el límite.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – este parámetro envía mensajes a postgresql.log cuando se eliminan los archivos temporales de una sesión. Este parámetro produce registros después de que la consulta se complete correctamente. Por lo tanto, puede que no ayude a solucionar problemas de consultas activas y de larga ejecución.
El ejemplo siguiente muestra que, cuando la consulta se completa correctamente, las entradas se registran en el archivo postgresql.log y se limpian los archivos temporales.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – esta función que está disponible desde RDS para PostgreSQL 13 y versiones posteriores proporciona visibilidad sobre el uso actual de los archivos temporales. La consulta completada no aparece en los resultados de la función. En el siguiente ejemplo, puede ver los resultados de esta función.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
El nombre del archivo incluye el ID de procesamiento (PID) de la sesión que generó el archivo temporal. Una consulta más avanzada, como en el ejemplo siguiente, realiza una suma de los archivos temporales de cada PID.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – si activa el parámetro pg\$1stat\$1statements, puede ver el uso medio de archivos temporales por llamada. Puede identificar el query\$1id de la consulta y usarlo para examinar el uso de archivos temporales, como se muestra en el siguiente ejemplo.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`**: en el panel de Información sobre el rendimiento, puede ver el uso temporal de los archivos activando las métricas **temp\$1bytes** y **temp\$1files**. A continuación, puede ver la media de estas dos métricas y cómo se corresponden con la carga de trabajo de la consulta. La vista de Información sobre el rendimiento no muestra específicamente las consultas que generan los archivos temporales. Sin embargo, al combinar Información sobre el rendimiento con la consulta que se muestra para `pg_ls_tmpdir`, puede solucionar problemas, realizar análisis y determinar los cambios en la carga de trabajo de la consulta.
Para obtener más información sobre cómo analizar métricas y consultas con Información de rendimiento, consulte [Análisis de métricas mediante el panel de Información sobre rendimiento](USER_PerfInsights.UsingDashboard.md).
Para ver un ejemplo sobre la visualización del uso de archivos temporales con Información de rendimiento, consulte [Visualización del uso de archivos temporales con Información de rendimiento](PostgreSQL.ManagingTempFiles.Example.md)
# Visualización del uso de archivos temporales con Información de rendimiento
Puede usar Información de rendimiento para consultar el uso de archivos temporales activando las métricas **temp\$1bytes** y **temp\$1files**. En Información de rendimiento, la vista no muestra las consultas específicas que generan archivos temporales; sin embargo, si combina Información de rendimiento con la consulta mostrada para `pg_ls_tmpdir`, puede solucionar problemas, realizar análisis y determinar cuáles son los cambios necesarios en la carga de trabajo de consultas.
1. En el panel de Información sobre el rendimiento, elija **Administrar métricas**.
1. Elija las **Métricas de la base de datos** y seleccione las métricas **temp\$1bytes** y **temp\$1files** como se muestra en la siguiente captura de pantalla.
![\[Las métricas se muestran en el gráfico.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. En la pestaña **Principales SQL**, seleccione el icono **Preferencias**.
1. En la ventana **Preferencias**, active las siguientes estadísticas para que aparezcan en la pestaña **Principales SQL** y seleccione **Continuar**.
+ Escrituras temporales por segundo
+ Lecturas temporales por segundo
+ Escritura temporal en bloque por llamada
+ Lectura temporal en bloque por llamada
1. El archivo temporal se divide cuando se combina con la consulta mostrada para `pg_ls_tmpdir`, como se observa en el siguiente ejemplo.
![\[Consulta que muestra el uso de archivos temporales.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Los eventos `IO:BufFileRead` y `IO:BufFileWrite` se producen cuando las consultas principales de la carga de trabajo crean archivos temporales a menudo. Puede utilizar la Información de rendimiento para identificar las principales consultas pendientes en `IO:BufFileRead` e `IO:BufFileWrite` mediante la revisión del promedio de sesiones activas (AAS) en las secciones de carga de base de datos y SQL principales.
![\[IO:BufFileRead e IO:BufFileWrite en el gráfico.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Para obtener más información sobre cómo analizar las consultas principales y cargar mediante eventos de espera con Información de Rendimiento, consulte [Información general sobre la pestaña Top SQL (SQL principal)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Debe identificar y ajustar las consultas que provocan el aumento del uso de archivos temporales y los eventos de espera relacionados. Para obtener más información sobre estos eventos de espera y su corrección, consulte [IO:BufFileRead e IO:BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html).
**nota**
El parámetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) controla cuándo se agota la memoria de la operación de ordenación y los resultados se escriben en archivos temporales. Se recomienda no cambiar la configuración de este parámetro por encima del valor predeterminado, ya que haría que cada sesión de base de datos consumiera más memoria. Además, una sola sesión que realiza combinaciones y ordenaciones complejas puede realizar operaciones paralelas en las que cada operación consume memoria.
Como práctica recomendada, cuando tenga un informe de gran tamaño con múltiples combinaciones y ordenaciones, defina este parámetro en el nivel de sesión mediante el comando `SET work_mem`. Por tanto, el cambio solo se aplica a la sesión actual y no cambia el valor globalmente.
## Uso de pgBadger para el análisis de registros con PostgreSQL
Puede usar un analizador de registros como [pgbadger](http://dalibo.github.io/pgbadger/) para analizar los registros de PostgreSQL. La documentación de pgBadger establece que el patrón %l (la línea de registro para la sesión o el proceso) debe ser parte del prefijo. Sin embargo, si proporciona el RDS actual `log_line_prefix` como parámetro a pgBadger, aún debería generar un informe.
Por ejemplo, el siguiente comando asigna el formato correcto a un archivo de registro de Amazon RDS para PostgreSQL con fecha 04-02-2014 con pgbadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## Uso de PGSnapper para supervisar PostgreSQL
Puede utilizar PGSnapper para facilitar la recopilación periódica de estadísticas y métricas relacionadas con el rendimiento de Amazon RDS para PostgreSQL. Para obtener más información, consulte[ Monitor Amazon RDS for PostgreSQL performance using PGSnapper](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/) (Supervise el rendimiento de Amazon RDS para PostgreSQL con PGSnapper).
# Gestión de conversiones personalizadas en RDS para PostgreSQL
La **conversión de tipos** en PostgreSQL es el proceso de convertir un valor de un tipo de dato a otro. PostgreSQL proporciona conversiones integradas para muchas transformaciones comunes, pero también puede crear conversiones personalizadas para definir cómo deben comportarse determinadas conversiones entre tipos.
Una conversión especifica cómo se lleva a cabo la transformación de un tipo de dato a otro. Por ejemplo, convertir texto `'123'` en entero `123` o numérico `45.67` en texto `'45.67'`.
Para obtener información completa sobre los conceptos y la sintaxis de la conversión de PostgreSQL, consulte la documentación CREATE CAST de [PostgreSQL](https://www.postgresql.org/docs/current/sql-createcast.html).
A partir de las versiones 13.23, 14.20, 15.15, 16.11, 17.7 y 18.1 de RDS para PostgreSQL, puede utilizar la extensión rds\$1casts para instalar conversiones adicionales para tipos integrados, sin dejar de poder crear sus propias conversiones para tipos personalizados.
**Topics**
+ [
## Instalación y uso de la extensión rds\$1casts
](#PostgreSQL.CustomCasts.Installing)
+ [
## Conversiones compatibles
](#PostgreSQL.CustomCasts.Supported)
+ [
## Creación o eliminación de conversiones
](#PostgreSQL.CustomCasts.Creating)
+ [
## Creación de conversiones personalizadas con la estrategia de contexto adecuada
](#PostgreSQL.CustomCasts.BestPractices)
## Instalación y uso de la extensión rds\$1casts
Para crear la extensión `rds_casts`, conéctese a la instancia de DB de RDS para PostgreSQL como un `rds_superuser` y ejecute el siguiente comando:
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Conversiones compatibles
Cree la extensión en cada base de datos en la que desee utilizar conversiones personalizadas. Tras crear la extensión, utilice el siguiente comando para ver todas las conversiones disponibles:
```
SELECT * FROM rds_casts.list_supported_casts();
```
Esta función muestra las combinaciones de conversión disponibles (tipo de fuente, tipo de objetivo, contexto de coerción y función de conversión). Por ejemplo, si desea crear `text` a `numeric` como una conversión de `implicit`. Puede utilizar la siguiente consulta para buscar si la conversión está disponible para crearse:
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
La extensión rds\$1casts proporciona dos tipos de funciones de conversión para cada conversión:
+ *\$1inout functions*: utilizar el mecanismo de conversión de E/S estándar de PostgreSQL, que se comporta de forma idéntica a las conversiones creadas con el método INOUT.
+ *\$1custom functions*: proporcionar una lógica de conversión mejorada que gestione casos de periferia, como convertir cadenas vacías en valores NULL para evitar errores de conversión.
Las funciones `inout` reproducen el comportamiento de conversión nativo de PostgreSQL, mientras que las funciones `custom` amplían esta funcionalidad al gestionar situaciones que las conversiones de INOUT estándar no pueden admitir, como la conversión de cadenas vacías en números enteros.
## Creación o eliminación de conversiones
Puede crear y soltar conversiones compatibles mediante dos métodos:
### Creación de conversión
**Método 1: usar el comando nativo CREATE CAST**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Método 2: usar la función rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
La función `create_cast` toma el ID del resultado `list_supported_casts()`. Este método es más sencillo y garantiza que se utilice la combinación correcta de función y contexto. Se garantiza que este identificador seguirá siendo el mismo en las diferentes versiones de Postgres.
Para comprobar que la conversión se creó correctamente, consulte el catálogo del sistema pg\$1cast:
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
La columna `castcontext` muestra: `e` para EXPLICIT, `a` para ASSIGNMENT o `i` para IMPLICIT.
### Cómo soltar las conversiones
**Método 1: usar el comando DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Método 2: usar la función rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
La función `drop_cast` utiliza el mismo identificador que se utilizó al crear la conversión. Este método garantiza que suelte la conversión exacta que se creó con el ID correspondiente.
## Creación de conversiones personalizadas con la estrategia de contexto adecuada
Al crear varias conversiones para tipos enteros, se pueden producir errores de ambigüedad de operadores si todas las conversiones se crean como IMPLICIT. El siguiente ejemplo muestra este problema mediante la creación de dos conversiones implícitas de texto a anchuras de enteros diferentes:
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
El error se produce porque PostgreSQL no puede determinar qué conversión implícita utilizar al comparar una columna de enteros con un valor de texto. Tanto la conversión implícita int4 como la int8 son candidatas válidas, lo que crea ambigüedad.
Para evitar esta ambigüedad de operadores, utilice el contexto ASSIGNMENT para anchuras de enteros más pequeñas y el contexto IMPLICIT para anchuras de enteros más grandes:
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
Con esta estrategia, solo la conversión int8 es implícita, por lo que PostgreSQL puede determinar sin ambigüedades qué conversión utilizar.
# Prácticas recomendadas para consultas paralelas en RDS para PostgreSQL
La ejecución de consultas paralelas es una característica de PostgreSQL que permite dividir una sola consulta SQL en tareas más pequeñas que se procesan simultáneamente mediante varios procesos de trabajo en segundo plano. En lugar de ejecutar una consulta por completo en un único proceso de backend, PostgreSQL puede distribuir partes de la consulta, como análisis, uniones, agregaciones o clasificación, en varios núcleos de CPU. El *proceso líder* coordina esta ejecución y recopila los resultados de los *trabajadores paralelos*.
Sin embargo, para la mayoría de las cargas de trabajo de producción, especialmente para los sistemas OLTP de alta concurrencia, recomendamos desactivar la ejecución automática de consultas en paralelo. Aunque el paralelismo puede acelerar las consultas en grandes conjuntos de datos en las cargas de trabajo de análisis o elaboración de informes, presenta riesgos importantes que, a menudo, superan los beneficios en entornos de producción muy ajetreados.
La ejecución paralela también supone una sobrecarga significativa. Cada servidor paralelo es un proceso completo de backend de PostgreSQL, que requiere la bifurcación del proceso (copiar las estructuras de la memoria e inicializar el estado del proceso) y la autenticación (consumir los espacios de conexión hasta el límite `max_connections`). Cada trabajador también consume su propia memoria, incluso `work_mem` para las operaciones de clasificación y cifrado, con varios trabajadores por consulta, el uso de la memoria se multiplica rápidamente (por ejemplo, 4 trabajadores × 64 MB `work_mem` = 256 MB por consulta). Como resultado, las consultas paralelas pueden consumir considerablemente más recursos del sistema que las consultas de un solo proceso. Si no se ajustan correctamente, pueden provocar una saturación de la CPU (varios trabajadores abruman la capacidad de procesamiento disponible), un aumento del cambio de contexto (el sistema operativo cambia con frecuencia entre varios procesos de trabajo, lo que aumenta la sobrecarga y reduce el rendimiento) o el agotamiento de la conexión (dado que cada trabajador paralelo consume una ranura de conexión, una sola consulta con 4 trabajadores utiliza 5 conexiones en total, 1 líder \$1 4 trabajadores, lo que puede agotar rápidamente el grupo de conexiones con una alta concurrencia, lo que impide nuevas conexiones de clientes y provoca errores en las aplicaciones). Estos problemas son particularmente graves en cargas de trabajo de alta concurrencia en las que varias consultas pueden intentar ejecutarse en paralelo simultáneamente.
PostgreSQL decide si utilizar el paralelismo en función de las estimaciones de costos. En algunos casos, el planificador puede cambiar automáticamente a un plan paralelo si parece más económico, incluso cuando no es lo ideal en la práctica. Esto puede suceder si las estadísticas de los índices están desactualizadas o si la sobrecarga hace que los análisis secuenciales parezcan más atractivos que las búsquedas de índices. Debido a este comportamiento, los planes paralelos automáticos a veces pueden presentar regresiones en el rendimiento de las consultas o en la estabilidad del sistema.
Para aprovechar al máximo las consultas paralelas en RDS para PostgreSQL, es importante probarlas y ajustarlas en función de la carga de trabajo, supervisar el impacto en el sistema y desactivar la selección automática de planes paralelos en favor del control por consulta.
## Parámetros de configuración
PostgreSQL utiliza varios parámetros para controlar el comportamiento y la disponibilidad de las consultas paralelas. Comprenderlos y ajustarlos es fundamental para lograr un rendimiento predecible:
| Parámetro | Descripción | Valor predeterminado |
| --- | --- | --- |
| max\$1parallel\$1workers | Número máximo de procesos de trabajo en segundo plano que se pueden ejecutar en total | GREATEST(\$1DBInstanceVCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Número máximo de trabajadores por nodo del plan de consultas (por ejemplo, por Gather) | 2 |
| parallel\$1setup\$1cost | Se ha agregado el costo del planificador para iniciar la infraestructura de consultas paralelas | 1 000 |
| parallel\$1tuple\$1cost | Costo por tupla procesada en modo paralelo (afecta a la decisión del planificador) | 0.1 |
| force\$1parallel\$1mode | Obliga al planificador a probar planes paralelos (off, on, regress) | off |
### Consideraciones clave
+ `max_parallel_workers` controla el grupo total de trabajadores paralelos. Si se establece un valor demasiado bajo, algunas consultas pueden volver a ejecutarse en serie.
+ `max_parallel_workers_per_gather` afecta al número de trabajadores que puede utilizar una sola consulta. Un valor más alto aumenta la simultaneidad, pero también el uso de los recursos.
+ `parallel_setup_cost` y `parallel_tuple_cost` afectan al modelo de costos del planificador. Reducirlos puede hacer que sea más probable que se elijan planes paralelos.
+ `force_parallel_mode` es útil para realizar pruebas, pero no se debe utilizar en producción a menos que sea necesario.
**nota**
El valor predeterminado del parámetro `max_parallel_workers` se calcula dinámicamente en función del tamaño de la instancia mediante la fórmula `GREATEST($DBInstanceVCPU/2, 8)`. Esto significa que al escalar la instancia de base de datos a un tamaño de procesamiento mayor con más vCPU, el número máximo de trabajadores paralelos disponibles aumentará automáticamente. Como resultado, las consultas que antes se ejecutaban en serie o con un paralelismo limitado pueden utilizar repentinamente más trabajadores paralelos después de una operación de escalar verticalmente, lo que podría provocar aumentos inesperados en el uso de la conexión, la utilización de la CPU y el consumo de memoria. Es importante supervisar el comportamiento de las consultas en paralelo después de cualquier evento de escalado de computación y ajustar `max_parallel_workers_per_gather` si es necesario para mantener un uso predecible de los recursos.
## Identificación del uso de consultas paralelas
Las consultas pueden pasar a planes paralelos en función de la distribución de datos o las estadísticas. Por ejemplo:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Esta consulta puede usar un índice para datos recientes, pero cambiar a un análisis secuencial paralelo para datos históricos.
Puede registrar los planes de ejecución de consultas cargando el módulo `auto_explain`. Para obtener más información, consulte [Logging execution plans of queries](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) (Registro de los planes de ejecución de las consultas) en el centro de conocimiento de AWS.
Puede supervisar la [Información sobre las bases de datos de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) para detectar eventos de espera relacionados con consultas paralelas. Obtención de más información sobre los eventos de espera relacionados con consultas paralelas, mediante [Eventos de espera de IPC:parallel](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html)
A partir de la versión 18 de PostgreSQL, puede supervisar la actividad de los trabajadores en paralelo mediante columnas nuevas en [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW) y [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html):
+ `parallel_workers_to_launch`: número de trabajadores paralelos que se prevé lanzar
+ `parallel_workers_launched`: número de trabajadores paralelos realmente lanzados
Estas métricas ayudan a identificar las discrepancias entre el paralelismo planificado y el real, lo que puede indicar limitaciones de recursos o problemas de configuración. Utilice las siguientes consultas para supervisar la ejecución paralela:
Para las métricas de trabajadores paralelos por base de datos:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Para las métricas de trabajadores paralelos por consulta
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Cómo controlar el paralelismo
Existen varias formas de controlar el paralelismo de consultas, cada una diseñada para diferentes escenarios y requisitos.
Para desactivar el paralelismo automático de forma global, [modifique el grupo de parámetros](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html) para establecer:
```
max_parallel_workers_per_gather = 0;
```
Para configuraciones persistentes y específicas del usuario, el comando ALTER ROLE proporciona una forma de establecer los parámetros que se aplicarán a todas las sesiones futuras de un usuario en particular.
Por ejemplo:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;` garantiza que cada vez que este usuario se conecte a la base de datos, sus sesiones utilizarán esta configuración de trabajo paralelo cuando sea necesario.
El control por sesión se puede lograr mediante el comando SET, que modifica los parámetros durante la sesión de la base de datos actual. Esto resulta especialmente útil cuando se deben ajustar temporalmente los ajustes sin que ello afecte a otros usuarios o sesiones futuras. Una vez configurados, estos parámetros permanecen en vigor hasta que se restablezcan explícitamente o hasta que finalice la sesión. Los comandos son sencillos:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Para un control aún más detallado, SET LOCAL permite modificar los parámetros de una sola transacción. Esto resulta ideal cuando se necesita ajustar la configuración para un conjunto específico de consultas dentro de una transacción, tras lo cual la configuración vuelve automáticamente a sus valores anteriores. Este enfoque ayuda a evitar efectos no deseados en otras operaciones de la misma sesión.
## Diagnóstico del comportamiento de consultas paralelas
Se usa `EXPLAIN (ANALYZE, VERBOSE)` para confirmar si una consulta utilizó la ejecución paralela:
+ Busque nodos como `Gather`, `Gather Merge` o `Parallel Seq Scan`.
+ Compare planes con y sin paralelismo.
Para desactivar temporalmente el paralelismo para la comparación:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL
En algunos casos, puede crear una instancia de base de datos de RDS for PostgreSQL sin especificar un grupo de parámetros personalizado. De ser el caso, la instancia de base de datos se crea por medio del grupo de parámetros predeterminado para la versión de PostgreSQL que elija. Por ejemplo, suponga que crea una instancia de base de datos de RDS for PostgreSQL por medio de la versión 13.3 de PostgreSQL. En este caso, la instancia de base de datos se crea por medio de los valores del grupo de parámetros para las versiones 13 de PostgreSQL, `default.postgres13`.
También puede crear su propio grupo de parámetros de base de datos personalizado. Debe hacer esto si desea modificar cualquier configuración para la instancia de base de datos de RDS for PostgreSQL a partir de sus valores predeterminados. Para aprender a hacerlo, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Puede realizar un seguimiento de la configuración en su instancia de base de datos de RDS for PostgreSQL de varias maneras diferentes. Puede utilizar la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS. También puede consultar los valores de la tabla `pg_settings` de PostgreSQL de la instancia, como se muestra a continuación.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Para obtener más información sobre los valores que se muestran en esta consulta, consulte [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) en la documentación de PostgreSQL.
Tenga especial cuidado cuando cambie la configuración de `max_connections` y `shared_buffers` en la instancia de base de datos de RDS for PostgreSQL. Por ejemplo, suponga que modifica la configuración para `max_connections` o `shared_buffers` y utiliza valores que son demasiado altos para la carga de trabajo real. En este caso, su instancia de base de datos de RDS for PostgreSQL no se iniciará. Si esto ocurre, verá un error como el siguiente en el `postgres.log`.
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Sin embargo, no puede cambiar ningún valor de la configuración contenida en los grupos de parámetros de base de datos de RDS for PostgreSQL predeterminados. Para cambiar la configuración de cualquier parámetro, primero cree un grupo de parámetros de base de datos personalizado. Luego, cambie la configuración en ese grupo personalizado y, luego, aplique el grupo de parámetros personalizado a su instancia de base de datos de RDS for PostgreSQL. Para obtener más información, consulte [Grupos de parámetros para Amazon RDS](USER_WorkingWithParamGroups.md).
Hay dos tipos de parámetros en RDS para PostgreSQL.
+ **Parámetros estáticos**: los parámetros estáticos requieren que la instancia de la base de datos RDS for PostgreSQL se reinicie después de un cambio para que el nuevo valor tenga efecto.
+ **Parámetros dinámicos**: los parámetros dinámicos no requieren un reinicio después de cambiar su configuración.
**nota**
Si su instancia de base de datos de RDS for PostgreSQL utiliza su propio grupo de parámetros de base de datos personalizado, puede cambiar los valores de los parámetros dinámicos en la instancia de base de datos en ejecución. Puede hacerlo mediante la Consola de administración de AWS, la AWS CLI o la API de Amazon RDS.
Si tiene privilegios para hacerlo, también puede cambiar los valores de los parámetros con los comandos `ALTER DATABASE`, `ALTER ROLE` y `SET`.
## Lista de parámetros de la instancia de base de datos de RDS for PostgreSQL
La siguiente tabla enumera algunos de (pero no todos) los parámetros disponibles en una instancia de base de datos RDS for PostgreSQL. Para ver todos los parámetros disponibles, utilice el comando [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) de AWS CLI. Por ejemplo, para obtener la lista de todos los parámetros disponibles en el grupo de parámetros predeterminado de RDS para PostgreSQL versión 13, ejecute lo siguiente.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
También puede usar la consola. Elija **grupos de parámetros** en el menú de Amazon RDS y, a continuación, elija el grupo de parámetros entre los disponibles en suRegión de AWS.
| Nombre del parámetro | Apply\$1Type | Descripción |
| --- | --- | --- |
| `application_name` | Dinámico | Define el nombre de la aplicación sobre la que informarán las estadísticas y los registros. |
| `archive_command` | Dinámico | Establece el comando del shell que se llamará para archivar un archivo WAL. |
| `array_nulls` | Dinámico | Permite la entrada de elementos NULL en matrices. |
| `authentication_timeout` | Dinámico | Establece el tiempo máximo permitido para completar una autenticación del cliente. |
| `autovacuum` | Dinámico | Inicia el subproceso de autovacuum. |
| `autovacuum_analyze_scale_factor` | Dinámico | Número de inserciones, actualizaciones o eliminaciones de tuplas previas al análisis como una fracción de reltuples. |
| `autovacuum_analyze_threshold` | Dinámico | Número mínimo de inserciones, actualizaciones o eliminaciones de tuplas previas al análisis. |
| `autovacuum_freeze_max_age` | Estático | Antigüedad con la que se debe aplicar autovacuum a una tabla para impedir el reinicio de los ID. |
| `autovacuum_naptime` | Dinámico | Tiempo de reposo entre ejecuciones de autovacuum. |
| `autovacuum_max_workers` | Estático | Define el número máximo de procesos de empleados de autovacuum que se ejecutan simultáneamente. |
| `autovacuum_vacuum_cost_delay` | Dinámico | Retardo del costo del vacío, en milisegundos, para autovacuum. |
| `autovacuum_vacuum_cost_limit` | Dinámico | Importe del costo del vacío disponible antes del periodo de reposo para autovacuum. |
| `autovacuum_vacuum_scale_factor` | Dinámico | Número de actualizaciones o eliminaciones de tuplas previas al vacío como una fracción de reltuples. |
| `autovacuum_vacuum_threshold` | Dinámico | Número mínimo de actualizaciones o eliminaciones de tuplas previas al vacío. |
| `backslash_quote` | Dinámico | Define si se admite una barra diagonal invertida (\$1) en el texto de las cadenas. |
| `bgwriter_delay` | Dinámico | Tiempo de reposo del escritor de segundo plano entre una ronda y la siguiente. |
| `bgwriter_lru_maxpages` | Dinámico | Número máximo de páginas de LRU del escritor de segundo plano que se deben vaciar en cada ronda. |
| `bgwriter_lru_multiplier` | Dinámico | Múltiplo del uso medio del búfer que se debe liberar en cada ronda. |
| `bytea_output` | Dinámico | Establece el formato de salida para bytes. |
| `check_function_bodies` | Dinámico | Comprueba los cuerpos de las funciones durante la ejecución de CREATE FUNCTION. |
| `checkpoint_completion_target` | Dinámico | Tiempo requerido para vaciar los búferes sucios durante el punto de comprobación expresado como una fracción del intervalo del punto de comprobación. |
| `checkpoint_segments` | Dinámico | Define la distancia máxima en los segmentos de registro entre los puntos de comprobación de registro previo a la lectura (WAL) automáticos. |
| `checkpoint_timeout` | Dinámico | Define el tiempo máximo entre los puntos de comprobación de WAL automáticos. |
| `checkpoint_warning` | Dinámico | Habilita las advertencias si los segmentos del punto de comprobación se rellenan con una frecuencia superior a esta. |
| `client_connection_check_interval` | Dinámico | Establece el intervalo de tiempo entre las comprobaciones de desconexión mientras se ejecutan las consultas. |
| `client_encoding` | Dinámico | Define la codificación del conjunto de caracteres del cliente. |
| `client_min_messages` | Dinámico | Define los niveles de los mensajes que se envían al cliente. |
| `commit_delay` | Dinámico | Define el retardo en microsegundos entre la confirmación de la transacción y el vaciado de WAL al disco. |
| `commit_siblings` | Dinámico | Define el número mínimo de transacciones abiertas concurrentes antes de ejecutar commit\$1delay. |
| `constraint_exclusion` | Dinámico | Habilita el planificador para que use restricciones con el fin de optimizar las consultas. |
| `cpu_index_tuple_cost` | Dinámico | Define la estimación del planificador del costo de procesar cada entrada de índice durante un examen del índice. |
| `cpu_operator_cost` | Dinámico | Define la estimación del planificador del costo de procesar cada llamada a operador o a función. |
| `cpu_tuple_cost` | Dinámico | Define la estimación del planificador del costo de procesar cada tupla (fila). |
| `cursor_tuple_fraction` | Dinámico | Define la estimación del planificador de la fracción de las filas de un cursor que se recuperarán. |
| `datestyle` | Dinámico | Define el formato de visualización para los valores de fecha y hora. |
| `deadlock_timeout` | Dinámico | Define el tiempo de espera de una interrupción antes de comprobar si se ha producido un bloqueo. |
| `debug_pretty_print` | Dinámico | Aplica una sangría a las visualizaciones del árbol de análisis y de planificación. |
| `debug_print_parse` | Dinámico | Registra el árbol de análisis de cada consulta. |
| `debug_print_plan` | Dinámico | Registra el plan de ejecución de cada consulta. |
| `debug_print_rewritten` | Dinámico | Registra el árbol de análisis reescrito de cada consulta. |
| `default_statistics_target` | Dinámico | Define el objetivo de estadística predeterminado. |
| `default_tablespace` | Dinámico | Define el espacio de tabla predeterminado en el que se deben crear las tablas y los índices. |
| `default_transaction_deferrable` | Dinámico | Define el estado diferible predeterminado de las nuevas transacciones. |
| `default_transaction_isolation` | Dinámico | Define el nivel de aislamiento de cada nueva transacción. |
| `default_transaction_read_only` | Dinámico | Define el estado de solo lectura predeterminado de las nuevas transacciones. |
| `default_with_oids` | Dinámico | Crea nuevas tablas con ID de objeto (OID) de forma predeterminada. |
| `effective_cache_size` | Dinámico | Define la suposición del planificador sobre el tamaño de la caché de disco. |
| `effective_io_concurrency` | Dinámico | Número de solicitudes simultáneas que el subsistema del disco puede gestionar de un modo eficiente. |
| `enable_bitmapscan` | Dinámico | Habilita el uso de planes de examen de mapas de bits por parte del planificador. |
| `enable_hashagg` | Dinámico | Habilita el uso de planes de agregación con hash por parte del planificador. |
| `enable_hashjoin` | Dinámico | Habilita el uso de planes de unión con hash por parte del planificador. |
| `enable_indexscan` | Dinámico | Habilita el uso de planes de examen de índice por parte del planificador. |
| `enable_material` | Dinámico | Habilita el uso de la materialización por parte del planificador. |
| `enable_mergejoin` | Dinámico | Habilita el uso de planes de unión de fusión por parte del planificador. |
| `enable_nestloop` | Dinámico | Habilita el uso de planes de unión de bucle anidado por parte del planificador. |
| `enable_seqscan` | Dinámico | Habilita el uso de planes de examen secuencial por parte del planificador. |
| `enable_sort` | Dinámico | Habilita el uso de pasos de ordenación explícitos por parte del planificador. |
| `enable_tidscan` | Dinámico | Habilita el uso de planes de examen de TID por parte del planificador. |
| `escape_string_warning` | Dinámico | Advierte sobre los caracteres de escape de barra diagonal invertida (\$1) en el texto de las cadenas ordinarias. |
| `extra_float_digits` | Dinámico | Define el número de dígitos que se muestran para los valores de punto flotante. |
| `from_collapse_limit` | Dinámico | Define el tamaño FROM-list por encima del cual las subconsultas no se contraen. |
| `fsync` | Dinámico | Fuerza la sincronización de las actualizaciones del disco. |
| `full_page_writes` | Dinámico | Escribe páginas completas en WAL la primera vez que se modifican después de un punto de comprobación. |
| `geqo` | Dinámico | Habilita la optimización genética de consultas. |
| `geqo_effort` | Dinámico | GEQO: effort se usa para definir el ajuste predeterminado de otros parámetros de GEQO. |
| `geqo_generations` | Dinámico | GEQO: número de iteraciones del algoritmo. |
| `geqo_pool_size` | Dinámico | GEQO: número de individuos de la población. |
| `geqo_seed` | Dinámico | GEQO: valor de inicialización para la selección de ruta aleatoria. |
| `geqo_selection_bias` | Dinámico | GEQO: presión selectiva dentro de la población. |
| `geqo_threshold` | Dinámico | Define el umbral de los elementos FROM por encima de los cuales se usa GEQO. |
| `gin_fuzzy_search_limit` | Dinámico | Define el resultado máximo permitido para la búsqueda exacta por GIN. |
| `hot_standby_feedback` | Dinámico | Determina si un servidor de espera en caliente envía mensajes de retroalimentación al servidor primario o de subida en espera. |
| `intervalstyle` | Dinámico | Define el formato de visualización para los valores de intervalo. |
| `join_collapse_limit` | Dinámico | Define el tamaño FROM-list por encima del cual las construcciones JOIN no se aplanan. |
| `lc_messages` | Dinámico | Define el idioma en el que se muestran los mensajes. |
| `lc_monetary` | Dinámico | Define la configuración regional para el formato de las cantidades monetarias. |
| `lc_numeric` | Dinámico | Define la configuración regional para el formato de los números. |
| `lc_time` | Dinámico | Define la configuración regional para el formato de los valores de fecha y hora. |
| `log_autovacuum_min_duration` | Dinámico | Define el tiempo de ejecución mínimo por encima del cual se registrarán las acciones de autovacuum. |
| `log_checkpoints` | Dinámico | Registra cada punto de comprobación. |
| `log_connections` | Dinámico | Registra cada conexión realizada correctamente. |
| `log_disconnections` | Dinámico | Registra el final de una sesión, incluida su duración. |
| `log_duration` | Dinámico | Registra la duración de cada declaración de SQL completada. |
| `log_error_verbosity` | Dinámico | Define el detalle de los mensajes registrados. |
| `log_executor_stats` | Dinámico | Escribe las estadísticas de rendimiento del ejecutor en el registro del servidor. |
| `log_filename` | Dinámico | Define el patrón del nombre de archivo para los archivos de registro. |
| `log_file_mode` | Dinámico | Establece los permisos de los archivos de registro. El valor predeterminado es 0644. |
| `log_hostname` | Dinámico | Registra el nombre del host en los registros de conexión. A partir de PostgreSQL 12 y versiones posteriores, este parámetro está desactivado de forma predeterminada. Cuando se activa, la conexión utiliza la búsqueda inversa de DNS para obtener el nombre de host que se captura en los registros de conexión. Si activa este parámetro, debe supervisar el impacto que tiene en el tiempo que se tarda en establecer las conexiones. |
| `log_line_prefix ` | Dinámico | Controla la información prefijada en cada línea de registro. |
| `log_lock_waits` | Dinámico | Registra las esperas de bloqueo largas. |
| `log_min_duration_statement` | Dinámico | Define el tiempo de ejecución mínimo por encima del cual se registrarán las instrucciones. |
| `log_min_error_statement` | Dinámico | Hace que todas las declaraciones que generen un error en este nivel o por encima de él se registren. |
| `log_min_messages` | Dinámico | Define los niveles de los mensajes que se registran. |
| `log_parser_stats` | Dinámico | Escribe las estadísticas de desempeño del analizador en el registro del servidor. |
| `log_planner_stats` | Dinámico | Escribe las estadísticas de desempeño del planificador en el registro del servidor. |
| `log_rotation_age` | Dinámico | Se producirá una rotación automática del archivo de registro después de N minutos. |
| `log_rotation_size` | Dinámico | Se producirá una rotación automática del archivo de registro después de N kilobytes. |
| `log_statement` | Dinámico | Define el tipo de declaraciones que se deben registrar. |
| `log_statement_stats` | Dinámico | Escribe las estadísticas de desempeño acumulativas en el registro del servidor. |
| `log_temp_files` | Dinámico | Registra el uso de archivos temporales con un tamaño superior a este número de kilobytes. |
| `log_timezone` | Dinámico | Establece la zona horaria que se usará en los mensajes de registro. |
| `log_truncate_on_rotation` | Dinámico | Permite truncar los archivos de registro existentes con el mismo nombre durante la rotación del registro. |
| `logging_collector` | Estático | Inicia un subproceso para capturar el resultado de stderr o csvlogs en archivos de registro. |
| `maintenance_work_mem` | Dinámico | Define la memoria máxima que se debe usar para las operaciones de mantenimiento. |
| `max_connections` | Estático | Define el número máximo de conexiones simultáneas. |
| `max_files_per_process` | Estático | Define el número máximo de archivos abiertos simultáneamente para cada proceso del servidor. |
| `max_locks_per_transaction` | Estático | Define el número máximo de bloqueos por transacción. |
| `max_pred_locks_per_transaction` | Estático | Define el número máximo de bloqueos de predicado por transacción. |
| `max_prepared_transactions` | Estático | Define el número máximo de transacciones preparadas simultáneamente. |
| `max_stack_depth` | Dinámico | Define la profundidad máxima de la pila en kilobytes. |
| `max_standby_archive_delay` | Dinámico | Define el retardo máximo antes de la cancelación de consultas cuando un servidor de espera en caliente está procesando los datos de WAL archivados. |
| `max_standby_streaming_delay` | Dinámico | Define el retardo máximo antes de la cancelación de consultas cuando un servidor de espera en caliente está procesando los datos de WAL transmitidos. |
| max\$1wal\$1size | Dinámico | Establece el tamaño de WAL (MB) que lanza un punto de comprobación. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Use el comando siguiente en la instancia de base de datos de Amazon RDS para PostgreSQL para ver su valor actual: SHOW max_wal_size;
|
| min\$1wal\$1size | Dinámico | Establece el tamaño mínimo al que reducir el WAL. Para la versión 9.6 de PostgreSQL y anteriores, min\$1wal\$1size está en unidades de 16 MB. Para la versión 10 de PostgreSQL y posteriores, min\$1wal\$1size está en unidades de 1 MB. |
| `quote_all_identifiers` | Dinámico | Añade comillas (") a todos los identificadores cuando se generan fragmentos SQL. |
| `random_page_cost` | Dinámico | Define la estimación del planificador del coste de una página de disco que no se recupera secuencialmente. Este parámetro no tiene valor a menos que la administración del plan de consultas (QPM) esté activada. Cuando QPM está activado, el valor predeterminado para este parámetro es 4. |
| rds.adaptive\$1autovacuum | Dinámico | Ajusta automáticamente los parámetros autovacuum cuando se superan los umbrales del identificador de transacción. |
| rds.force\$1ssl | Dinámico | Requiere el uso de conexiones SSL. El valor predeterminado se establece en 1 (activado) para RDS para la versión 15 de PostgreSQL. Todas las demás versiones de RDS para PostgreSQL 14 principal y anteriores tienen el valor predeterminado establecido en 0 (desactivado). |
| `rds.local_volume_spill_enabled` | Estático | Permite escribir archivos de vertidos lógicos en el volumen local. |
| `rds.log_retention_period` | Dinámico | Establece la retención de registros de manera que Amazon RDS elimina los registros de PostgreSQL que sobrepasan n minutos. |
| rds.rds\$1superuser\$1reserved\$1connections | Estático | Establece el número de ranuras de conexión reservadas para rds\$1superusers. Este parámetro solo está disponible en la versión 15 y anteriores. Para obtener más información, consulte la documentación de PostgreSQL sobre [reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). |
| `rds.replica_identity_full` | Dinámico | Al establecer este parámetro en `on`, invalida la configuración de identidad de réplica a `FULL` para todas las tablas de la base de datos. Esto significa que todos los valores de las columnas se escriben en el registro de escritura anticipada (WAL), independientemente de la configuración de `REPLICA IDENTITY FULL`. La activación de este parámetro puede aumentar las IOPS de la instancia de base de datos debido al registro WAL adicional. |
| rds.restrict\$1password\$1commands | Estático | Restringe quién puede administrar contraseñas de los usuarios con el rol rds\$1password. Establezca este parámetro en 1 para habilitar la restricción de contraseñas. El valor predeterminado es 0. |
| `search_path` | Dinámico | Define el orden de búsqueda del esquema para los nombres que no cumplen los requisitos del esquema. |
| `seq_page_cost` | Dinámico | Define la estimación del planificador del costo de una página de disco que se recupera secuencialmente. |
| `session_replication_role` | Dinámico | Define el comportamiento de las sesiones para los desencadenadores y las reglas de reescritura. |
| `shared_buffers` | Estático | Define el número de búferes de memoria compartida utilizados por el servidor. |
| `shared_preload_libraries ` | Estático | Enumera las bibliotecas compartidas para precargar en la instancia de base de datos de RDS para PostgreSQL. Los valores admitidos son: auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler y plrust. |
| `ssl` | Dinámico | Habilita las conexiones SSL. |
| `sql_inheritance` | Dinámico | Hace que las subtablas se incluyan de manera predeterminada en varios comandos. |
| `ssl_renegotiation_limit` | Dinámico | Define la cantidad de tráfico que se debe enviar y recibir antes de renegociar las claves de cifrado. |
| `standard_conforming_strings` | Dinámico | Hace que las cadenas ... traten las barras diagonales invertidas literalmente. |
| `statement_timeout` | Dinámico | Establece la duración máxima permitida de cualquier declaración. |
| `synchronize_seqscans` | Dinámico | Habilita los exámenes secuenciales sincronizados. |
| `synchronous_commit` | Dinámico | Define el nivel de sincronización de las transacciones actuales. |
| `tcp_keepalives_count` | Dinámico | Número máximo de retransmisiones de keepalive de TCP. |
| `tcp_keepalives_idle` | Dinámico | Tiempo entre emisiones de keepalive de TCP. |
| `tcp_keepalives_interval` | Dinámico | Tiempo entre retransmisiones de keepalive de TCP. |
| `temp_buffers` | Dinámico | Define el número máximo de búferes temporales utilizados por cada sesión. |
| temp\$1file\$1limit | Dinámico | Establece el tamaño máximo en KB que pueden alcanzar los archivos temporales. |
| `temp_tablespaces` | Dinámico | Define los espacios de tabla que se deben usar para las tablas temporales y los archivos de ordenación. |
| `timezone` | Dinámico | Define la zona horaria para visualizar e interpretar las marcas temporales. Internet Assigned Numbers Authority (Autoridad de Números Asignados en Internet, IANA por sus siglas en inglés) publica nuevas zonas horarias en [https://www.iana.org/time-zones](https://www.iana.org/time-zones) varias veces al año. Cada vez que RDS publica una nueva versión secundaria de mantenimiento de PostgreSQL, incluye los datos de zona horaria más recientes en el momento de la publicación. Cuando utiliza las versiones más recientes de RDS para PostgreSQL, dispone de datos de zona horaria recientes de RDS. Para garantizar que la instancia de base de datos tenga datos de zona horaria recientes, se recomienda actualizar a una versión posterior del motor de base de datos. No puede modificar las tablas de zona horaria de las instancias de base de datos de PostgreSQL de forma manual. RDS no modifica ni restablece los datos de zona horaria de las instancias de base de datos en ejecución. Los nuevos datos de zona horaria solo se instalan cuando se actualiza la versión del motor de base de datos. |
| `track_activities` | Dinámico | Recopila información sobre la ejecución de comandos. |
| `track_activity_query_size` | Estático | Define el tamaño reservado para pg\$1stat\$1activity.current\$1query en bytes. |
| `track_counts` | Dinámico | Recopila estadísticas sobre la actividad de la base de datos. |
| `track_functions` | Dinámico | Recopila estadísticas de nivel de función sobre la actividad de la base de datos. |
| `track_io_timing` | Dinámico | Recopila estadísticas temporales sobre la actividad de E/S de la base de datos. |
| `transaction_deferrable` | Dinámico | Indica si se debe retrasar una transacción serializable de solo lectura hasta que se pueda comenzar sin posibles errores de serialización. |
| `transaction_isolation` | Dinámico | Define el nivel de aislamiento de las transacciones actuales. |
| `transaction_read_only` | Dinámico | Define el estado de solo lectura de las transacciones actuales. |
| `transform_null_equals` | Dinámico | Trata expr=NULL como expr IS NULL. |
| `update_process_title` | Dinámico | Actualiza el título del proceso para mostrar el comando SQL activo. |
| `vacuum_cost_delay` | Dinámico | Retardo del costo del vacío en milisegundos. |
| `vacuum_cost_limit` | Dinámico | Importe del costo del vacío disponible antes del periodo de reposo. |
| `vacuum_cost_page_dirty` | Dinámico | Costo del vacío para una página ensuciada por el vacío. |
| `vacuum_cost_page_hit` | Dinámico | Costo del vacío para una página encontrada en la caché del búfer. |
| `vacuum_cost_page_miss` | Dinámico | Costo del vacío para una página no encontrada en la caché del búfer. |
| `vacuum_defer_cleanup_age` | Dinámico | Número de transacciones para las que se deben retrasar el vacío y la limpieza en caliente, si los hay. |
| `vacuum_freeze_min_age` | Dinámico | Antigüedad mínima a la que el vacío debe inmovilizar una fila de una tabla. |
| `vacuum_freeze_table_age` | Dinámico | Antigüedad a la que el vacío debe examinar una tabla completa para inmovilizar tuplas. |
| `wal_buffers` | Estático | Define el número de búferes de página de disco de memoria compartida para WAL. |
| `wal_writer_delay` | Dinámico | Tiempo de reposo del escritor de WAL entre vaciados de WAL. |
| `work_mem` | Dinámico | Define la memoria máxima que se debe usar para los espacios de trabajo de consulta. |
| `xmlbinary` | Dinámico | Define cómo se deben codificar los valores binarios en XML. |
| `xmloption` | Dinámico | Define si los datos XML de las operaciones implícitas de análisis y serialización se deben considerar documentos o fragmentos de contenido. |
Amazon RDS usa las unidades predeterminadas de PostgreSQL para todos los parámetros. En la tabla siguiente se muestra la unidad predeterminada de PostgreSQL para cada parámetro.
| Nombre del parámetro | Unidad |
| --- | --- |
| `archive_timeout` | s |
| `authentication_timeout` | s |
| `autovacuum_naptime` | s |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | s |
| `checkpoint_warning` | s |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | minutos |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | s |
| `pre_auth_delay` | s |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | s |
| `tcp_keepalives_interval` | s |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | s |