# Referência de funções do Aurora PostgreSQL
Você pode encontrar uma lista de funções do Aurora PostgreSQL disponíveis para clusters de bancos de dados Aurora que executam o mecanismo de banco de dados Aurora PostgreSQL, edição compatível com PostgreSQL. Essas funções do Aurora PostgreSQL são adicionadas às funções do PostgreSQL padrão. Para obter mais informações sobre funções padrão do PostgreSQL, consulte [PostgreSQL – Funções e operadores](https://www.postgresql.org/docs/current/functions.html).
## Visão geral
Você pode usar as seguintes funções para instâncias de banco de dados do Amazon RDS que executam o Aurora PostgreSQL:
+ [aurora\$1db\$1instance\$1identifier](aurora_db_instance_identifier.md)
+ [aurora\$1ccm\$1status](aurora_ccm_status.md)
+ [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md)
+ [aurora\$1global\$1db\$1status](aurora_global_db_status.md)
+ [aurora\$1list\$1builtins](aurora_list_builtins.md)
+ [aurora\$1replica\$1status](aurora_replica_status.md)
+ [aurora\$1stat\$1activity](aurora_stat_activity.md)
+ [aurora\$1stat\$1backend\$1waits](aurora_stat_backend_waits.md)
+ [aurora\$1stat\$1bgwriter](aurora_stat_bgwriter.md)
+ [aurora\$1stat\$1database](aurora_stat_database.md)
+ [aurora\$1stat\$1dml\$1activity](aurora_stat_dml_activity.md)
+ [aurora\$1stat\$1get\$1db\$1commit\$1latency](aurora_stat_get_db_commit_latency.md)
+ [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)
+ [aurora\$1stat\$1memctx\$1usage](aurora_stat_memctx_usage.md)
+ [aurora\$1stat\$1optimized\$1reads\$1cache](aurora_stat_optimized_reads_cache.md)
+ [aurora\$1stat\$1plans](aurora_stat_plans.md)
+ [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md)
+ [aurora\$1stat\$1statements](aurora_stat_statements.md)
+ [aurora\$1stat\$1system\$1waits](aurora_stat_system_waits.md)
+ [aurora\$1stat\$1wait\$1event](aurora_stat_wait_event.md)
+ [aurora\$1stat\$1wait\$1type](aurora_stat_wait_type.md)
+ [aurora\$1version](aurora_version.md)
+ [aurora\$1volume\$1logical\$1start\$1lsn](aurora_volume_logical_start_lsn.md)
+ [aurora\$1wait\$1report](aurora_wait_report.md)
# aurora\$1db\$1instance\$1identifier
Informa o nome da instância de banco de dados à qual você está conectado.
## Sintaxe
```
aurora_db_instance_identifier()
```
## Argumentos
Nenhum
## Tipo de retorno
String VARCHAR
## Observações de uso
Essa função exibe o nome da instância de banco de dados do cluster da edição do Aurora compatível com PostgreSQL para a conexão do seu cliente ou aplicação de banco de dados.
Essa função está disponível a partir do lançamento do Aurora PostgreSQL versões 13.7, 12.11, 11.16 e 10.21, e para todas as outras versões posteriores.
## Exemplos
O exemplo a seguir mostra os resultados de uma chamada à função `aurora_db_instance_identifier`.
```
=> SELECT aurora_db_instance_identifier();
aurora_db_instance_identifier
-------------------------------
test-my-instance-name
```
Você pode unir os resultados dessa função com a função `aurora_replica_status` para obter detalhes sobre a instância de banco de dados para sua conexão. [aurora\$1replica\$1status](aurora_replica_status.md) sozinho não mostra qual instância de banco de dados você está usando. O exemplo a seguir mostra como.
```
=> SELECT *
FROM aurora_replica_status() rt,
aurora_db_instance_identifier() di
WHERE rt.server_id = di;
-[ RECORD 1 ]----------------------+-----------------------
server_id | test-my-instance-name
session_id | MASTER_SESSION_ID
durable_lsn | 88492069
highest_lsn_rcvd |
current_read_lsn |
cur_replay_latency_in_usec |
active_txns |
is_current | t
last_transport_error | 0
last_error_timestamp |
last_update_timestamp | 2022-06-03 11:18:25+00
feedback_xmin |
feedback_epoch |
replica_lag_in_msec |
log_stream_speed_in_kib_per_second | 0
log_buffer_sequence_number | 0
oldest_read_view_trx_id |
oldest_read_view_lsn |
pending_read_ios | 819
```
# aurora\$1ccm\$1status
Exibe o status do gerenciador de cache do cluster.
## Sintaxe
```
aurora_ccm_status()
```
## Argumentos
Nenhum.
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ `buffers_sent_last_minute`: quantos buffers foram enviados ao leitor designado no último minuto.
+ `buffers_found_last_minute`: o número de buffers acessados com frequência que foram identificados durante o último minuto.
+ `buffers_sent_last_scan`: quantos buffers foram enviados ao leitor designado durante a última verificação completa do cache em buffer.
+ `buffers_found_last_scan`: quantos buffers acessados com frequência foram enviados durante a última verificação completa do cache em buffer. Os buffers que já estão em cache no leitor designado não são enviados.
+ `buffers_sent_current_scan`: quantos buffers foram enviados durante a verificação atual.
+ `buffers_found_current_scan`: o número de buffers acessados com frequência identificados na verificação atual.
+ `current_scan_progress`: quantos buffers foram visitados durante a verificação atual até agora.
## Observações de uso
É possível usar essa função para verificar e monitorar o recurso de gerenciamento de cache de cluster (CCM). Essa função opera somente quando o CCM está ativo no cluster de banco de dados do Aurora PostgreSQL. Para usar essa função, conecte-se à instância de banco de dados de gravação no cluster de banco de dados do Aurora PostgreSQL.
Ative o CCM para um cluster de banco de dados do Aurora PostgreSQL definindo a opção `apg_ccm_enabled` como 1 no grupo de parâmetros de cluster de banco de dados personalizado. Para saber como, consulte [Configuração do gerenciamento de cache do cluster](AuroraPostgreSQL.cluster-cache-mgmt.md#AuroraPostgreSQL.cluster-cache-mgmt.Configure).
O gerenciamento de cache do cluster está ativo em um cluster de banco de dados do Aurora PostgreSQL quando o cluster tem uma instância do leitor do Aurora configurada da seguinte forma:
+ A instância do leitor do Aurora usa o mesmo tipo e tamanho de classe que a instância de banco de dados da instância do gravador do cluster.
+ A instância do leitor do Aurora está configurada como Nível 0 para o cluster. Se o cluster tiver mais de um leitor, esse será o único leitor Nível 0.
A definição de mais de um leitor como Nível 0 desativa o CCM. Quando o CCM está desativado, a chamada dessa função retornará a seguinte mensagem de erro:
```
ERROR: Cluster Cache Manager is disabled
```
Também é possível usar a extensão pg\$1buffercache do PostgreSQL para analisar o cache do buffer. Para obter mais informações, consulte [pg\$1buffercache](https://www.postgresql.org/docs/current/pgbuffercache.html) na documentação do PostgreSQL.
Para obter mais informações, consulte [Introdução ao gerenciamento de cache do cluster do Aurora PostgreSQL](https://aws.amazon.com/blogs/database/introduction-to-aurora-postgresql-cluster-cache-management/).
## Exemplos
O exemplo a seguir mostra os resultados de uma chamada à função `aurora_ccm_status`. Este primeiro exemplo mostra as estatísticas do CCM.
```
=> SELECT * FROM aurora_ccm_status();
buffers_sent_last_minute | buffers_found_last_minute | buffers_sent_last_scan | buffers_found_last_scan | buffers_sent_current_scan | buffers_found_current_scan | current_scan_progress
--------------------------+---------------------------+------------------------+-------------------------+---------------------------+----------------------------+-----------------------
2242000 | 2242003 | 17920442 | 17923410 | 14098000 | 14100964 | 15877443
```
Para obter detalhes mais completos, use a exibição expandida, conforme mostrado a seguir:
```
\x
Expanded display is on.
SELECT * FROM aurora_ccm_status();
[ RECORD 1 ]-----------------------+---------
buffers_sent_last_minute | 2242000
buffers_found_last_minute | 2242003
buffers_sent_last_scan | 17920442
buffers_found_last_scan | 17923410
buffers_sent_current_scan | 14098000
buffers_found_current_scan | 14100964
current_scan_progress | 15877443
```
Este exemplo mostra como verificar a taxa de aquecimento e a porcentagem de aquecimento.
```
=> SELECT buffers_sent_last_minute * 8/60 AS warm_rate_kbps,
100 * (1.0-buffers_sent_last_scan/buffers_found_last_scan) AS warm_percent
FROM aurora_ccm_status ();
warm_rate_kbps | warm_percent
----------------+--------------
16523 | 100.0
```
# aurora\$1global\$1db\$1instance\$1status
Exibe o status de todas as instâncias do Aurora, incluindo as réplicas em um cluster de banco de dados global do Aurora.
## Sintaxe
```
aurora_global_db_instance_status()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ `server_id`: o identificador da instância de banco de dados.
+ `session_id`: o identificador exclusivo da sessão. O valor de `MASTER_SESSION_ID` identifica a instância de banco de dados do leitor (primário).
+ `aws_region`: a Região da AWS em que essa instância de banco de dados global é executada. Para obter uma lista de regiões, consulte [Disponibilidade de regiões](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ `durable_lsn`: o número de sequência de log (LSN) que se tornou durável no armazenamento. Um número de sequência de log (LSN) é um número sequencial exclusivo que identifica um registo no log de transações do banco de dados. LSNs são ordenados de forma que um LSN maior represente uma transação posterior.
+ `highest_lsn_rcvd`: o LSN mais alto recebido pela instância de banco de dados do gravador.
+ `feedback_epoch`: a época que a instância de banco de dados usa ao gerar informações de standby a quente. *Standby a quente* é uma instância de banco de dados que oferece suporte às conexões e às consultas quando o banco de dados primário está no modo de recuperação ou de standby. As informações de standby a quente incluem a época (ponto no tempo) e outros detalhes sobre a instância de banco de dados que está sendo usada como standby a quente. Para obter mais informações, consulte [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html) na documentação do PostgreSQL.
+ `feedback_xmin`: o ID mínimo (mais antigo) da transação ativa usado pela instância de banco de dados.
+ `oldest_read_view_lsn`: o LSN mais antigo usado pela instância de banco de dados para fazer a leitura no armazenamento.
+ `visibility_lag_in_msec`: o tempo de atraso dessa instância de banco de dados em relação à instância de banco de dados do gravador, em milissegundos.
## Observações de uso
Essa função mostra estatísticas de replicação de um cluster de banco de dados do Aurora. Para cada instância de banco de dados do Aurora PostgreSQL no cluster, a função mostra uma linha de dados que inclui todas as réplicas entre regiões em uma configuração de banco de dados global.
É possível executar essa função em qualquer instância em um cluster de banco de dados do Aurora PostgreSQL ou em um banco de dados global do Aurora PostgreSQL. A função retorna detalhes sobre o atraso de todas as instâncias de réplica.
Para saber mais sobre o monitoramento de atraso usando essa função (`aurora_global_db_instance_status`) ou usando `aurora_global_db_status`, consulte [Monitorar banco de dados globais baseados no Aurora PostgreSQL](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres).
Para obter mais informações sobre bancos de dados globais do Aurora, consulte [Visão geral do Amazon Aurora Global Database](aurora-global-database.md#aurora-global-database-overview).
Para obter os conceitos básicos sobre bancos de dados globais do Aurora, consulte [Conceitos básicos do Amazon Aurora Global Database](aurora-global-database-getting-started.md) ou [Perguntas frequentes sobre o Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/).
## Exemplos
Este exemplo mostra as estatísticas de instâncias entre regiões.
```
=> SELECT *
FROM aurora_global_db_instance_status();
server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec
------------------------------------------+--------------------------------------+--------------+-------------+------------------+----------------+---------------+----------------------+------------------------
db-119-001-instance-01 | MASTER_SESSION_ID | eu-west-1 | 2534560273 | [NULL] | [NULL] | [NULL] | [NULL] | [NULL]
db-119-001-instance-02 | 4ecff34d-d57c-409c-ba28-278b31d6fc40 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560266 | 6
db-119-001-instance-03 | 3e8a20fc-be86-43d5-95e5-bdf19d27ad6b | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560266 | 6
db-119-001-instance-04 | fc1b0023-e8b4-4361-bede-2a7e926cead6 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560254 | 23
db-119-001-instance-05 | 30319b74-3f08-4e13-9728-e02aa1aa8649 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560254 | 23
db-119-001-global-instance-1 | a331ffbb-d982-49ba-8973-527c96329c60 | eu-central-1 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 996
db-119-001-global-instance-1 | e0955367-7082-43c4-b4db-70674064a9da | eu-west-2 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 14
db-119-001-global-instance-1-eu-west-2a | 1248dc12-d3a4-46f5-a9e2-85850491a897 | eu-west-2 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 0
```
Este exemplo mostra como verificar o atraso de uma réplica global em milissegundos.
```
=> SELECT CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'Primary'
ELSE 'Secondary'
END AS global_role,
aws_region,
server_id,
visibility_lag_in_msec
FROM aurora_global_db_instance_status()
ORDER BY 1, 2, 3;
global_role | aws_region | server_id | visibility_lag_in_msec
-------------+--------------+-----------------------------------------+------------------------
Primary | eu-west-1 | db-119-001-instance-01 | [NULL]
Secondary | eu-central-1 | db-119-001-global-instance-1 | 13
Secondary | eu-west-1 | db-119-001-instance-02 | 10
Secondary | eu-west-1 | db-119-001-instance-03 | 9
Secondary | eu-west-1 | db-119-001-instance-04 | 2
Secondary | eu-west-1 | db-119-001-instance-05 | 18
Secondary | eu-west-2 | db-119-001-global-instance-1 | 14
Secondary | eu-west-2 | db-119-001-global-instance-1-eu-west-2a | 13
```
Este exemplo mostra como verificar o atraso mínimo, máximo e médio por Região da AWS na configuração do banco de dados global.
```
=> SELECT 'Secondary' global_role,
aws_region,
min(visibility_lag_in_msec) min_lag_in_msec,
max(visibility_lag_in_msec) max_lag_in_msec,
round(avg(visibility_lag_in_msec),0) avg_lag_in_msec
FROM aurora_global_db_instance_status()
WHERE aws_region NOT IN (SELECT aws_region
FROM aurora_global_db_instance_status()
WHERE session_id='MASTER_SESSION_ID')
GROUP BY aws_region
UNION ALL
SELECT 'Primary' global_role,
aws_region,
NULL,
NULL,
NULL
FROM aurora_global_db_instance_status()
WHERE session_id='MASTER_SESSION_ID'
ORDER BY 1, 5;
global_role | aws_region | min_lag_in_msec | max_lag_in_msec | avg_lag_in_msec
------------+--------------+-----------------+-----------------+-----------------
Primary | eu-west-1 | [NULL] | [NULL] | [NULL]
Secondary | eu-central-1 | 133 | 133 | 133
Secondary | eu-west-2 | 0 | 495 | 248
```
# aurora\$1global\$1db\$1status
Exibe informações sobre diversos aspectos do atraso do banco de dados Aurora global, especificamente o atraso do armazenamento do Aurora subjacente (o chamado atraso de durabilidade) e o atraso entre o objetivo de ponto de recuperação (RPO).
## Sintaxe
```
aurora_global_db_status()
```
## Argumentos
Nenhum.
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ `aws_region`: a Região da AWS em que esse cluster de banco de dados está. Para obter uma lista completa de Regiões da AWS por mecanismo, consulte [Regiões e zonas de disponibilidade](Concepts.RegionsAndAvailabilityZones.md).
+ `highest_lsn_written`: o número de sequência de logs (LSN) mais alto nesse cluster de banco de dados no momento. Um número de sequência de log (LSN) é um número sequencial exclusivo que identifica um registo no log de transações do banco de dados. LSNs são ordenados de forma que um LSN maior represente uma transação posterior.
+ `durability_lag_in_msec`: a diferença nos valores de carimbo de data/hora entre `highest_lsn_written` em um cluster de banco de dados secundário e `highest_lsn_written` no cluster de banco de dados primário. Um valor de -1 identifica o cluster de banco de dados primário do banco de dados Aurora global.
+ `rpo_lag_in_msec`: o atraso do objetivo de ponto de recuperação (RPO). O atraso do RPO é o tempo necessário para que a transação COMMIT mais recente do usuário seja armazenada em um cluster de banco de dados secundário após ser armazenada no cluster de banco de dados primário de um banco de dados Aurora global. Um valor igual a -1 denota o cluster de banco de dados primário (e, portanto, o atraso não é relevante).
Em termos simples, essa métrica calcula o objetivo do ponto de recuperação de cada cluster de banco de dados do Aurora PostgreSQL no banco de dados Aurora global, ou seja, quantos dados poderão ser perdidos se houver uma interrupção. Tal como o atraso, o RPO é medido em tempo.
+ `last_lag_calculation_time`: o carimbo de data/hora que especifica quando os valores foram calculados pela última vez para `durability_lag_in_msec` e `rpo_lag_in_msec`. Um valor de tempo como `1970-01-01 00:00:00+00` indica que este é o cluster de banco de dados primário.
+ `feedback_epoch`: a época que o cluster de banco de dados secundário usa ao gerar informações de standby a quente. *Standby a quente* é uma instância de banco de dados que oferece suporte às conexões e às consultas quando o banco de dados primário está no modo de recuperação ou de standby. As informações de standby a quente incluem a época (ponto no tempo) e outros detalhes sobre a instância de banco de dados que está sendo usada como standby a quente. Para obter mais informações, consulte [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html) na documentação do PostgreSQL.
+ `feedback_xmin`: o ID mínimo (mais antigo) da transação ativa usado por um cluster de banco de dados secundário.
## Observações de uso
Todas as versões do Aurora PostgreSQL atualmente disponíveis são compatíveis com essa função. Esta função mostra estatísticas de replicação de um banco de dados do Aurora. A função mostra uma linha para cada cluster de banco de dados em um banco de dados global do Aurora PostgreSQL. É possível executar essa função em qualquer instância em um banco de dados global do Aurora PostgreSQL.
Para avaliar o atraso de replicação de banco de dados global do Aurora, que é o atraso de dados visível, consulte [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md).
Para saber mais sobre o uso de `aurora_global_db_status` e de `aurora_global_db_instance_status` para monitorar o atraso do banco de dados global do Aurora, consulte [Monitorar banco de dados globais baseados no Aurora PostgreSQL](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres). Para obter mais informações sobre bancos de dados globais do Aurora, consulte [Visão geral do Amazon Aurora Global Database](aurora-global-database.md#aurora-global-database-overview).
## Exemplos
Este exemplo mostra como exibir estatísticas de armazenamento entre regiões.
```
=> SELECT CASE
WHEN '-1' = durability_lag_in_msec THEN 'Primary'
ELSE 'Secondary'
END AS global_role,
*
FROM aurora_global_db_status();
global_role | aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin
-------------+------------+---------------------+------------------------+-----------------+----------------------------+----------------+---------------
Primary | eu-west-1 | 131031557 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0
Secondary | eu-west-2 | 131031554 | 410 | 0 | 2021-06-01 18:59:36.124+00 | 0 | 12640
Secondary | eu-west-3 | 131031554 | 410 | 0 | 2021-06-01 18:59:36.124+00 | 0 | 12640
```
# aurora\$1list\$1builtins
Lista todas as funções integradas do Aurora PostgreSQL disponíveis, juntamente com breves descrições e detalhes da função.
## Sintaxe
```
aurora_list_builtins()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF
## Exemplos
O exemplo a seguir mostra os resultados de uma chamada à função `aurora_list_builtins`.
```
=> SELECT *
FROM aurora_list_builtins();
Name | Result data type | Argument data types | Type | Volatility | Parallel | Security | Description
-----------------------------------+------------------+----------------------------------------------------------+------+------------+------------+----------+---------------------------------------------------------------------
aurora_version | text | | func | stable | safe | invoker | Amazon Aurora PostgreSQL-Compatible Edition version string
aurora_stat_wait_type | SETOF record | OUT type_id smallint, OUT type_name text | func | volatile | restricted | invoker | Lists all supported wait types
aurora_stat_wait_event | SETOF record | OUT type_id smallint, OUT event_id integer, OUT event_na.| func | volatile | restricted | invoker | Lists all supported wait events
| |.me text | | | | |
aurora_list_builtins | SETOF record | OUT "Name" text, OUT "Result data type" text, OUT "Argum.| func | stable | safe | invoker | Lists all Aurora built-in functions
| |.ent data types" text, OUT "Type" text, OUT "Volatility" .| | | | |
| |.text, OUT "Parallel" text, OUT "Security" text, OUT "Des.| | | | |
| |.cription" text | | | | |
.
.
.
aurora_stat_file | SETOF record | OUT filename text, OUT allocated_bytes bigint, OUT used_.| func | stable | safe | invoker | Lists all files present in Aurora storage
| |.bytes bigint | | | | |
aurora_stat_get_db_commit_latency | bigint | oid | func | stable | restricted | invoker | Per DB commit latency in microsecs
```
# aurora\$1replica\$1status
Exibe o status de todos os nós de leitor do Aurora PostgreSQL.
## Sintaxe
```
aurora_replica_status()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ `server_id`: o DB de instância de banco de dados (identificador).
+ `session_id`: um identificador exclusivo da sessão atual, retornado para instâncias primárias e do leitor da seguinte forma:
+ Para a instância principal, `session_id` é sempre ``MASTER_SESSION_ID’`.
+ Para instâncias de leitor, `session_id` é sempre o `UUID` (identificador universalmente exclusivo) da instância do leitor.
+ `durable_lsn`: o número de sequência de log (LSN) que foi salvo no armazenamento.
+ Para o volume principal, o LSN (VDL) durável do volume principal que está atualmente em vigor.
+ Para quaisquer volumes secundários, o VDL do principal até o secundário que foi aplicado com êxito.
**nota**
Um número de sequência de log (LSN) é um número sequencial exclusivo que identifica um registo no log de transações do banco de dados. Os LSNs são ordenados de forma que um LSN maior represente uma transação ocorrida posteriormente na sequência.
+ `highest_lsn_rcvd`: o LSN mais alto (mais recente) recebido pela instância de banco de dados da instância de banco de dados do gravador.
+ `current_read_lsn`: o LSN do snapshot mais recente que foi aplicado a todos os leitores.
+ `cur_replay_latency_in_usec`: o número de microssegundos que se espera para reproduzir o log no secundário.
+ `active_txns`: o número de transações atualmente ativas.
+ `is_current`: não usado.
+ `last_transport_error`: código do último erro de replicação.
+ `last_error_timestamp`: carimbo de data/hora do último erro de replicação.
+ `last_update_timestamp`: carimbo de data/hora da última atualização para o status da réplica. No Aurora PostgreSQL 13.9, o valor `last_update_timestamp` da instância de banco de dados com que você tem conexão é definido como `NULL`.
+ `feedback_xmin`: o feedback\$1xmin de standby a quente da réplica. O ID mínimo (mais antigo) de transação ativo usado pela instância de banco de dados.
+ `feedback_epoch`: a época que a instância de banco de dados usa quando gera informações de standby a quente.
+ `replica_lag_in_msec`: o tempo de atraso da instância do leitor em relação à instância do gravador, em milissegundos.
+ `log_stream_speed_in_kib_per_second`: a taxa de transferência do fluxo de logs em kilobytes por segundo.
+ `log_buffer_sequence_number`: o número da sequência do buffer de log.
+ `oldest_read_view_trx_id`: não usado.
+ `oldest_read_view_lsn`: o LSN mais antigo usado pela instância de banco de dados para fazer a leitura no armazenamento.
+ `pending_read_ios`: a página pendente indica que ainda há pendência na réplica.
+ `read_ios`: o número total de leituras de página na réplica.
+ `iops`: não usado.
+ `cpu`: uso da CPU do Aurora Storage Daemon para cada nó no cluster. Para obter mais informações sobre o uso da CPU pela instância, consulte [Métricas no nível da instância do Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
## Observações de uso
Todas as versões do Aurora PostgreSQL atualmente disponíveis são compatíveis com essa função. A função `aurora_replica_status` retorna valores do gerenciador de status de réplica de um cluster de banco de dados do Aurora PostgreSQL. Você pode usar essa função para obter informações sobre o status da replicação em seu cluster de banco de dados do Aurora PostgreSQL, como métricas para todas as instâncias de banco de dados no cluster de banco de dados do Aurora. Por exemplo, você pode fazer o seguinte:
+ **Obtenha informações sobre o tipo de instância (gravador, leitor) no cluster de banco de dados do Aurora PostgreSQL**: você pode obter essas informações conferindo os valores das seguintes colunas:
+ `server_id`: contém o nome da instância que você especificou quando criou a instância. Em alguns casos, como para a instância principal (gravador), o nome geralmente é criado para você anexando *-instância-1* ao nome criado para o cluster de banco de dados do Aurora PostgreSQL.
+ `session_id`: o campo `session_id` indica se a instância é um leitor ou um gravador. Para uma instância de gravador, `session_id` é sempre definido como `"MASTER_SESSION_ID"`. Para uma instância de leitor, `session_id` é definido como o `UUID` do leitor específico.
+ **Diagnosticar problemas comuns de replicação, como atraso de réplica**: o atraso da réplica é o tempo em milissegundos em que o cache de página de uma instância de leitor está atrasado em relação à instância de gravador. Esse atraso ocorre porque os clusters do Aurora usam replicação assíncrona, conforme descrito em [Replicação com o Amazon Aurora](Aurora.Replication.md). Ele é mostrado na coluna `replica_lag_in_msec`, nos resultados retornados por essa função. O atraso também pode ocorrer quando uma consulta é cancelada devido a conflitos com a recuperação em um servidor em espera. Você pode conferir `pg_stat_database_conflicts()` para verificar se esse conflito está causando o atraso da réplica (ou não). Para obter mais informações, consulte [Coletor de estatísticas](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW) na *documentação do PostgreSQL*. Para saber mais sobre alta disponibilidade e replicação, consulte [Perguntas frequentes sobre o Amazon Aurora](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication).
O Amazon CloudWatch armazena resultados `replica_lag_in_msec` ao longo do tempo, como a métrica do `AuroraReplicaLag`. Para obter mais informações sobre o uso de métricas do CloudWatch para o Aurora, consulte [Monitorar métricas do Amazon Aurora com o Amazon CloudWatch](monitoring-cloudwatch.md).
Para saber mais sobre a solução de problemas de réplicas de leitura e reinicializações do Aurora, consulte [Por que minha réplica de leitura do Amazon Aurora ficou atrasada e foi reiniciada?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/) no [AWS Support Center](https://console.aws.amazon.com/support/home#/).
## Exemplos
O exemplo a seguir mostra como obter o status de replicação de todas as instâncias em um cluster de banco de dados do Aurora PostgreSQL:
```
=> SELECT *
FROM aurora_replica_status();
```
O exemplo a seguir mostra a instância do gravador no cluster de banco de dados `docs-lab-apg-main` do Aurora PostgreSQL:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id = 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-01 | writer
```
O exemplo a seguir lista todas as instâncias de leitor em um cluster:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id <> 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-02 | reader
db-119-001-instance-03 | reader
db-119-001-instance-04 | reader
db-119-001-instance-05 | reader
(4 rows)
```
O exemplo a seguir lista todas as instâncias, o atraso de cada instância em relação ao gravador e o tempo desde a última atualização:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role,
replica_lag_in_msec AS replica_lag_ms,
round(extract (epoch FROM (SELECT age(clock_timestamp(), last_update_timestamp))) * 1000) AS last_update_age_ms
FROM aurora_replica_status()
ORDER BY replica_lag_in_msec NULLS FIRST;
server_id | instance_role | replica_lag_ms | last_update_age_ms
------------------------+---------------+----------------+--------------------
db-124-001-instance-03 | writer | [NULL] | 1756
db-124-001-instance-01 | reader | 13 | 1756
db-124-001-instance-02 | reader | 13 | 1756
(3 rows)
```
# aurora\$1stat\$1activity
Exibe uma linha por processo do servidor, mostrando informações relacionadas à atividade atual desse processo.
## Sintaxe
```
aurora_stat_activity();
```
## Argumentos
Nenhum
## Tipo de retorno
Exibe uma linha por processo do servidor. Além das colunas `pg_stat_activity`, o seguinte campo é adicionado:
+ planid: identificador do plano
## Observações de uso
Uma visualização complementar para `pg_stat_activity` exibindo as mesmas colunas com uma coluna `plan_id` adicional que mostra o plano de execução da consulta atual.
`aurora_compute_plan_id` deve estar habilitado para que a visualização exiba um plan\$1id.
Essa função está disponível para o Aurora PostgreSQL versões 14.10, 15.5 e todas as outras versões posteriores.
## Exemplos
O exemplo de consulta abaixo agrega a carga superior por query\$1id e plan\$1id.
```
db1=# select count(*), query_id, plan_id
db1-# from aurora_stat_activity() where state = 'active'
db1-# and pid <> pg_backend_pid()
db1-# group by query_id, plan_id
db1-# order by 1 desc;
count | query_id | plan_id
-------+----------------------+-------------
11 | -5471422286312252535 | -2054628807
3 | -6907107586630739258 | -815866029
1 | 5213711845501580017 | 300482084
(3 rows)
```
Se o plano usado para query\$1id mudar, um novo plan\$1id será relatado por aurora\$1stat\$1activity.
```
count | query_id | plan_id
-------+----------------------+-------------
10 | -5471422286312252535 | 1602979607
1 | -6907107586630739258 | -1809935983
1 | -2446282393000597155 | -207532066
(3 rows)
```
# aurora\$1stat\$1backend\$1waits
Exibe estatísticas da atividade de espera de um processo de backend específico.
## Sintaxe
```
aurora_stat_backend_waits(pid)
```
## Argumentos
`pid`: o ID do processo de backend. É possível obter os IDs de processos usando a visualização `pg_stat_activity`.
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ `type_id`: um número que denota o tipo de evento de espera, como `1` para um bloqueio leve (`LWLock`), `3` para um bloqueio ou `6` para uma sessão de cliente, para citar alguns exemplos. Esses valores se tornam significativos ao unir os resultados dessa função com colunas da função `aurora_stat_wait_type`, como mostrado em [Exemplos](#aurora_stat_backend_waits-examples).
+ `event_id`: um número de identificação para o evento de espera. Una esse valor com as colunas de `aurora_stat_wait_event` para obter nomes de eventos significativos.
+ `waits`: uma contagem do número de esperas acumuladas para o ID do processo especificado.
+ `wait_time`: tempo de espera em milissegundos.
## Observações de uso
É possível usar essa função para analisar eventos de espera específicos de backend (sessão) que ocorreram desde que uma conexão foi aberta. Para obter informações mais significativas sobre os nomes e os tipos de evento de espera, combine as funções `aurora_stat_wait_type` e `aurora_stat_wait_event`, usando JOIN como mostrado nos exemplos.
## Exemplos
Este exemplo mostra todas as esperas, os tipos e os nomes dos eventos de um processo de backend ID 3027.
```
=> SELECT type_name, event_name, waits, wait_time
FROM aurora_stat_backend_waits(3027)
NATURAL JOIN aurora_stat_wait_type()
NATURAL JOIN aurora_stat_wait_event();
type_name | event_name | waits | wait_time
-----------+------------------------+-------+------------
LWLock | ProcArrayLock | 3 | 27
LWLock | wal_insert | 423 | 16336
LWLock | buffer_content | 11840 | 1033634
LWLock | lock_manager | 23821 | 5664506
Lock | tuple | 10258 | 152280165
Lock | transactionid | 78340 | 1239808783
Client | ClientRead | 34072 | 17616684
IO | ControlFileSyncUpdate | 2 | 0
IO | ControlFileWriteUpdate | 4 | 32
IO | RelationMapRead | 2 | 795
IO | WALWrite | 36666 | 98623
IO | XactSync | 4867 | 7331963
```
Este exemplo mostra os tipos de espera atuais e cumulativos e de eventos de espera para todas as sessões ativas (`pg_stat_activity state <> 'idle'`), mas sem a sessão atual que está invocando a função (`pid <> pg_backend_pid()`).
```
=> SELECT a.pid,
a.usename,
a.app_name,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND state <> 'idle') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we;
pid | usename | app_name | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+----------+----------+-------------------+--------------------+---------------+-----------+------------------------+-------+-----------
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | wal_insert | 1937 | 29975
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | buffer_content | 22903 | 760498
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | lock_manager | 10012 | 223207
30099 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 20315 | 63081529
.
.
.
30099 | postgres | pgbench | Lock | transactionid | active | IO | WALWrite | 93293 | 237440
30099 | postgres | pgbench | Lock | transactionid | active | IO | XactSync | 13010 | 19525143
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | ProcArrayLock | 6 | 53
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | wal_insert | 1913 | 25450
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | buffer_content | 22874 | 778005
.
.
.
30109 | postgres | pgbench | IO | XactSync | active | LWLock | ProcArrayLock | 3 | 71
30109 | postgres | pgbench | IO | XactSync | active | LWLock | wal_insert | 1940 | 27741
30109 | postgres | pgbench | IO | XactSync | active | LWLock | buffer_content | 22962 | 776352
30109 | postgres | pgbench | IO | XactSync | active | LWLock | lock_manager | 9879 | 218826
30109 | postgres | pgbench | IO | XactSync | active | Lock | tuple | 20401 | 63581306
30109 | postgres | pgbench | IO | XactSync | active | Lock | transactionid | 50769 | 211645008
30109 | postgres | pgbench | IO | XactSync | active | Client | ClientRead | 89901 | 44192439
```
Este exemplo mostra os três tipos principais de espera cumulativa e os eventos de espera de todas as sessões ativas (`pg_stat_activity state <> 'idle'`), exceto a sessão atual (`pid <>pg_backend_pid()`).
```
=> SELECT top3.*
FROM (SELECT a.pid,
a.usename,
a.app_name,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time,
RANK() OVER (PARTITION BY pid ORDER BY a.wait_time DESC)
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND state <> 'idle') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we) top3
WHERE RANK <=3;
pid | usename | app_name | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time | rank
-------+----------+----------+-------------------+--------------------+---------------+-----------+-----------------+---------+------------+------
20567 | postgres | psql | CPU | CPU | active | LWLock | wal_insert | 25000 | 67512003 | 1
20567 | postgres | psql | CPU | CPU | active | IO | WALWrite | 3071758 | 1016961 | 2
20567 | postgres | psql | CPU | CPU | active | IO | BufFileWrite | 20750 | 184559 | 3
27743 | postgres | pgbench | Lock | transactionid | active | Lock | transactionid | 237350 | 1265580011 | 1
27743 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 93641 | 341472318 | 2
27743 | postgres | pgbench | Lock | transactionid | active | Client | ClientRead | 417556 | 204796837 | 3
.
.
.
27745 | postgres | pgbench | IO | XactSync | active | Lock | transactionid | 238068 | 1265816822 | 1
27745 | postgres | pgbench | IO | XactSync | active | Lock | tuple | 93210 | 338312247 | 2
27745 | postgres | pgbench | IO | XactSync | active | Client | ClientRead | 419157 | 207836533 | 3
27746 | postgres | pgbench | Lock | transactionid | active | Lock | transactionid | 237621 | 1264528811 | 1
27746 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 93563 | 339799310 | 2
27746 | postgres | pgbench | Lock | transactionid | active | Client | ClientRead | 417304 | 208372727 | 3
```
# aurora\$1stat\$1bgwriter
`aurora_stat_bgwriter` é uma exibição de estatísticas que mostra informações sobre gravações em cache do Optimized Reads.
## Sintaxe
```
aurora_stat_bgwriter()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com todas as colunas `pg_stat_bgwriter` e as seguintes colunas adicionais. Para obter mais informações sobre as colunas `pg_stat_bgwriter`, consulte [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-BGWRITER-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-BGWRITER-VIEW).
Você pode redefinir as estatísticas dessa função usando `pg_stat_reset_shared("bgwriter")`.
+ `orcache_blks_written`: número total de gravações em cache de blocos de dados do optimized reads.
+ `orcache_blk_write_time`: se `track_io_timing` estiver ativado, ele rastreará o tempo total gasto gravando blocos de arquivos de dados em cache do optimized reads, em milissegundos. Para obter mais informações, consulte [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
## Observações de uso
Essa função está disponível nas seguintes versões do Aurora PostgreSQL:
+ 15.4 e versões 15 posteriores
+ 14.9 e versões 14 posteriores
## Exemplos
```
=> select * from aurora_stat_bgwriter();
-[ RECORD 1 ]-----------------+-----------
orcache_blks_written | 246522
orcache_blk_write_time | 339276.404
```
# aurora\$1stat\$1database
Ele carrega todas as colunas de pg\$1stat\$1database e acrescenta novas colunas no final.
## Sintaxe
```
aurora_stat_database()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com todas as colunas `pg_stat_database` e as seguintes colunas adicionais. Para obter mais informações sobre as colunas `pg_stat_database`, consulte [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).
+ `storage_blks_read`: número total de blocos compartilhados lidos do armazenamento do aurora nesse banco de dados.
+ `orcache_blks_hit`: número total de acessos ao cache do optimized reads nesse banco de dados.
+ `local_blks_read`: número total de blocos locais lidos nesse banco de dados.
+ `storage_blk_read_time`: se `track_io_timing` estiver ativado, ele rastreará o tempo total gasto lendo blocos de arquivos de dados do armazenamento do aurora, em milissegundos; caso contrário, o valor será zero. Para obter mais informações, consulte [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time`: se `track_io_timing` estiver ativado, ele rastreará o tempo total gasto lendo blocos de arquivos de dados locais, em milissegundos; caso contrário, o valor será zero. Para obter mais informações, consulte [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time`: se `track_io_timing` estiver ativado, ele rastreará o tempo total gasto lendo blocos de arquivos de dados do cache do optimized reads, em milissegundos; caso contrário, o valor será zero. Para obter mais informações, consulte [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
**nota**
O valor de `blks_read` é a soma de `storage_blks_read`, `orcache_blks_hit` e `local_blks_read`.
O valor de `blk_read_time` é a soma de `storage_blk_read_time`, `orcache_blk_read_time` e `local_blk_read_time`.
## Observações de uso
Essa função está disponível nas seguintes versões do Aurora PostgreSQL:
+ 15.4 e versões 15 posteriores
+ 14.9 e versões 14 posteriores
## Exemplos
O exemplo a seguir mostra como ele carrega todas as colunas `pg_stat_database` e acrescenta seis novas colunas no final:
```
=> select * from aurora_stat_database() where datid=14717;
-[ RECORD 1 ]------------+------------------------------
datid | 14717
datname | postgres
numbackends | 1
xact_commit | 223
xact_rollback | 4
blks_read | 1059
blks_hit | 11456
tup_returned | 27746
tup_fetched | 5220
tup_inserted | 165
tup_updated | 42
tup_deleted | 91
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
checksum_failures |
checksum_last_failure |
blk_read_time | 3358.689
blk_write_time | 0
session_time | 1076007.997
active_time | 3684.371
idle_in_transaction_time | 0
sessions | 10
sessions_abandoned | 0
sessions_fatal | 0
sessions_killed | 0
stats_reset | 2023-01-12 20:15:17.370601+00
orcache_blks_hit | 425
orcache_blk_read_time | 89.934
storage_blks_read | 623
storage_blk_read_time | 3254.914
local_blks_read | 0
local_blk_read_time | 0
```
# aurora\$1stat\$1dml\$1activity
Relata a atividade cumulativa para cada tipo de operação de linguagem de manipulação de dados (DML) em um banco de dados em um cluster do Aurora PostgreSQL.
## Sintaxe
```
aurora_stat_dml_activity(database_oid)
```
## Argumentos
*database\$1oid*
O ID do objeto (OID) do banco de dados no cluster do Aurora PostgreSQL.
## Tipo de retorno
Registro SETOF
## Observações de uso
A função `aurora_stat_dml_activity` só está disponível com o Aurora PostgreSQL versão 3.1 compatível com o mecanismo do PostgreSQL 11.6 e posteriores.
Use essa função em clusters do Aurora PostgreSQL com um grande número de bancos de dados para identificar quais bancos de dados apresentam mais atividades de DML ou atividades de DML mais lentas ou ambas.
A função `aurora_stat_dml_activity` retorna o número de vezes que as operações foram executadas e a latência cumulativa em microssegundos para as operações SELECT, INSERT, UPDATE e DELETE. O relatório inclui apenas operações DML bem-sucedidas.
Você pode redefinir essa estatística usando a função de acesso de estatísticas do PostgreSQL `pg_stat_reset`. Você pode verificar a última vez que esta estatística foi redefinida usando a função `pg_stat_get_db_stat_reset_time`. Para obter mais informações sobre as funções de acesso a estatísticas do PostgreSQL, consulte [Coletor de estatísticas](https://www.postgresql.org/docs/9.1/monitoring-stats.html) na documentação do PostgreSQL.
## Exemplos
O exemplo a seguir mostra como relatar estatísticas de atividades de DML para o banco de dados conectado.
```
––Define the oid variable from connected database by using \gset
=> SELECT oid,
datname
FROM pg_database
WHERE datname=(select current_database()) \gset
=> SELECT *
FROM aurora_stat_dml_activity(:oid);
select_count | select_latency_microsecs | insert_count | insert_latency_microsecs | update_count | update_latency_microsecs | delete_count | delete_latency_microsecs
--------------+--------------------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------
178957 | 66684115 | 171065 | 28876649 | 519538 | 1454579206167 | 1 | 53027
–– Showing the same results with expanded display on
=> SELECT *
FROM aurora_stat_dml_activity(:oid);
-[ RECORD 1 ]------------+--------------
select_count | 178957
select_latency_microsecs | 66684115
insert_count | 171065
insert_latency_microsecs | 28876649
update_count | 519538
update_latency_microsecs | 1454579206167
delete_count | 1
delete_latency_microsecs | 53027
```
O exemplo a seguir mostra estatísticas de atividades de DML para todos os bancos de dados no cluster do Aurora PostgreSQL. Esse cluster tem dois bancos de dados,`postgres` e `mydb`. A lista separada por vírgulas corresponde aos campos `select_count`, `select_latency_microsecs`, `insert_count`, `insert_latency_microsecs`, `update_count`, `update_latency_microsecs`, `delete_count` e `delete_latency_microsecs`.
O Aurora PostgreSQL cria e usa um banco de dados do sistema chamado `rdsadmin` para oferecer suporte a operações administrativas, como backups, restaurações, verificações de integridade, replicação e assim por diante. Essas operações de DML não têm impacto no cluster do Aurora PostgreSQL.
```
=> SELECT oid,
datname,
aurora_stat_dml_activity(oid)
FROM pg_database;
oid | datname | aurora_stat_dml_activity
-------+----------------+-----------------------------------------------------------------
14006 | template0 | (,,,,,,,)
16384 | rdsadmin | (2346623,1211703821,4297518,817184554,0,0,0,0)
1 | template1 | (,,,,,,,)
14007 | postgres | (178961,66716329,171065,28876649,519538,1454579206167,1,53027)
16401 | mydb | (200246,64302436,200036,107101855,600000,83659417514,0,0)
```
O exemplo a seguir mostra estatísticas de atividade DML para todos os bancos de dados, organizadas em colunas para melhor legibilidade.
```
SELECT db.datname,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 1), '()') AS select_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 2), '()') AS select_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 3), '()') AS insert_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 4), '()') AS insert_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 5), '()') AS update_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 6), '()') AS update_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 7), '()') AS delete_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 8), '()') AS delete_latency_microsecs
FROM (SELECT datname,
aurora_stat_dml_activity(oid) AS asdmla
FROM pg_database
) AS db;
datname | select_count | select_latency_microsecs | insert_count | insert_latency_microsecs | update_count | update_latency_microsecs | delete_count | delete_latency_microsecs
----------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------
template0 | | | | | | | |
rdsadmin | 4206523 | 2478812333 | 7009414 | 1338482258 | 0 | 0 | 0 | 0
template1 | | | | | | | |
fault_test | 66 | 452099 | 0 | 0 | 0 | 0 | 0 | 0
db_access_test | 1 | 5982 | 0 | 0 | 0 | 0 | 0 | 0
postgres | 42035 | 95179203 | 5752 | 2678832898 | 21157 | 441883182488 | 2 | 1520
mydb | 71 | 453514 | 0 | 0 | 1 | 190 | 1 | 152
```
O exemplo a seguir mostra a latência cumulativa média (latência cumulativa dividida por contagem) para cada operação de DML para o banco de dados com o OID `16401`.
```
=> SELECT select_count,
select_latency_microsecs,
select_latency_microsecs/NULLIF(select_count,0) select_latency_per_exec,
insert_count,
insert_latency_microsecs,
insert_latency_microsecs/NULLIF(insert_count,0) insert_latency_per_exec,
update_count,
update_latency_microsecs,
update_latency_microsecs/NULLIF(update_count,0) update_latency_per_exec,
delete_count,
delete_latency_microsecs,
delete_latency_microsecs/NULLIF(delete_count,0) delete_latency_per_exec
FROM aurora_stat_dml_activity(16401);
-[ RECORD 1 ]------------+-------------
select_count | 451312
select_latency_microsecs | 80205857
select_latency_per_exec | 177
insert_count | 451001
insert_latency_microsecs | 123667646
insert_latency_per_exec | 274
update_count | 1353067
update_latency_microsecs | 200900695615
update_latency_per_exec | 148478
delete_count | 12
delete_latency_microsecs | 448
delete_latency_per_exec | 37
```
# aurora\$1stat\$1get\$1db\$1commit\$1latency
Obtém a latência de confirmação cumulativa em microssegundos para bancos de dados do Aurora PostgreSQL. A *confirmação da latência* é medida como o tempo entre quando um cliente envia uma solicitação de confirmação e quando ele recebe a resposta afirmativa da confirmação.
## Sintaxe
```
aurora_stat_get_db_commit_latency(database_oid)
```
## Argumentos
*database\$1oid*
O ID do objeto (OID) do banco de dados Aurora PostgreSQL.
## Tipo de retorno
Registro SETOF
## Observações de uso
O Amazon CloudWatch usa essa função para calcular a latência média de confirmação. Para obter mais informações sobre as métricas do Amazon CloudWatch e como solucionar problemas de alta latência de confirmação, consulte [Visualizar métricas no console do Amazon RDS](USER_Monitoring.md) e [Como tomar melhores decisões sobre o Amazon RDS com métricas do Amazon CloudWatch](https://aws.amazon.com/blogs/database/making-better-decisions-about-amazon-rds-with-amazon-cloudwatch-metrics/).
Você pode redefinir essa estatística usando a função de acesso de estatísticas do PostgreSQL `pg_stat_reset`. Você pode verificar a última vez que esta estatística foi redefinida usando a função `pg_stat_get_db_stat_reset_time`. Para obter mais informações sobre as funções de acesso a estatísticas do PostgreSQL, consulte [Coletor de estatísticas](https://www.postgresql.org/docs/9.1/monitoring-stats.html) na documentação do PostgreSQL.
## Exemplos
O exemplo a seguir obtém a latência de confirmação cumulativa para cada banco de dados no cluster `pg_database`.
```
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database;
oid | datname | aurora_stat_get_db_commit_latency
-------+----------------+-----------------------------------
14006 | template0 | 0
16384 | rdsadmin | 654387789
1 | template1 | 0
16401 | mydb | 229556
69768 | postgres | 22011
```
O exemplo a seguir obtém a latência de confirmação cumulativa para o banco de dados conectado no momento. Antes de chamar a função `aurora_stat_get_db_commit_latency`, o exemplo primeiro usa `\gset` para definir uma variável para o argumento `oid` e define seu valor do banco de dados conectado.
```
––Get the oid value from the connected database before calling aurora_stat_get_db_commit_latency
=> SELECT oid
FROM pg_database
WHERE datname=(SELECT current_database()) \gset
=> SELECT *
FROM aurora_stat_get_db_commit_latency(:oid);
aurora_stat_get_db_commit_latency
-----------------------------------
1424279160
```
O exemplo a seguir obtém a latência de confirmação cumulativa para o banco de dados `mydb` no cluster `pg_database`. Em seguida, ele redefine essa estatística usando a função `pg_stat_reset` e mostra os resultados. Finalmente, ele usa a função `pg_stat_get_db_stat_reset_time` para verificar a última vez que essa estatística foi redefinida.
```
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database
WHERE datname = 'mydb';
oid | datname | aurora_stat_get_db_commit_latency
-------+-----------+-----------------------------------
16427 | mydb | 3320370
=> SELECT pg_stat_reset();
pg_stat_reset
---------------
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database
WHERE datname = 'mydb';
oid | datname | aurora_stat_get_db_commit_latency
-------+-----------+-----------------------------------
16427 | mydb | 6
=> SELECT *
FROM pg_stat_get_db_stat_reset_time(16427);
pg_stat_get_db_stat_reset_time
--------------------------------
2021-04-29 21:36:15.707399+00
```
# aurora\$1stat\$1logical\$1wal\$1cache
Mostra o uso do log de gravação antecipada (WAL) por slot.
## Sintaxe
```
SELECT * FROM aurora_stat_logical_wal_cache()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ `name`: o nome do slot de replicação.
+ `active_pid`: ID do processo walsender.
+ `cache_hit`: o número total de acessos ao cache wal desde a última redefinição.
+ `cache_miss`: o número total de perdas do cache wal desde a última redefinição.
+ `blks_read`: o número total de solicitações de leitura do cache wal.
+ `hit_rate`: a taxa de acertos do cache WAL (cache\$1hit/blks\$1read).
+ `last_reset_timestamp`: última vez que o contador foi redefinido.
## Observações de uso
Essa função está disponível para as versões a seguir do Aurora PostgreSQL.
+ 15.2 e todas as versões posteriores.
+ 14.7 e versões posteriores.
+ 13.08 e versões posteriores
+ 12.12 e versões posteriores
+ 11.17 e versões posteriores
## Exemplos
O exemplo a seguir mostra dois slots de replicação com somente uma função `aurora_stat_logical_wal_cache` ativa.
```
=> SELECT *
FROM aurora_stat_logical_wal_cache();
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
------------+------------+-----------+------------+-----------+----------+-------------------------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39:56.830635+00
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34:04.036795+00
(2 rows)
```
# aurora\$1stat\$1memctx\$1usage
Relata o uso do contexto de memória para cada processo do PostgreSQL.
## Sintaxe
```
aurora_stat_memctx_usage()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ `pid`: o ID do processo.
+ `name`: o nome do contexto da memória.
+ `allocated`: o número de bytes obtidos do subsistema de memória subjacente pelo contexto da memória.
+ `used`: o número de bytes confirmados nos clientes do contexto de memória.
+ `instances`: a contagem de contextos existentes desse tipo no momento.
## Observações de uso
Essa função exibe o uso do contexto de memória para cada processo do PostgreSQL. Alguns processos são identificados como `anonymous`. Os processos não são expostos porque contêm palavras-chave restritas.
Essa função está disponível para as seguintes versões do Aurora PostgreSQL:
+ 15.3 e versões 15 posteriores
+ 14.8 e versões 14 posteriores
+ 13.11 e versões 13 posteriores
+ 12.15 e versões 12 posteriores
+ 11.20 e versões 11 posteriores
## Exemplos
O exemplo a seguir mostra os resultados de uma chamada à função `aurora_stat_memctx_usage`.
```
=> SELECT *
FROM aurora_stat_memctx_usage();
pid| name | allocated | used | instances
-------+---------------------------------+-----------+---------+-----------
123864 | Miscellaneous | 19520 | 15064 | 3
123864 | Aurora File Context | 8192 | 616 | 1
123864 | Aurora WAL Context | 8192 | 296 | 1
123864 | CacheMemoryContext | 524288 | 422600 | 1
123864 | Catalog tuple context | 16384 | 13736 | 1
123864 | ExecutorState | 32832 | 28304 | 1
123864 | ExprContext | 8192 | 1720 | 1
123864 | GWAL record construction | 1024 | 832 | 1
123864 | MdSmgr | 8192 | 296 | 1
123864 | MessageContext | 532480 | 353832 | 1
123864 | PortalHeapMemory | 1024 | 488 | 1
123864 | PortalMemory | 8192 | 576 | 1
123864 | printtup | 8192 | 296 | 1
123864 | RelCache hash table entries | 8192 | 8152 | 1
123864 | RowDescriptionContext | 8192 | 1344 | 1
123864 | smgr relation context | 8192 | 296 | 1
123864 | Table function arguments | 8192 | 352 | 1
123864 | TopTransactionContext | 8192 | 632 | 1
123864 | TransactionAbortContext | 32768 | 296 | 1
123864 | WAL record construction | 50216 | 43904 | 1
123864 | hash table | 65536 | 52744 | 6
123864 | Relation metadata | 191488 | 124240 | 87
104992 | Miscellaneous | 9280 | 7728 | 3
104992 | Aurora File Context | 8192 | 376 | 1
104992 | Aurora WAL Context | 8192 | 296 | 1
104992 ||Autovacuum Launcher | 8192 | 296 | 1
104992 | Autovacuum database list | 16384 | 744 | 2
104992 | CacheMemoryContext | 262144 | 140288 | 1
104992 | Catalog tuple context | 8192 | 296 | 1
104992 | GWAL record construction | 1024 | 832 | 1
104992 | MdSmgr | 8192 | 296 | 1
104992 | PortalMemory | 8192 | 296 | 1
104992 | RelCache hash table entries | 8192 | 296 | 1
104992 | smgr relation context | 8192 | 296 | 1
104992 | Autovacuum start worker (tmp) | 8192 | 296 | 1
104992 | TopTransactionContext | 16384 | 592 | 2
104992 | TransactionAbortContext | 32768 | 296 | 1
104992 | WAL record construction | 50216 | 43904 | 1
104992 | hash table | 49152 | 34024 | 4
(39 rows)
```
Algumas palavras-chave restritas serão ocultadas, e a saída terá a seguinte aparência:
```
postgres=>SELECT *
FROM aurora_stat_memctx_usage();
pid| name | allocated | used | instances
-------+---------------------------------+-----------+---------+-----------
5482 | anonymous | 8192 | 456 | 1
5482 | anonymous | 8192 | 296 | 1
```
# aurora\$1stat\$1optimized\$1reads\$1cache
Essa função mostra estatísticas de cache em camadas.
## Sintaxe
```
aurora_stat_optimized_reads_cache()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ `total_size`: tamanho total do cache do optimized reads.
+ `used_size`: tamanho de página usado em cache do optimized reads.
## Observações de uso
Essa função está disponível nas seguintes versões do Aurora PostgreSQL:
+ 15.4 e versões 15 posteriores
+ 14.9 e versões 14 posteriores
## Exemplos
Veja a seguir um exemplo de saída em uma instância r6gd.8xlarge:
```
=> select pg_size_pretty(total_size) as total_size, pg_size_pretty(used_size)
as used_size from aurora_stat_optimized_reads_cache();
total_size | used_size
-----------+-----------
1054 GB | 975 GB
```
# aurora\$1stat\$1plans
Exibe uma linha para cada plano de execução monitorado.
## Sintaxe
```
aurora_stat_plans(
showtext
)
```
## Argumentos
+ showtext: mostra a consulta e o texto do plano. Os valores válidos são NULL, true ou false. True mostrará a consulta e o texto do plano.
## Tipo de retorno
Exibe uma linha para cada plano monitorado que contém todas as colunas de `aurora_stat_statements` e as colunas adicionais a seguir.
+ planid: identificador do plano.
+ explain\$1plan: explica o texto do plano.
+ plan\$1type:
+ `no plan`: nenhum plano foi capturado.
+ `estimate`: plano capturado com custos estimados.
+ `actual`: plano capturado com EXPLAIN ANALYZE.
+ plan\$1captured\$1time: última vez que um plano foi capturado.
## Observações de uso
`aurora_compute_plan_id` deve estar habilitado e `pg_stat_statements` deve estar em `shared_preload_libraries` para que os planos sejam monitorados.
O número de planos disponíveis é controlado pelo valor definido no parâmetro `pg_stat_statements.max`. Quando `aurora_compute_plan_id` está habilitado, é possível monitorar os planos até esse valor especificado em `aurora_stat_plans`.
Essa função está disponível para o Aurora PostgreSQL versões 14.10, 15.5 e todas as outras versões posteriores.
## Exemplos
No exemplo abaixo, os dois planos que são para o identificador de consulta -5471422286312252535 são capturados e as estatísticas das declarações são monitoradas pelo planid.
```
db1=# select calls, total_exec_time, planid, plan_captured_time, explain_plan
db1-# from aurora_stat_plans(true)
db1-# where queryid = '-5471422286312252535'
calls | total_exec_time | planid | plan_captured_time | explain_plan
---------+--------------------+-------------+-------------------------------+------------------------------------------------------------------
1532632 | 3209846.097107853 | 1602979607 | 2023-10-31 03:27:16.925497+00 | Update on pgbench_branches +
| | | | -> Bitmap Heap Scan on pgbench_branches +
| | | | Recheck Cond: (bid = 76) +
| | | | -> Bitmap Index Scan on pgbench_branches_pkey +
| | | | Index Cond: (bid = 76)
61365 | 124078.18012200127 | -2054628807 | 2023-10-31 03:20:09.85429+00 | Update on pgbench_branches +
| | | | -> Index Scan using pgbench_branches_pkey on pgbench_branches+
| | | | Index Cond: (bid = 17)
```
# aurora\$1stat\$1reset\$1wal\$1cache
Redefine o contador para o cache lógico wal.
## Sintaxe
Para redefinir um slot específico
```
SELECT * FROM aurora_stat_reset_wal_cache('slot_name')
```
Para redefinir todos os slots
```
SELECT * FROM aurora_stat_reset_wal_cache(NULL)
```
## Argumentos
`NULL` ou `slot_name`
## Tipo de retorno
Mensagem de status, string de texto
+ Redefina o contador lógico do cache wal: mensagem de êxito. Esse texto é retornado quando a função é bem-sucedida.
+ Slot de replicação não encontrado. Tente novamente. – Mensagem de falha. Esse texto é retornado quando a função não é bem-sucedida.
## Observações de uso
Essa função está disponível para as versões a seguir.
+ Aurora PostgreSQL 14.5 e posteriores
+ Aurora PostgreSQL versão 13.8 e posteriores
+ Aurora PostgreSQL versão 12.12 e posteriores
+ Aurora PostgreSQL versão 11.17 e posteriores
## Exemplos
O exemplo a seguir usa a função `aurora_stat_reset_wal_cache` para redefinir um slot denominado `test_results` e, depois, tenta redefinir um slot que não existe.
```
=> SELECT *
FROM aurora_stat_reset_wal_cache('test_slot');
aurora_stat_reset_wal_cache
--------------------------------------
Reset the logical wal cache counter.
(1 row)
=> SELECT *
FROM aurora_stat_reset_wal_cache('slot-not-exist');
aurora_stat_reset_wal_cache
-----------------------------------------------
Replication slot not found. Please try again.
(1 row)
```
# aurora\$1stat\$1resource\$1usage
Relata a utilização de recursos em tempo real, que consiste em métricas de recursos de backend e no uso da CPU para todos os processos de backend do Aurora PostgreSQL.
## Sintaxe
```
aurora_stat_resource_usage()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com colunas:
+ pid: identificador de processo.
+ allocated\$1memory: memória total alocada por processo em bytes.
+ used\$1memory: memória realmente usada por processo em bytes.
+ cpu\$1usage\$1percent: porcentagem de uso de CPU do processo.
## Observações de uso
Essa função exibe o uso de recursos de backend para cada processo de backend do Aurora PostgreSQL.
Essa função está disponível para as seguintes versões do Aurora PostgreSQL:
+ Aurora PostgreSQL 17.5 e versões 17 posteriores
+ Aurora PostgreSQL 16.9 e versões 16 posteriores
+ Aurora PostgreSQL 15.13 e versões 15 posteriores
+ Aurora PostgreSQL 14.18 e versões 14 posteriores
+ Aurora PostgreSQL 13.21 e versões 13 posteriores
## Exemplos
O exemplo a seguir mostra a saída da função `aurora_stat_resource_usage`.
```
=> select * from aurora_stat_resource_usage();
pid | allocated_memory | used_memory | cpu_usage_percent
------+------------------+-------------+-----------------------
666 | 1074032 | 333544 | 0.00729274882897963
667 | 787312 | 287360 | 0.0029263928146372746
668 | 3076776 | 1563488 | 0.006013116835953961
684 | 803744 | 307480 | 0.002226855426881142
2401 | 1232992 | 943144 | 0
647 | 8000 | 944 | 0.48853387812429855
659 | 319344 | 243000 | 0.0004135602076683591
663 | 262000 | 185736 | 0.008181301476644002
664 | 9024 | 1216 | 0.10992313082653653
(9 rows)
```
# aurora\$1stat\$1statements
Exibe todas as colunas `pg_stat_statements` e adiciona mais colunas no final.
## Sintaxe
```
aurora_stat_statements(showtext boolean)
```
## Argumentos
*showtext booliano*
## Tipo de retorno
Registro SETOF com todas as colunas `pg_stat_statements` e as seguintes colunas adicionais. Para obter mais informações sobre as colunas `pg_stat_statements`, consulte [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html).
Você pode redefinir as estatísticas dessa função usando `pg_stat_statements_reset()`.
+ `storage_blks_read`: número total de blocos compartilhados lidos do armazenamento do aurora de acordo com essa instrução.
+ `orcache_blks_hit`: número total de acessos ao cache do optimized reads nessa instrução.
+ `storage_blk_read_time`: se `track_io_timing` estiver habilitado, ele vai monitorar o tempo total gasto nessa declaração com a leitura de blocos compartilhados do armazenamento do Aurora, em milissegundos; caso contrário, o valor será zero. Para obter mais informações, consulte [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time`: se `track_io_timing` estiver habilitado, ele vai monitorar o tempo total gasto nessa declaração com a leitura de blocos locais, em milissegundos; caso contrário, o valor será zero. Para obter mais informações, consulte [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time`: se `track_io_timing` estiver habilitado, ele vai monitorar o tempo total gasto nessa declaração com a leitura de blocos compartilhados do cache de leituras otimizadas, em milissegundos; caso contrário, o valor será zero. Para obter mais informações, consulte [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `total_plan_peakmem`: soma total dos valores de pico de memória durante a fase de planejamento para todas as chamadas para essa declaração. Para ver o pico médio de memória durante o planejamento da declaração, divida esse valor pelo número de chamadas.
+ `min_plan_peakmem`: o menor valor de pico de memória observado durante o planejamento em todas as chamadas para essa declaração.
+ `max_plan_peakmem`: o maior valor de pico de memória durante o planejamento observado em todas as chamadas para essa declaração.
+ `total_exec_peakmem`: soma total dos valores de pico de memória durante a fase de execução para todas as chamadas para essa declaração. Para ver o pico médio de memória durante a execução da declaração, divida esse valor pelo número de chamadas.
+ `min_exec_peakmem`: o menor valor de pico de memória, em bytes, observado durante a execução em todas as chamadas para essa declaração.
+ `max_exec_peakmem`: o maior valor de pico de memória, em bytes, observado durante a execução em todas as chamadas para essa declaração.
**nota**
`total_plan_peakmen`, `min_plan_peakmem` e `max_plan_peakmem` são monitorados apenas quando a configuração `pg_stat_statements.track_planning` está ativada.
## Observações de uso
Para usar a função aurora\$1stat\$1statements(), é necessário incluir a extensão `pg_stat_statements` no parâmetro `shared_preload_libraries`.
Essa função está disponível nas seguintes versões do Aurora PostgreSQL:
+ 15.4 e versões 15 posteriores
+ 14.9 e versões 14 posteriores
As colunas que mostram o pico de memória estão disponíveis nas seguintes versões:
+ 16.3 e versões posteriores
+ 15.7 e versões posteriores
+ 14.12 e versões posteriores
## Exemplos
O exemplo a seguir mostra como ele carrega todas as colunas pg\$1stat\$1statements e inclui 11 novas colunas no final:
```
=> select * from aurora_stat_statements(true) where query like 'with window_max%';
-[ RECORD 1 ]----------+------------------------------------------------------------------------------------------------
userid | 16409
dbid | 5
toplevel | t
queryid | -8347523682669847482
query | with window_max as (select custid, max(scratch) over (order by scratch rows between $1 preceding
and $2 following) wmax from ts) select sum(wmax), max(custid) from window_max
plans | 0
total_plan_time | 0
min_plan_time | 0
max_plan_time | 0
mean_plan_time | 0
stddev_plan_time | 0
calls | 4
total_exec_time | 254.105121
min_exec_time | 57.503164000000005
max_exec_time | 68.687418
mean_exec_time | 63.52628025
stddev_exec_time | 5.150765359979643
rows | 4
shared_blks_hit | 200192
shared_blks_read | 0
shared_blks_dirtied | 0
shared_blks_written | 0
local_blks_hit | 0
local_blks_read | 0
local_blks_dirtied | 0
local_blks_written | 0
temp_blks_read | 0
temp_blks_written | 0
blk_read_time | 0
blk_write_time | 0
temp_blk_read_time | 0
temp_blk_write_time | 0
wal_records | 0
wal_fpi | 0
wal_bytes | 0
jit_functions | 0
jit_generation_time | 0
jit_inlining_count | 0
jit_inlining_time | 0
jit_optimization_count | 0
jit_optimization_time | 0
jit_emission_count | 0
jit_emission_time | 0
storage_blks_read | 0
orcache_blks_hit | 0
storage_blk_read_time | 0
local_blk_read_time | 0
orcache_blk_read_time | 0
total_plan_peakmem | 0
min_plan_peakmem | 0
max_plan_peakmem | 0
total_exec_peakmem | 6356224
min_exec_peakmem | 1589056
max_exec_peakmem | 1589056
```
# aurora\$1stat\$1system\$1waits
Relata informações de eventos de espera para a instância de banco de dados Aurora PostgreSQL.
## Sintaxe
```
aurora_stat_system_waits()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF
## Observações de uso
Essa função retorna o número cumulativo de esperas e o tempo de espera cumulativo para cada evento de espera gerado pela instância de banco de dados à qual você está conectado no momento.
O conjunto de registros retornado inclui os seguintes campos:
+ `type_id`: o ID do tipo do evento de espera.
+ `event_id`: o ID do evento de espera.
+ `waits`: o número de vezes que o evento de espera ocorreu.
+ `wait_time`: a quantidade total de tempo em microssegundos gasto aguardando esse evento.
As estatísticas retornadas por essa função são redefinidas quando uma instância de banco de dados é reiniciada.
## Exemplos
O exemplo a seguir mostra os resultados de uma chamada à função `aurora_stat_system_waits`.
```
=> SELECT *
FROM aurora_stat_system_waits();
type_id | event_id | waits | wait_time
---------+-----------+-----------+--------------
1 | 16777219 | 11 | 12864
1 | 16777220 | 501 | 174473
1 | 16777270 | 53171 | 23641847
1 | 16777271 | 23 | 319668
1 | 16777274 | 60 | 12759
.
.
.
10 | 167772231 | 204596 | 790945212
10 | 167772232 | 2 | 47729
10 | 167772234 | 1 | 888
10 | 167772235 | 2 | 64
```
O exemplo a seguir mostra como é possível usar essa função junto com `aurora_stat_wait_event` e `aurora_stat_wait_type` para produzir resultados mais legíveis.
```
=> SELECT type_name,
event_name,
waits,
wait_time
FROM aurora_stat_system_waits()
NATURAL JOIN aurora_stat_wait_event()
NATURAL JOIN aurora_stat_wait_type();
type_name | event_name | waits | wait_time
-----------+------------------------+----------+--------------
LWLock | XidGenLock | 11 | 12864
LWLock | ProcArrayLock | 501 | 174473
LWLock | buffer_content | 53171 | 23641847
LWLock | rdsutils | 2 | 12764
Lock | tuple | 75686 | 2033956052
Lock | transactionid | 1765147 | 47267583409
Activity | AutoVacuumMain | 136868 | 56305604538
Activity | BgWriterHibernate | 7486 | 55266949471
Activity | BgWriterMain | 7487 | 1508909964
.
.
.
IO | SLRURead | 3 | 11756
IO | WALWrite | 52544463 | 388850428
IO | XactSync | 187073 | 597041642
IO | ClogRead | 2 | 47729
IO | OutboundCtrlRead | 1 | 888
IO | OutboundCtrlWrite | 2 | 64
```
# aurora\$1stat\$1wait\$1event
Lista todos os eventos de espera compatíveis para o Aurora PostgreSQL. Para obter informações sobre eventos de espera do Aurora PostgreSQL, consulte [Eventos de espera do Amazon Aurora PostgreSQL](AuroraPostgreSQL.Reference.Waitevents.md).
## Sintaxe
```
aurora_stat_wait_event()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ type\$1id: o ID do tipo do evento de espera.
+ event\$1id: o ID do evento de espera.
+ type\$1name: nome do tipo de espera
+ event\$1name: nome do evento de espera
## Observações de uso
Para ver nomes de eventos com tipos de eventos em vez de IDs, use essa função junto com outras funções, como `aurora_stat_wait_type` e `aurora_stat_system_waits`. Os nomes de eventos de espera retornados por esta função são os mesmos que os retornados pela função `aurora_wait_report`.
## Exemplos
O exemplo a seguir mostra os resultados de uma chamada à função `aurora_stat_wait_event`.
```
=> SELECT *
FROM aurora_stat_wait_event();
type_id | event_id | event_name
---------+-----------+-------------------------------------------
1 | 16777216 |
1 | 16777217 | ShmemIndexLock
1 | 16777218 | OidGenLock
1 | 16777219 | XidGenLock
.
.
.
9 | 150994945 | PgSleep
9 | 150994946 | RecoveryApplyDelay
10 | 167772160 | BufFileRead
10 | 167772161 | BufFileWrite
10 | 167772162 | ControlFileRead
.
.
.
10 | 167772226 | WALInitWrite
10 | 167772227 | WALRead
10 | 167772228 | WALSync
10 | 167772229 | WALSyncMethodAssign
10 | 167772230 | WALWrite
10 | 167772231 | XactSync
.
.
.
11 | 184549377 | LsnAllocate
```
O exemplo a seguir junta `aurora_stat_wait_type` e `aurora_stat_wait_event` para retornar nomes de tipos e nomes de eventos para melhorar a legibilidade.
```
=> SELECT *
FROM aurora_stat_wait_type() t
JOIN aurora_stat_wait_event() e
ON t.type_id = e.type_id;
type_id | type_name | type_id | event_id | event_name
---------+-----------+---------+-----------+-------------------------------------------
1 | LWLock | 1 | 16777216 |
1 | LWLock | 1 | 16777217 | ShmemIndexLock
1 | LWLock | 1 | 16777218 | OidGenLock
1 | LWLock | 1 | 16777219 | XidGenLock
1 | LWLock | 1 | 16777220 | ProcArrayLock
.
.
.
3 | Lock | 3 | 50331648 | relation
3 | Lock | 3 | 50331649 | extend
3 | Lock | 3 | 50331650 | page
3 | Lock | 3 | 50331651 | tuple
.
.
.
10 | IO | 10 | 167772214 | TimelineHistorySync
10 | IO | 10 | 167772215 | TimelineHistoryWrite
10 | IO | 10 | 167772216 | TwophaseFileRead
10 | IO | 10 | 167772217 | TwophaseFileSync
.
.
.
11 | LSN | 11 | 184549376 | LsnDurable
```
# aurora\$1stat\$1wait\$1type
Lista todos os tipos de espera compatíveis para o Aurora PostgreSQL.
## Sintaxe
```
aurora_stat_wait_type()
```
## Argumentos
Nenhum
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ type\$1id: o ID do tipo do evento de espera.
+ type\$1name: nome do tipo de espera.
## Observações de uso
Para ver nomes de eventos de espera com tipos de eventos de espera em vez de IDs, use essa função junto com outras funções, como `aurora_stat_wait_event` e `aurora_stat_system_waits`. Os nomes de tipos de espera retornados por esta função são os mesmos que os retornados pela função `aurora_wait_report`.
## Exemplos
O exemplo a seguir mostra os resultados de uma chamada à função `aurora_stat_wait_type`.
```
=> SELECT *
FROM aurora_stat_wait_type();
type_id | type_name
---------+-----------
1 | LWLock
3 | Lock
4 | BufferPin
5 | Activity
6 | Client
7 | Extension
8 | IPC
9 | Timeout
10 | IO
11 | LSN
```
# aurora\$1version
Retorna o valor de string do número de versão do Amazon Aurora edição compatível com PostgreSQL.
## Sintaxe
```
aurora_version()
```
## Argumentos
Nenhum
## Tipo de retorno
String CHAR ou VARCHAR
## Observações de uso
Essa função exibe a versão do mecanismo de banco de dados do Amazon Aurora edição compatível com PostgreSQL. O número da versão é retornado como uma string formatada como *major*.*minor*.*patch*. Para obter mais informações sobre os número de versão do Aurora PostgreSQL, consulte [Número de versão do Aurora](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions.AuroraNumber).
Você pode escolher quando aplicar atualizações de versões secundárias definindo a janela de manutenção do cluster de banco de dados do Aurora PostgreSQL. Para saber como, consulte [Manutenção de um cluster de banco de dados do Amazon Aurora](USER_UpgradeDBInstance.Maintenance.md).
A partir do lançamento das versões 13.3, 12.8, 11.13, 10.18 do Aurora PostgreSQL e para todas as outras posteriores, os números de versão do Aurora seguem os números de versão do PostgreSQL. Para obter mais informações sobre todas as versões do Aurora PostgreSQL, consulte [Atualizações do Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) nas *Notas de lançamento do Aurora PostgreSQL*.
## Exemplos
O exemplo a seguir mostra os resultados da chamada da função `aurora_version` em um cluster de banco de dados do Aurora PostgreSQL que executa o [PostgreSQL 12.7, Aurora PostgreSQL versão 4.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.42), e depois executa a mesma função em um cluster que executa o [Aurora PostgreSQL versão 13.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.133X).
```
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
```
Este exemplo mostra como usar a função com várias opções para obter mais detalhes sobre a versão do Aurora PostgreSQL. Este exemplo tem um número de versão do Aurora distinto do número de versão do PostgreSQL.
```
=> SHOW SERVER_VERSION;
server_version
----------------
12.7
(1 row)
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
(1 row)
=> SELECT current_setting('server_version') AS "PostgreSQL Compatiblility";
PostgreSQL Compatiblility
---------------------------
12.7
(1 row)
=> SELECT version() AS "PostgreSQL Compatiblility Full String";
PostgreSQL Compatiblility Full String
-------------------------------------------------------------------------------------------------------------
PostgreSQL 12.7 on aarch64-unknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 7.4.0, 64-bit
(1 row)
=> SELECT 'Aurora: '
|| aurora_version()
|| ' Compatible with PostgreSQL: '
|| current_setting('server_version') AS "Instance Version";
Instance Version
------------------------------------------------
Aurora: 4.2.2 Compatible with PostgreSQL: 12.7
(1 row)
```
Este próximo exemplo usa a função com as mesmas opções no exemplo anterior. Este exemplo não tem um número de versão do Aurora distinto do número de versão do PostgreSQL.
```
=> SHOW SERVER_VERSION;
server_version
----------------
13.3
=> SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
=> SELECT current_setting('server_version') AS "PostgreSQL Compatiblility";
PostgreSQL Compatiblility
---------------------------
13.3
=> SELECT version() AS "PostgreSQL Compatiblility Full String";
PostgreSQL Compatiblility Full String
-------------------------------------------------------------------------------------------------
PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (GCC) 7.4.0, 64-bit
=> SELECT 'Aurora: '
|| aurora_version()
|| ' Compatible with PostgreSQL: '
|| current_setting('server_version') AS "Instance Version";
Instance Version
-------------------------------------------------------
Aurora: 13.3.0 Compatible with PostgreSQL: 13.3
```
# aurora\$1volume\$1logical\$1start\$1lsn
Retorna o número de sequência de log (LSN) usado para identificar o início de um registro no stream lógico do log de gravação antecipada (WAL) do volume de cluster do Aurora.
## Sintaxe
```
aurora_volume_logical_start_lsn()
```
## Argumentos
Nenhum
## Tipo de retorno
`pg_lsn`
## Observações de uso
Essa função identifica o início do registro no stream lógico de WAL para determinado volume de cluster do Aurora. Você pode usar essa função enquanto realiza um upgrade de versão principal usando a replicação lógica e a clonagem rápida do Aurora para determinar o LSN em que um snapshot ou clone de banco de dados é gerado. Depois, você pode usar a replicação lógica para transmitir continuamente os dados mais recentes registrados depois do LSN e sincronizar as alterações entre publicador e assinante.
Para obter mais informações sobre como usar a replicação lógica para um upgrade de versão principal, consulte [Usar replicação lógica para realizar uma atualização de versão principal do Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md).
Essa função está disponível nas seguintes versões do Aurora PostgreSQL:
+ Versão 15.2 e versões 15 posteriores
+ Versão 14.3 e versões 14 posteriores
+ Versão 13.6 e versões 13 posteriores
+ Versão 12.10 e versões 12 posteriores
+ Versão 11.15 e versões 11 posteriores
+ Versão 10.20 e versões 10 posteriores
## Exemplos
Você pode obter o número de sequência de log (LSN) usando a seguinte consulta:
```
postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn
---------------
0/402E2F0
(1 row)
```
# aurora\$1wait\$1report
Essa função mostra a atividade de eventos de espera por um período.
## Sintaxe
```
aurora_wait_report([time])
```
## Argumentos
*time (opcional) *
A hora em segundos. O padrão é 10 segundos.
## Tipo de retorno
Registro SETOF com as seguintes colunas:
+ type\$1name: nome do tipo de espera
+ event\$1name: nome do evento de espera
+ wait: número de esperas
+ wait\$1time: tempo de espera em milissegundos
+ ms\$1per\$1wait: média de milissegundos pelo número de uma espera
+ waits\$1per\$1xact: média de esperas pelo número de uma transação
+ ms\$1per\$1wait: média de milissegundos pelo número de transações
## Observações de uso
Essa função está disponível a partir do Aurora PostgreSQL versão 1.1 compatível com PostgreSQL 9.6.6 e versões posteriores.
Para usar essa função, você precisa primeiro criar a extensão `aurora_stat_utils` do Aurora PostgreSQL, da seguinte forma:
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
Para obter mais informações sobre as versões de extensão do Aurora PostgreSQL disponíveis, consulte [Versões de extensão do Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) em *Notas de lançamento do Aurora PostgreSQL*.
Essa função calcula os eventos de espera no nível da instância comparando dois snapshots de dados estatísticos da função aurora\$1stat\$1system\$1waits() e das visualizações estatísticas pg\$1stat\$1database do PostgreSQL.
Para obter mais informações sobre `aurora_stat_system_waits()` e `pg_stat_database`, consulte [Coletor de estatísticas](https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-DATABASE-VIEW) na *documentação do PostgreSQL*.
Quando executada, essa função tira um snapshot inicial, aguarda o número de segundos especificado e, depois, tira um segundo snapshot. A função compara os dois snapshots e retorna a diferença. Essa diferença representa a atividade da instância para esse intervalo de tempo.
Na instância de gravador, a função também exibe o número de transações confirmadas e TPS (transações por segundo). Essa função retorna informações no nível da instância e inclui todos os bancos de dados na instância.
## Exemplos
Este exemplo mostra como criar a extensão aurora\$1stat\$1utils para poder usar a função aurora\$1wait\$1report.
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
Este exemplo mostra como conferir o relatório de espera por 10 segundos.
```
=> SELECT *
FROM aurora_wait_report();
NOTICE: committed 34 transactions in 10 seconds (tps 3)
type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
-----------+-------------------+-------+-----------+-------------+----------------+-------------
Client | ClientRead | 26 | 30003.00 | 1153.961 | 0.76 | 882.441
Activity | WalWriterMain | 50 | 10051.32 | 201.026 | 1.47 | 295.627
Timeout | PgSleep | 1 | 10049.52 | 10049.516 | 0.03 | 295.574
Activity | BgWriterHibernate | 1 | 10048.15 | 10048.153 | 0.03 | 295.534
Activity | AutoVacuumMain | 18 | 9941.66 | 552.314 | 0.53 | 292.402
Activity | BgWriterMain | 1 | 201.09 | 201.085 | 0.03 | 5.914
IO | XactSync | 15 | 25.34 | 1.690 | 0.44 | 0.745
IO | RelationMapRead | 12 | 0.54 | 0.045 | 0.35 | 0.016
IO | WALWrite | 84 | 0.21 | 0.002 | 2.47 | 0.006
IO | DataFileExtend | 1 | 0.02 | 0.018 | 0.03 | 0.001
```
Este exemplo mostra como conferir o relatório de espera por 60 segundos.
```
=> SELECT *
FROM aurora_wait_report(60);
NOTICE: committed 1544 transactions in 60 seconds (tps 25)
type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
-----------+------------------------+---------+-----------+-------------+----------------+-------------
Lock | transactionid | 6422 | 477000.53 | 74.276 | 4.16 | 308.938
Client | ClientRead | 8265 | 270752.99 | 32.759 | 5.35 | 175.358
Activity | CheckpointerMain | 1 | 60100.25 | 60100.246 | 0.00 | 38.925
Timeout | PgSleep | 1 | 60098.49 | 60098.493 | 0.00 | 38.924
Activity | WalWriterMain | 296 | 60010.99 | 202.740 | 0.19 | 38.867
Activity | AutoVacuumMain | 107 | 59827.84 | 559.139 | 0.07 | 38.749
Activity | BgWriterMain | 290 | 58821.83 | 202.834 | 0.19 | 38.097
IO | XactSync | 1295 | 55220.13 | 42.641 | 0.84 | 35.764
IO | WALWrite | 6602259 | 47810.94 | 0.007 | 4276.07 | 30.966
Lock | tuple | 473 | 29880.67 | 63.173 | 0.31 | 19.353
LWLock | buffer_mapping | 142 | 3540.13 | 24.930 | 0.09 | 2.293
Activity | BgWriterHibernate | 290 | 1124.15 | 3.876 | 0.19 | 0.728
IO | BufFileRead | 7615 | 618.45 | 0.081 | 4.93 | 0.401
LWLock | buffer_content | 73 | 345.93 | 4.739 | 0.05 | 0.224
LWLock | lock_manager | 62 | 191.44 | 3.088 | 0.04 | 0.124
IO | RelationMapRead | 72 | 5.16 | 0.072 | 0.05 | 0.003
LWLock | ProcArrayLock | 1 | 2.01 | 2.008 | 0.00 | 0.001
IO | ControlFileWriteUpdate | 2 | 0.03 | 0.013 | 0.00 | 0.000
IO | DataFileExtend | 1 | 0.02 | 0.018 | 0.00 | 0.000
IO | ControlFileSyncUpdate | 1 | 0.00 | 0.000 | 0.00 | 0.000
```