# Monitoramento do Aurora PostgreSQL Limitless Database
Você pode usar o Amazon CloudWatch, o Monitoramento aprimorado e o Insights de Performance para monitorar o Aurora PostgreSQL Limitless Database. Também há novas funções e visualizações de estatísticas, e eventos de espera, para o Aurora PostgreSQL Limitless Database que você pode usar para monitoramento e diagnóstico.
**Topics**
+ [Monitorar o Aurora PostgreSQL Limitless Database com o Amazon CloudWatch](limitless-monitoring.cw.md)
+ [Monitorar o Aurora PostgreSQL Limitless Database com o CloudWatch Database Insights](limitless-monitoring.cwdbi.md)
+ [Monitoramento do Aurora PostgreSQL Limitless Database com o Amazon CloudWatch Logs](limitless-monitoring.cwl.md)
+ [Monitoramento do Aurora PostgreSQL Limitless Database com Monitoramento aprimorado](limitless-monitoring.em.md)
+ [Monitoramento do Aurora PostgreSQL Limitless Database com o Insights de Performance](limitless-monitoring.pi.md)
+ [Monitoramento do Aurora PostgreSQL Limitless Database com o Amazon GuardDuty RDS Protection](limitless-monitoring.gd.md)
+ [Funções e visualizações do Aurora PostgreSQL Limitless Database](limitless-monitoring-fns-views.md)
+ [Eventos de espera do Aurora PostgreSQL Limitless Database](limitless-monitoring-waits.md)
+ [Usar funções para aumentar a eficiência](limitless-performance-functions.md)
# Monitorar o Aurora PostgreSQL Limitless Database com o Amazon CloudWatch
As métricas do CloudWatch para o Aurora PostgreSQL Limitless Database são relatadas nas seguintes dimensões:
+ [DBShardGroup](#limitless-monitoring.cw.DBShardGroup)
+ [DBShardGroupRouterAggregation](#limitless-monitoring.cw.DBShardGroupRouterAggregate)
+ [DBShardGroupInstance](#limitless-monitoring.cw.DBShardGroupInstance)
+ [DBClusterIdentifier](#limitless-monitoring.cw.DBClusterIdentifier)
Para obter mais informações sobre métricas do CloudWatch, consulte [Monitorar métricas do Amazon Aurora com o Amazon CloudWatch](monitoring-cloudwatch.md).
## Métricas do DBShardGroup
Para ver métricas `DBShardGroup` do Aurora PostgreSQL Limitless Database no console do CloudWatch, escolha **RDS** e, em seguida, **DBShardGroup**.
Você pode acompanhar as seguintes métricas do CloudWatch:
+ `DBShardGroupACUUtilization`: uso da unidade de capacidade do Aurora (ACU) como uma porcentagem calculada a partir de `DBShardGroupCapacity` dividido por `DBShardGroupMaxACU`.
+ `DBShardGroupCapacity`: número de ACUs consumidas por instâncias do gravador do grupo de fragmentos de banco de dados.
+ `DBShardGroupComputeRedundancyCapacity`: número de ACUs consumidas por instâncias em espera do gravador do grupo de fragmentos de banco de dados.
+ `DBShardGroupMaxACU`: número máximo de ACUs configuradas para o grupo de fragmentos de banco de dados.
+ `DBShardGroupMinACU`: número mínimo de ACUs exigido pelo grupo de fragmentos de banco de dados.
A chave de dimensão `DBShardGroupIdentifier` está disponível para agregar as métricas `DBShardGroup`.
## Métricas do DBShardGroupRouterAggregation
Para ver métricas `DBShardGroupRouterAggregation` do Aurora PostgreSQL Limitless Database no console do CloudWatch, escolha **RDS** e, em seguida, **DBShardGroupRouterAggregation**.
Você pode acompanhar as seguintes métricas do CloudWatch:
+ `CommitThroughput`: o número médio de operações de confirmação por segundo em todos os nós do roteador no grupo de fragmentos de banco de dados.
+ `DatabaseConnections`: a soma de todas as conexões em todos os nós do roteador no grupo de fragmentos de banco de dados.
## Métricas do DBShardGroupInstance
DBShardGroupInstance é a instância de banco de dados individual dentro de cada fragmento ou subcluster de roteador.
Para ver métricas `DBShardGroupInstance` do Aurora PostgreSQL Limitless Database no console do CloudWatch, escolha **RDS** e, em seguida, **DBShardGroupInstance**.
Você pode acompanhar as seguintes métricas do CloudWatch:
+ `ACUUtilization`: a porcentagem calculada como a métrica `ServerlessDatabaseCapacity` dividida pelo valor máximo de ACU atribuído ao subcluster.
+ `AuroraReplicaLag`: para clusters do Limitless com a redundância de computação habilitada, essa é a quantidade de atraso ao replicar atualizações da instância primária no subcluster.
+ `AuroraReplicaLagMaximum`: para clusters do Limitless com redundância de computação habilitada, essa é a quantidade máxima de atraso ao replicar atualizações da instância primária no subcluster. Quando as réplicas de leitura são excluídas ou renomeadas, pode haver um aumento temporário no atraso de replicação à medida que o recurso antigo é reciclado. Use essa métrica para descobrir se ocorreu um failover devido a um alto atraso na replicação em um dos leitores.
+ `AuroraReplicaLagMinimum`: para clusters do Limitless com redundância de computação habilitada, essa é a quantidade mínima de atraso ao replicar atualizações da instância primária no subcluster.
+ `BufferCacheHitRatio`: a porcentagem de dados e índices fornecidos pelo cache de memória de uma instância (ao contrário do volume de armazenamento).
+ `CommitLatency`: a duração média para o mecanismo e o armazenamento concluírem as operações de confirmação de um nó específico (roteador ou fragmento).
+ `CommitThroughput`: o número médio de operações de confirmação por segundo.
+ `CPUUtilization`: uso da CPU como porcentagem do valor máximo de ACU atribuído ao subcluster.
+ `FreeableMemory`: a quantidade de memória não utilizada que está disponível quando o grupo de fragmentos é escalado para sua capacidade máxima. Isso é determinado pelas ACUs atribuídas do grupo de fragmentos. Para cada ACU em que a capacidade atual está abaixo da capacidade máxima, esse valor aumenta em aproximadamente 2 GiB. Desse modo, essa métrica não se aproxima de zero enquanto o grupo de fragmentos de banco de dados não for escalado até o limite máximo.
+ `MaximumUsedTransactionIDs`: a idade do ID da transação mais antiga sem limpeza, em transações. Se esse valor atingir 2.146.483.648 (2^31 - 1.000.000), o banco de dados será forçado para o modo somente leitura a fim de evitar a conclusão do ID da transação. Para ter mais informações, consulte [Evitar falhas de conclusão do ID da transação](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) na documentação do PostgreSQL.
+ `NetworkReceiveThroughput`: a quantidade de throughput de rede recebida dos clientes por cada instância no grupo de fragmentos de bancos de dados. Esse throughput não inclui o tráfego de rede entre instâncias no grupo de fragmentos de banco de dados e o volume do cluster.
+ `NetworkThroughput`: o throughput da rede agregada (tanto transmitida quanto recebida) entre clientes e roteadores, e roteadores e fragmentos no grupo de fragmentos de banco de dados. Esse throughput não inclui o tráfego de rede entre instâncias no grupo de fragmentos de banco de dados e o volume do cluster.
+ `NetworkTransmitThroughput`: a quantidade de throughput de rede enviada aos clientes por cada instância no grupo de fragmentos de bancos de dados. Esse throughput não inclui o tráfego de rede entre instâncias no grupo de fragmentos de banco de dados e o volume do cluster.
+ `ReadIOPS`: o número médio de operações de entrada e saída por segundo (IOPS) de leitura de disco.
+ `ReadLatency`: o tempo médio necessário por operação de entrada/saída (E/S) de leitura de disco.
+ `ReadThroughput`: o número médio de bytes lidos do disco por segundo.
+ `ServerlessDatabaseCapacity`: a capacidade atual do fragmento de banco de dados ou do subcluster de roteador dentro do grupo de fragmentos de banco de dados.
+ `StorageNetworkReceiveThroughput`: a quantidade de throughput de rede recebida do subsistema de armazenamento do Aurora por cada instância no grupo de fragmentos de banco de dados.
+ `StorageNetworkThroughput`: o throughput de rede agregado, tanto transmitido quanto recebido do subsistema de armazenamento do Aurora por cada instância no grupo de fragmentos de banco de dados.
+ `StorageNetworkTransmitThroughput`: a quantidade de throughput de rede enviada ao subsistema de armazenamento do Aurora por cada instância no grupo de fragmentos de banco de dados.
+ `SwapUsage`: a quantidade de espaço de troca usado pelo grupo de fragmentos do banco de dados.
+ `TempStorageIOPS`: o número médio de operações de E/S realizadas no armazenamento local anexado à instância de banco de dados. Inclui operações de E/S de leitura e gravação.
`TempStorageIOPS` pode ser usado com `TempStorageThroughput` para diagnosticar os casos raros em que a atividade de rede para transferências entre suas instâncias de banco de dados e dispositivos de armazenamento local é responsável por aumentos inesperados de capacidade.
+ `TempStorageThroughput`: a quantidade de dados transferidos do armazenamento local associado a um roteador ou fragmento.
+ `WriteIOPS`: o número médio de IOPS de gravação em disco.
+ `WriteLatency`: o tempo médio necessário por operação de E/S de gravação em disco.
+ `WriteThroughput`: o número médio de bytes gravados no disco por segundo.
As seguintes chaves de dimensão estão disponíveis para agregar as métricas `DBShardGroupInstance`:
+ `DBClusterIdentifier`: o cluster de banco de dados do Aurora PostgreSQL.
+ `DBShardGroupIdentifier`: o grupo de fragmentos de banco de dados ao qual a instância pertence.
+ `DBShardGroupSubClusterType`: o tipo de nó, seja `Distributed Transaction Router` (roteador) ou `Data Access Shard` (fragmento).
+ `DBShardGroupSubClusterIdentifier`: o nome do roteador ou fragmento ao qual a instância pertence.
A seguir estão exemplos de agregação de métricas do CloudWatch:
+ Total `CPUUtilization` de todas as instâncias que pertencem a um fragmento ou roteador específico em um grupo de fragmentos de banco de dados.
+ Total `CPUUtilization` de todas as instâncias em um grupo de fragmentos de banco de dados.
## Métricas do DBClusterIdentifier
Para ver métricas `DBClusterIdentifier` do Aurora PostgreSQL Limitless Database no console do CloudWatch, escolha **RDS** e, em seguida, **DBClusterIdentifier**.
Ao usar o Aurora PostgreSQL Limitless Database, você pode ter mais operações de entrada/saída (E/S) do que teria com um cluster de banco de dados do Aurora. Você pode acompanhar as seguintes métricas do CloudWatch para seu cluster do Limitless Database:
+ `VolumeReadIops`: o número de operações de E/S de leitura faturadas a partir de um volume de cluster, relatado em intervalos de 5 minutos.
+ `VolumeWriteIops`: o número de operações de E/S do disco do gravador no volume de cluster, relatado em intervalos de 5 minutos.
O Aurora PostgreSQL Limitless Database usa a configuração de armazenamento em cluster Aurora I/O-Optimized. Com Aurora I/O-Optimized, você paga um único preço mensal por todas as operações de E/S, em vez de pagar por cada milhão de solicitações de E/S. Para obter mais informações, consulte [Configurações de armazenamento para clusters de banco de dados do Amazon Aurora](Aurora.Overview.StorageReliability.md#aurora-storage-type).
Você também pode usar mais armazenamento do que usaria em um cluster de banco de dados do Aurora. Você pode acompanhar as seguintes métricas de armazenamento do CloudWatch:
+ `BackupRetentionPeriodStorageUsed`: o uso total faturado do armazenamento de backup contínuo do cluster do Aurora PostgreSQL Limitless Database.
+ `SnapshotStorageUsed`: o uso total faturado do armazenamento de snapshots do cluster do Aurora PostgreSQL Limitless Database.
+ `TotalBackupStorageBilled`: a soma dos custos de retenção automática de backup e snapshots de cluster de banco de dados.
Para obter mais informações sobre os custos de armazenamento de backup, consulte [Noções básicas do uso do armazenamento de backup do Amazon Aurora](aurora-storage-backup.md).
+ `VolumeBytesUsed`: a quantidade de armazenamento usada pelo cluster do Aurora PostgreSQL Limitless Database, relatada em intervalos de 5 minutos.
# Monitorar o Aurora PostgreSQL Limitless Database com o CloudWatch Database Insights
O modo padrão do Database Insights é necessário como parte da habilitação do Aurora PostgreSQL Limitless Database. Você pode usá-lo para monitorar em tempo real a carga do banco de dados das instâncias de banco de dados do Limitless Database. A carga do banco de dados avalia o nível de atividade de sessão em um banco de dados. Você pode usar o Database Insights para analisar e solucionar problemas de performance das instâncias de bancos de dados do Aurora PostgreSQL Limitless Database em grande escala.
Para ter mais informações sobre as métricas do CloudWatch Database Insights, consulte os tópicos a seguir.
+ [Monitoramento de bancos de dados do Amazon Aurora com o CloudWatch Database Insights](USER_DatabaseInsights.md)
+ [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html) no *Guia do usuário do Amazon CloudWatch*
+ [Conceitos básicos do CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Get-Started.html) no *Guia do usuário do Amazon CloudWatch*
+ [Configurar o banco de dados para monitorar consultas SQL lentas com o Database Insights para Amazon Aurora](USER_DatabaseInsights.SlowSQL.md)
Para ter informações sobre como ativar o modo avançado ou o modo padrão do Database Insights, consulte os tópicos a seguir.
**Topics**
+ [Ativar o modo avançado do Database Insights para o Aurora PostgreSQL Limitless Database](limitless-monitoring.cwdbi.advanced.md)
+ [Ativar o modo padrão do Database Insights para o Aurora PostgreSQL Limitless Database](limitless-monitoring.cwdbi.standard.md)
# Ativar o modo avançado do Database Insights para o Aurora PostgreSQL Limitless Database
Ativar o modo avançado do Database Insights para o Aurora PostgreSQL Limitless Database, use os procedimentos a seguir.
## Ativar o modo avançado do Database Insights ao criar um cluster de banco de dados para o Aurora PostgreSQL Limitless Database
Ative o modo avançado do Database Insights ao criar um banco de dados para o Aurora PostgreSQL Limitless Database.
------
#### [ Console ]
No console, você pode ativar o modo Avançado do Database Insights ao criar um cluster de banco de dados. As configurações do Database Insights se aplicam a todas as instâncias de banco de dados em seu cluster de banco de dados.
**Como ativar o modo avançado do Database Insights ao criar um cluster de banco de dados usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Databases (Bancos de dados)**.
1. Selecione **Criar banco de dados**.
1. Na seção **Database Insights**, selecione **Modo avançado**. Em seguida, escolha as seguintes opções:
+ **Retention (Retenção)** – a duração do período de retenção de dados do Performance Insights. O período de retenção deve ser de 15 a 24 meses para o modo avançado do Database Insights.
+ **AWS KMS key**: especifique a sua chave do KMS. O Performance Insights criptografa todos os possíveis dados sigilosos usando a sua chave do KMS. Os dados são criptografados em repouso e em trânsito. Para obter mais informações, consulte [Criptografar recursos do Amazon Aurora](Overview.Encryption.md).
1. Selecione **Criar banco de dados**.
------
#### [ AWS CLI ]
Para ativar o modo Avançado do Database Insights ao criar um cluster de banco de dados, chame o comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) da AWS CLI e forneça os seguintes valores:
+ `--db-cluster-identifier`: o identificador do cluster de banco de dados.
+ `--database-insights-mode advanced` para ativar o modo Avançado do Database Insights.
+ `--engine`: o cluster de banco de dados deve usar o mecanismo de banco de dados `aurora-postgresql`.
+ `--engine-version`: o cluster de banco de dados deve usar uma das versões do mecanismo de banco de dados:
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type`: o cluster de banco de dados deve usar a configuração de armazenamento `aurora-iopt1` do cluster de banco de dados.
+ `--cluster-scalability-type`: especifica o modo de escalabilidade do cluster de banco de dados do Aurora. Quando definido como `limitless`, o cluster opera como um Aurora PostgreSQL Limitless Database. Quando definido como `standard` (o padrão), o cluster usa a criação normal de instância de banco de dados.
**nota**
Não é possível modificar essa configuração após a criação do cluster de banco de dados.
+ `--master-username`: o nome do usuário principal do cluster de banco de dados.
+ `--master-user-password`: a senha do usuário principal.
+ `--enable-performance-insights` para ativar o Performance Insights para o Database Insights.
+ `--performance-insights-retention-period`: o período de retenção de dados para seu cluster de banco de dados. Para ativar o Database Insights, o período de retenção deve ser de pelo menos 465 dias.
+ `--monitoring-interval`: o intervalo, em segundos, entre os pontos quando as métricas do Monitoramento aprimorado são coletadas para o cluster de banco de dados. Esse valor não pode ser `0`.
+ `--monitoring-role-arn`: o nome do recurso da Amazon (ARN) do perfil do IAM que permite que o RDS envie métricas do - para o Amazon CloudWatch Logs.
+ `--enable-cloudwatch-logs-exports`: você deve exportar logs `postgresql` para o CloudWatch Logs.
O exemplo a seguir ativa o modo Avançado do Database Insights ao criar um cluster de banco de dados.
Para Linux, macOS ou Unix:
```
aws rds create-db-cluster \
--db-cluster-identifier my-limitless-cluster \
--database-insights-mode advanced \
--engine aurora-postgresql \
--engine-version 16.6-limitless \
--storage-type aurora-iopt1 \
--cluster-scalability-type limitless \
--master-username myuser \
--master-user-password mypassword \
--enable-performance-insights \
--performance-insights-retention-period 465 \
--monitoring-interval 5 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \
--enable-cloudwatch-logs-exports postgresql
```
Para Windows:
```
aws rds create-db-cluster ^
--db-cluster-identifier my-limitless-cluster ^
--database-insights-mode advanced ^
--engine aurora-postgresql ^
--engine-version 16.6-limitless ^
--storage-type aurora-iopt1 ^
--cluster-scalability-type limitless ^
--master-username myuser ^
--master-user-password mypassword ^
--enable-performance-insights ^
--performance-insights-retention-period 465 ^
--monitoring-interval 5 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^
--enable-cloudwatch-logs-exports postgresql
```
------
#### [ RDS API ]
Para ativar o modo Avançado do Database Insights ao criar um cluster de banco de dados, especifique os parâmetros a seguir para a operação de API [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) do Amazon RDS.
+ `DatabaseInsightsMode` para `advanced`
+ `Engine` para `aurora-postgresql`
+ `EngineVersion` para uma versão de mecanismo disponível para o Limitless Database
+ `StorageType` para `aurora-iopt1`
+ `ClusterScalabilityType` para `limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights` para `True`
+ `PerformanceInsightsRetentionPeriod` para pelo menos `465` dias
+ `MonitoringInterval` para um valor que não seja `0`
+ `MonitoringRoleArn` para o nome do recurso da Amazon (ARN) do perfil do IAM que permite que o RDS envie métricas do monitoramento avançado para o Amazon CloudWatch Logs
------
## Ativar o modo Avançado do Database Insights ao modificar um cluster de banco de dados do Aurora PostgreSQL Limitless Database
Ative o Database Insights ao modificar um banco de dados para o Aurora PostgreSQL Limitless Database.
**nota**
Para habilitar o Database Insights, cada instância de banco de dados em um cluster de banco de dados deve ter as mesmas configurações do Insights de Performance e do monitoramento avançado.
------
#### [ Console ]
No console, você pode ativar o modo Avançado do Database Insights ao modificar um cluster de banco de dados. As configurações do Database Insights se aplicam a todas as instâncias de banco de dados em seu cluster de banco de dados.
**Como ativar o modo avançado do Database Insights ao modificar um cluster de banco de dados usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Databases (Bancos de dados)**.
1. Escolha o cluster de banco de dados e selecione **Modificar**.
1. Na seção **Database Insights**, selecione **Modo avançado**. Em seguida, escolha as seguintes opções:
+ **Retention (Retenção)** – a duração do período de retenção de dados do Performance Insights. O período de retenção deve ser de 15 a 24 meses para o modo avançado do Database Insights.
+ **AWS KMS key**: especifique a sua chave do KMS. O Performance Insights criptografa todos os possíveis dados sigilosos usando a sua chave do KMS. Os dados são criptografados em repouso e em trânsito. Para obter mais informações, consulte [Criptografar recursos do Amazon Aurora](Overview.Encryption.md).
1. Escolha **Continue**.
1. Em **Programação das modificações**, selecione **Aplicar imediatamente**. Se você escolher **Aplicar durante a próxima janela de manutenção programada**, seu banco de dados vai ignorar essa configuração e ativar imediatamente o modo Avançado do Database Insights.
1. Escolha **Modificar Cluster**.
------
#### [ AWS CLI ]
Para ativar o modo Avançado do Database Insights ao modificar um cluster de banco de dados, chame o comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) da AWS CLI e forneça os seguintes valores:
+ `--database-insights-mode advanced` para ativar o modo Avançado do Database Insights.
+ `--db-cluster-identifier`: o identificador do cluster de banco de dados.
+ `--enable-performance-insights` para ativar o Performance Insights para o Database Insights.
+ `--performance-insights-retention-period`: o período de retenção de dados do cluster de banco de dados. Para ativar o modo Avançado do Database Insights, o período de retenção deve ser de pelo menos 465 dias.
O exemplo a seguir ativa o modo Avançado do Database Insights ao modificar um cluster de banco de dados.
Para Linux, macOS ou Unix:
```
aws rds modify-db-cluster \
--database-insights-mode advanced \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 465
```
Para Windows:
```
aws rds modify-db-cluster ^
--database-insights-mode advanced ^
--db-cluster-identifier sample-db-identifier ^
--enable-performance-insights ^
--performance-insights-retention-period 465
```
------
#### [ RDS API ]
Para ativar o modo avançado do Database Insights ao modificar uma um cluster de banco de dados, especifique os parâmetros a seguir para a operação de API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) do Amazon RDS.
+ `DatabaseInsightsMode` para `advanced`
+ `EnablePerformanceInsights` para `True`
+ `PerformanceInsightsRetentionPeriod` para pelo menos `465` dias
------
# Ativar o modo padrão do Database Insights para o Aurora PostgreSQL Limitless Database
Ativar o modo padrão do Database Insights para o Aurora PostgreSQL Limitless Database, use os procedimentos a seguir.
## Ativar o modo padrão do Database Insights ao criar um cluster de banco de dados para o Aurora PostgreSQL Limitless Database
Ative o modo padrão do Database Insights ao criar um banco de dados para o Aurora PostgreSQL Limitless Database.
------
#### [ Console ]
No console, você pode ativar o modo Standard do Database Insights ao criar um cluster de banco de dados. As configurações do Database Insights se aplicam a todas as instâncias de banco de dados em seu cluster de banco de dados.
**Como ativar o modo padrão do Database Insights ao criar um cluster de banco de dados usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Databases (Bancos de dados)**.
1. Selecione **Criar banco de dados**.
1. Na seção **Database Insights**, selecione **Modo Standard**. Em seguida, escolha as seguintes opções:
+ **Retention (Retenção)** – a duração do período de retenção de dados do Performance Insights. Para criar um cluster de banco de dados para o Aurora PostgreSQL Limitless Database, o período de retenção deve ser de pelo menos 31 dias.
+ **AWS KMS key**: especifique a sua chave do KMS. O Performance Insights criptografa todos os possíveis dados sigilosos usando a sua chave do KMS. Os dados são criptografados em repouso e em trânsito. Para obter mais informações, consulte [Criptografar recursos do Amazon Aurora](Overview.Encryption.md).
1. Selecione **Criar banco de dados**.
------
#### [ AWS CLI ]
Para ativar o modo Standard do Database Insights ao criar um cluster de banco de dados, chame o comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) da AWS CLI e forneça os seguintes valores:
+ `--db-cluster-identifier`: o identificador do cluster de banco de dados.
+ `--database-insights-mode standard` para ativar o modo Standard do Database Insights.
+ `--engine`: o cluster de banco de dados deve usar o mecanismo de banco de dados `aurora-postgresql`.
+ `--engine-version`: o cluster de banco de dados deve usar uma das versões do mecanismo de banco de dados:
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type`: o cluster de banco de dados deve usar a configuração de armazenamento `aurora-iopt1` do cluster de banco de dados.
+ `--cluster-scalability-type`: especifica o modo de escalabilidade do cluster de banco de dados do Aurora. Quando definido como `limitless`, o cluster opera como um Aurora PostgreSQL Limitless Database. Quando definido como `standard` (o padrão), o cluster usa a criação normal de instância de banco de dados.
**nota**
Não é possível modificar essa configuração após a criação do cluster de banco de dados.
+ `--master-username`: o nome do usuário principal do cluster de banco de dados.
+ `--master-user-password`: a senha do usuário principal.
+ `--enable-performance-insights` para ativar o Performance Insights para o Database Insights.
+ `--performance-insights-retention-period`: o período de retenção de dados para seu cluster de banco de dados. Para criar um cluster de banco de dados para o Aurora PostgreSQL Limitless Database, o período de retenção deve ser de pelo menos 31 dias.
+ `--monitoring-interval`: o intervalo, em segundos, entre os pontos quando as métricas do Monitoramento aprimorado são coletadas para o cluster de banco de dados. Esse valor não pode ser `0`.
+ `--monitoring-role-arn`: o nome do recurso da Amazon (ARN) do perfil do IAM que permite que o RDS envie métricas do - para o Amazon CloudWatch Logs.
+ `--enable-cloudwatch-logs-exports`: você deve exportar logs `postgresql` para o CloudWatch Logs.
O exemplo a seguir habilita o modo padrão do Database Insights ao criar um cluster de banco de dados.
Para Linux, macOS ou Unix:
```
aws rds create-db-cluster \
--db-cluster-identifier my-limitless-cluster \
--database-insights-mode standard \
--engine aurora-postgresql \
--engine-version 16.6-limitless \
--storage-type aurora-iopt1 \
--cluster-scalability-type limitless \
--master-username myuser \
--master-user-password mypassword \
--enable-performance-insights \
--performance-insights-retention-period 31 \
--monitoring-interval 5 \
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \
--enable-cloudwatch-logs-exports postgresql
```
Para Windows:
```
aws rds create-db-cluster ^
--db-cluster-identifier my-limitless-cluster ^
--database-insights-mode standard ^
--engine aurora-postgresql ^
--engine-version 16.6-limitless ^
--storage-type aurora-iopt1 ^
--cluster-scalability-type limitless ^
--master-username myuser ^
--master-user-password mypassword ^
--enable-performance-insights ^
--performance-insights-retention-period 31 ^
--monitoring-interval 5 ^
--monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^
--enable-cloudwatch-logs-exports postgresql
```
------
#### [ RDS API ]
Para ativar o modo padrão do Database Insights ao criar , especifique os parâmetros a seguir para a operação de API [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) do Amazon RDS.
+ `DatabaseInsightsMode` para `standard`
+ `Engine` para `aurora-postgresql`
+ `EngineVersion` para uma versão de mecanismo disponível para o Limitless Database
+ `StorageType` para `aurora-iopt1`
+ `ClusterScalabilityType` para `limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights` para `True`
+ `PerformanceInsightsRetentionPeriod` para pelo menos `31` dias
+ `MonitoringInterval` para um valor que não seja `0`
+ `MonitoringRoleArn` para o nome do recurso da Amazon (ARN) do perfil do IAM que permite que o RDS envie métricas do monitoramento avançado para o Amazon CloudWatch Logs
------
## Ativar o modo padrão do Database Insights ao modificar um cluster de banco de dados para o Aurora PostgreSQL Limitless Database
Ative o Database Insights ao modificar um banco de dados para o Aurora PostgreSQL Limitless Database.
**nota**
Para habilitar o Database Insights, cada instância de banco de dados em um cluster de banco de dados deve ter as mesmas configurações do Insights de Performance e do monitoramento avançado.
------
#### [ Console ]
No console, você pode ativar o modo Standard do Database Insights ao criar um cluster de banco de dados. As configurações do Database Insights se aplicam a todas as instâncias de banco de dados em seu cluster de banco de dados.
**Como ativar o modo padrão do Database Insights ao modificar um cluster de banco de dados usando o console**
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Escolha **Databases (Bancos de dados)**.
1. Escolha o cluster de banco de dados e selecione **Modificar**.
1. Na seção **Database Insights**, selecione **Modo Standard**. Em seguida, escolha as seguintes opções:
+ **Retention (Retenção)** – a duração do período de retenção de dados do Performance Insights. Para criar um cluster de banco de dados para o Aurora PostgreSQL Limitless Database, o período de retenção deve ser de pelo menos 31 dias.
+ **AWS KMS key**: especifique a sua chave do KMS. O Performance Insights criptografa todos os possíveis dados sigilosos usando a sua chave do KMS. Os dados são criptografados em repouso e em trânsito. Para obter mais informações, consulte [Criptografar recursos do Amazon Aurora](Overview.Encryption.md).
1. Escolha **Continue**.
1. Em **Programação das modificações**, selecione **Aplicar imediatamente**. Se você escolher **Aplicar durante a próxima janela de manutenção programada**, seu banco de dados vai ignorar essa configuração e ativar imediatamente o modo Padrão do Database Insights.
1. Escolha **Modificar Cluster**.
------
#### [ AWS CLI ]
Para ativar o modo Standard do Database Insights ao modificar um cluster de banco de dados, chame o comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) da AWS CLI e forneça os seguintes valores:
+ `--db-cluster-identifier`: o identificador do cluster de banco de dados.
+ `--database-insights-mode standard` para ativar o modo Standard do Database Insights.
+ `--enable-performance-insights` para ativar o Performance Insights para o Database Insights.
+ `--performance-insights-retention-period`: o período de retenção de dados para seu cluster de banco de dados. Para ativar o modo padrão do Database Insights, o período de retenção deve ser de pelo menos 31 dias.
O exemplo a seguir habilita o modo padrão do Database Insights ao modificar um cluster de banco de dados.
Para Linux, macOS ou Unix:
```
aws rds modify-db-cluster \
--database-insights-mode standard \
--db-cluster-identifier sample-db-identifier \
--enable-performance-insights \
--performance-insights-retention-period 31
```
Para Windows:
```
aws rds modify-db-cluster ^
--database-insights-mode standard ^
--db-cluster-identifier sample-db-identifier ^
--enable-performance-insights ^
--performance-insights-retention-period 31
```
------
#### [ RDS API ]
Para ativar o modo padrão do Database Insights ao modificar um cluster de banco de dados, especifique os parâmetros a seguir para a operação de API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) do Amazon RDS.
+ `DatabaseInsightsMode` para `standard`
+ `EnablePerformanceInsights` para `True`
+ `PerformanceInsightsRetentionPeriod` para pelo menos `31` dias
------
# Monitoramento do Aurora PostgreSQL Limitless Database com o Amazon CloudWatch Logs
A exportação de logs do PostgreSQL para o CloudWatch Logs é necessária como parte da habilitação do Aurora PostgreSQL Limitless Database. Você pode acessar e analisar esses logs no CloudWatch Logs Insights, de forma semelhante ao acesso aos logs do PostgreSQL para um cluster de banco de dados do Aurora PostgreSQL padrão. Para ter mais informações, consulte [Analisar logs do PostgreSQL utilizando o CloudWatch Logs Insights](AuroraPostgreSQL.CloudWatch.Analyzing.md).
O nome do grupo de logs para o cluster de banco de dados é o mesmo do Aurora PostgreSQL:
```
/aws/rds/cluster/DB_cluster_ID/postgresql
```
O nome do grupo de logs para o grupo de fragmentos de banco de dados tem o seguinte formato:
```
/aws/rds/cluster/DB_cluster_ID/DB_shard_group_ID/postgresql
```
Há fluxos de logs para cada nó (roteador ou fragmento). Os nomes têm o seguinte formato:
```
[DistributedTransactionRouter|DataAccessShard]/node_cluster_serial_ID-node_instance_serial_ID/n
```
Por exemplo:
+ Roteador: `DistributedTransactionRouter/6-6.2`
+ Fragmento: `DataAccessShard/22-22.0`
**nota**
Não é possível visualizar os arquivos de log do PostgreSQL para o grupo de fragmentos de banco de dados diretamente no console do RDS, na AWS CLI ou na API do RDS, como você pode fazer para o cluster de banco de dados. Você deve usar o CloudWatch Logs Insights para visualizá-los.
# Monitoramento do Aurora PostgreSQL Limitless Database com Monitoramento aprimorado
O Monitoramento aprimorado é necessário como parte da ativação do Aurora PostgreSQL Limitless Database. Você pode usá-lo para monitorar o sistema operacional das instâncias de banco de dados do Limitless Database em tempo real.
O Aurora publica métricas de Monitoramento aprimorado no CloudWatch Logs. Algumas das principais métricas disponíveis incluem conexões de banco de dados, uso de armazenamento e latência de consultas. Elas podem ajudar a identificar gargalos de desempenho.
Para ter mais informações sobre as métricas do Monitoramento Avançado, consulte [Métricas do SO para Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
# Monitoramento do Aurora PostgreSQL Limitless Database com o Insights de Performance
Use o Insights de Performance para monitorar o cluster do Aurora PostgreSQL Limitless Database. O Insights de Performance funciona de forma semelhante para o Aurora PostgreSQL Limitless Database e para clusters de banco de dados do Aurora padrão. No entanto, você monitora métricas no nível do grupo de fragmentos para o Aurora PostgreSQL Limitless Database.
As duas principais métricas do Insights de Performance a serem monitoradas são as seguintes:
+ Carga do banco de dados: mede o nível de atividade no seu banco de dados. A métrica chave do Performance Insights é `DBLoad`, que é coletada a cada segundo.
A unidade da métrica `DBLoad` no Insights de Performance é a média de sessões ativas (AAS). Para obter a média de sessões ativas, o Performance Insights obtém uma amostra do número de sessões que executam simultaneamente uma consulta. A AAS é o número total de sessões, dividido pelo número total de amostras por um determinado período. Para obter mais informações sobre `DBLoad` e AAS, consulte [Carga de banco de dados](USER_PerfInsights.Overview.ActiveSessions.md).
+ CPU máxima: a potência computacional máxima disponível para seu banco de dados. Para ver se as sessões ativas estão excedendo o máximo de CPU, observe sua relação com a linha `Max vCPU`. O valor de `Max vCPU` é determinado pelo número de núcleos de vCPU (CPUs virtuais) da instância de banco de dados. Para obter mais informações sobre `Max vCPU`, consulte [Máximo de CPU](USER_PerfInsights.Overview.MaxCPU.md).
Além disso, você pode "dividir" a métrica `DBLoad` em *dimensões*, que são subcategorias da métrica. As dimensões mais úteis são as seguintes:
+ Principais instâncias: mostra a carga relativa do banco de dados para suas instâncias (fragmentos e roteadores) em ordem decrescente.
+ Eventos de espera: fazem com que instruções SQL aguardem que eventos específicos aconteçam antes que possam continuar a execução. Eventos de espera indicam onde o trabalho está impedido.
+ Principal SQL: mostra quais consultas contribuem mais para a carga do banco de dados.
Para ter mais informações sobre o Insights de Performance, consulte [Dimensões](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions).
A figura a seguir mostra a dimensão **Principais instâncias** para um grupo de fragmentos de banco de dados.
![\[Dimensão Principais instâncias para um grupo de fragmentos de banco de dados.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
**Topics**
+ [Analisar a carga do banco de dados do Aurora PostgreSQL Limitless Database usando o painel do Insights de Performance](USER_PerfInsights.AnalyzeLimitlessTables.md)
# Analisar a carga do banco de dados do Aurora PostgreSQL Limitless Database usando o painel do Insights de Performance
Com o Insights de Performance, é possível monitorar métricas no nível do grupo de fragmentos e no nível da instância para o Aurora PostgreSQL Limitless Database. Ao analisar a carga de banco de dados do Aurora PostgreSQL Limitless Database, talvez você queira comparar a carga de banco de dados de cada fragmento e roteador com a vCPU máxima.
**nota**
O Aurora PostgreSQL Limitless Database sempre tem o Insights de Performance e o Monitoramento aprimorado habilitados. O período mínimo de retenção dos dados do Insights de Performance para o Limitless Database é de 31 dias (1 mês).
A visualização **Absoluto** mostra o número da Média de sessões ativas (AAS) e a vCPU estimada. A visualização **Relativo** mostra a proporção de AAS em relação à vCPU estimada.
**Topics**
+ [Analisar a carga relativa de banco de dados do Aurora PostgreSQL Limitless Database usando o painel do Insights de Performance](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad)
+ [Análise da carga do banco de dados por esperas no Aurora PostgreSQL Limitless Database usando o painel do Insights de Performance](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md)
+ [Analisar a distribuição de carga do Aurora PostgreSQL Limitless Database usando o painel do Insights de Performance](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md)
## Analisar a carga relativa de banco de dados do Aurora PostgreSQL Limitless Database usando o painel do Insights de Performance
Talvez você queira melhorar o desempenho do Aurora PostgreSQL Limitless Database monitorando a carga relativa de banco de dados. Para analisar a carga relativa de banco de dados por instância do Aurora PostgreSQL Limitless Database, use o procedimento a seguir.
**Como analisar a carga relativa de banco de dados do Aurora PostgreSQL Limitless Database usando o console**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Performance Insights**.
1. Escolha um Aurora PostgreSQL Limitless Database. O painel do Insights de Performance será exibido para esse Aurora PostgreSQL Limitless Database.
1. Na seção **Carga do banco de dados (carga do BC)**, escolha **Instâncias** em **Fatiado por**. Para ver a proporção entre a Média de sessões ativas (AAS) e os núcleos de vCPU de todas as instâncias no Aurora PostgreSQL Limitless Database, escolha **Relativo** em **Visto como**.
O gráfico Média de sessões ativas (AAS) mostra a carga do banco de dados para instâncias no Aurora PostgreSQL Limitless Database.
![\[Veja o painel do Insights de Performance para o Aurora PostgreSQL Limitless Database dividido por instâncias.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png)
1. Para ver as principais instâncias, escolha a guia **Principais instâncias**.
No exemplo a seguir, a instância com a carga do banco de dados mais alta é `DTR-2-2`.
![\[Use a guia Principais instâncias para um Aurora PostgreSQL Limitless Database dividido por instâncias.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
1. (Opcional) Para analisar a carga de banco de dados de uma instância no Aurora PostgreSQL Limitless Database, escolha o nome da instância na coluna **Instâncias**. Para visualizar a carga de banco de dados de `DTR-2-2`, escolha `DTR-2-2` na coluna **Instâncias**.
**nota**
Você pode visualizar as métricas do Insights de Performance somente para instâncias no Aurora PostgreSQL Limitless Database.
# Análise da carga do banco de dados por esperas no Aurora PostgreSQL Limitless Database usando o painel do Insights de Performance
Talvez você queira melhorar o desempenho do Aurora PostgreSQL Limitless Database monitorando eventos de espera. Para analisar a carga do banco de dados por eventos de espera do Aurora PostgreSQL Limitless Database, use o procedimento a seguir.
**Como analisar a carga do banco de dados por esperas do Aurora PostgreSQL Limitless Database usando o console**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Performance Insights**.
1. Escolha um Aurora PostgreSQL Limitless Database. O painel do Insights de Performance será exibido para esse Aurora PostgreSQL Limitless Database.
1. Na seção **Carga do banco de dados (carga do BC)**, escolha **Esperas** em **Fatiado por**. Para visualizar o número de AAS e a vCPU estimada, escolha **Absoluto** para **Visualizado como**.
O gráfico Média de sessões ativas (AAS) mostra a carga do banco de dados para instâncias no Aurora PostgreSQL Limitless Database.
![\[Dividido por esperas.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png)
1. Role para baixo até a guia **Top SQL ** (SQL principal).
No exemplo a seguir, a instrução SQL com a maior carga por esperas é a instrução `DELETE`.
![\[Guia SQL principal quando segmentada por esperas.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png)
1. Escolha a instrução SQL para expandi-la nas instruções de componente.
No exemplo a seguir, a instrução `SELECT` tem 3 instruções de componente.
![\[Escolha uma instrução SQL para expandi-la.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql-selected.png)
# Analisar a distribuição de carga do Aurora PostgreSQL Limitless Database usando o painel do Insights de Performance
Talvez você queira equilibrar a distribuição de carga das instâncias no Aurora PostgreSQL Limitless Database. Para analisar a distribuição de carga das instâncias no Aurora PostgreSQL Limitless Database, use o procedimento a seguir.
**Como analisar a distribuição de carga das instâncias no Aurora PostgreSQL Limitless Database usando o console**
1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. No painel de navegação, escolha **Performance Insights**.
1. Escolha um Aurora PostgreSQL Limitless Database. O painel do Insights de Performance será exibido para esse Aurora PostgreSQL Limitless Database.
1. Na seção **Carga do banco de dados (carga do BC)**, escolha **Instâncias** em **Fatiado por**. Para visualizar o número de AAS e a vCPU estimada para todas as instâncias no Aurora PostgreSQL Limitless Database, escolha **Absoluto** em **Visto como**.
O gráfico Média de sessões ativas (AAS) mostra a carga do banco de dados para instâncias no Aurora PostgreSQL Limitless Database.
![\[Veja o painel absoluto do Insights de Performance para o Aurora PostgreSQL Limitless Database dividido por instâncias.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png)
1. Para ver um gráfico da distribuição de carga das instâncias no Aurora PostgreSQL Limitless Database, escolha a guia **Distribuição de carga**.
No exemplo a seguir, a instância com a carga do banco de dados mais alta é `DTR-2-2`.
![\[Guia SQL superior quando você divide por esperas no nível da instância.\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png)
# Monitoramento do Aurora PostgreSQL Limitless Database com o Amazon GuardDuty RDS Protection
O Amazon GuardDuty é um serviço de detecção de ameaças que ajuda a proteger contas, contêineres, workloads e dados no ambiente da AWS. Usando modelos de machine learning (ML) e recursos de detecção de anomalias e ameaças, o GuardDuty monitora continuamente diferentes fontes de log e atividades de runtime para identificar e priorizar possíveis riscos de segurança e atividades maliciosas no seu ambiente.
O GuardDuty RDS Protection analisa e traça o perfil de eventos de login em busca de possíveis ameaças de acesso aos seus bancos de dados Amazon Aurora. Quando você ativa o RDS Protection, o GuardDuty consome eventos de login do RDS de seus bancos de dados Aurora. O RDS Protection monitora esses eventos e traça o perfil de possíveis ameaças internas ou agentes externos.
Para obter mais informações sobre o GuardDuty RDS Protection no Aurora, consulte [Monitorar ameaças com o Amazon GuardDuty RDS Protection para Amazon Aurora](guard-duty-rds-protection.md).
Para ter mais informações sobre como habilitar a Proteção do GuardDuty RDS, consulte [Proteção do GuardDuty RDS](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html) no *Guia do usuário do Amazon GuardDuty*.
# Funções e visualizações do Aurora PostgreSQL Limitless Database
O Aurora PostgreSQL Limitless Database adicionou funções e visualizações. Elas são baseadas nas funções e visualizações correspondentes do Aurora PostgreSQL.
**nota**
Algumas estatísticas podem retornar resultados inconsistentes se houver transações em andamento.
**Topics**
+ [Funções do Aurora PostgreSQL Limitless Database](limitless-monitoring-functions.md)
+ [Visualizações do Aurora PostgreSQL Limitless Database](limitless-monitoring-views.md)
# Funções do Aurora PostgreSQL Limitless Database
A tabela a seguir mostra as novas funções do Aurora PostgreSQL Limitless Database.
**nota**
As funções listadas nesta tabela estão localizadas no esquema `rds_aurora`. Ao usar uma função do Limitless Database, inclua o nome do objeto totalmente qualificado: `rds_aurora`.`object_name`.
| Função do Aurora PostgreSQL Limitless Database | Função correspondente do Aurora PostgreSQL |
| --- | --- |
| [limitless\$1backend\$1dsid](#limitless_backend_dsid) | pg\$1backend\$1pid |
| [limitless\$1cancel\$1session](#limitless_cancel_session) | pg\$1cancel\$1backend |
| [limitless\$1stat\$1clear\$1snapshot](#limitless_stat_clear_snapshot) | pg\$1stat\$1clear\$1snapshot |
| [limitless\$1stat\$1database\$1size](#limitless_stat_database_size) | pg\$1database\$1size |
| [limitless\$1stat\$1get\$1snapshot\$1timestamp](#limitless_stat_get_snapshot_timestamp) | pg\$1stat\$1get\$1snapshot\$1timestamp |
| [limitless\$1stat\$1prepared\$1xacts](#limitless_stat_prepared_xacts) | pg\$1prepared\$1xacts |
| [limitless\$1stat\$1relation\$1sizes](#limitless_stat_relation_sizes) | pg\$1indexes\$1size, pg\$1relation\$1size, pg\$1table\$1size, pg\$1total\$1relation\$1size |
| [limitless\$1stat\$1reset](#limitless_stat_reset) | pg\$1stat\$1reset |
| [limitless\$1stat\$1statements\$1reset](#limitless_stat_statements_reset) | pg\$1stat\$1statements\$1reset |
| [limitless\$1stat\$1system\$1waits](#limitless_stat_system_waits) | aurora\$1stat\$1system\$1waits |
| [limitless\$1terminate\$1session](#limitless_terminate_session) | pg\$1terminate\$1backend |
| [limitless\$1wait\$1report](#limitless_wait_report) | aurora\$1wait\$1report |
Os exemplos a seguir fornecem detalhes sobre as funções do Aurora PostgreSQL Limitless Database. Para obter mais informações sobre funções do PostgreSQL, consulte [Functions and operators](https://www.postgresql.org/docs/15/functions.html) na documentação do PostgreSQL.
**limitless\$1backend\$1dsid**
A função `limitless_backend_dsid` retorna o ID da sessão distribuída para a sessão atual. Uma sessão distribuída é executada em um roteador em um grupo de fragmentos de banco de dados e envolve processos de backend em um ou mais fragmentos no grupo de fragmentos de banco de dados.
O exemplo a seguir mostra como usar a função `limitless_backend_dsid`.
```
SELECT rds_aurora.limitless_backend_dsid();
limitless_backend_dsid
------------------------
8CACD7B04D0FC2A5
(1 row)
```
**limitless\$1cancel\$1session**
A função `limitless_cancel_session` funciona de forma semelhante a `pg_cancel_backend`, mas tenta cancelar todos os processos de backend relacionados ao ID de sessão distribuído fornecido enviando um `SIGINT` (sinal de interrupção).
O parâmetro de entrada é o seguinte:
+ `distributed_session_id` (texto): o ID da sessão distribuída a ser cancelada.
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `pid` (texto): o ID do processo de backend.
+ `success` (booleano): se o cancelamento foi bem-sucedido.
O exemplo a seguir mostra como usar a função `limitless_cancel_session`.
```
SELECT * FROM rds_aurora.limitless_cancel_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1stat\$1clear\$1snapshot**
A função `limitless_stat_clear_snapshot` descarta o snapshot das estatísticas atuais ou as informações em cache em todos os nós.
O exemplo a seguir mostra como usar a função `limitless_stat_clear_snapshot`.
```
SELECT rds_aurora.limitless_stat_clear_snapshot();
```
**limitless\$1stat\$1database\$1size**
A função `limitless_stat_database_size` retorna os tamanhos de um banco de dados no grupo de fragmentos de banco de dados.
O parâmetro de entrada é o seguinte:
+ `dbname` (nome): o banco de dados para o qual obter os tamanhos.
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `subcluster_type` (texto): o tipo de subcluster ao qual esse processo pertence: `router` ou `shard`.
+ `db_size`: o tamanho do banco de dados nesse subcluster em bytes.
O exemplo a seguir mostra como usar a função `limitless_stat_database_size`.
```
SELECT * FROM rds_aurora.limitless_stat_database_size('postgres_limitless');
subcluster_id | subcluster_type | db_size
---------------+-----------------+----------
1 | router | 8895919
2 | router | 8904111
3 | shard | 21929391
4 | shard | 21913007
5 | shard | 21831087
(5 rows)
```
**limitless\$1stat\$1get\$1snapshot\$1timestamp**
A função `limitless_stat_get_snapshot_timestamp` retorna a data e hora do snapshot de estatísticas atual ou `NULL` se nenhum instantâneo de estatísticas foi obtido. Um snapshot é obtido na primeira vez que as estatísticas cumulativas são acessadas em uma transação, se `stats_fetch_consistency` estiver definido como `snapshot`. Retorna uma visão consolidada dos registros de data e hora dos snapshots de todos os nós. As colunas `subcluster_id` e `subcluster_type` mostram de qual nó os dados são provenientes.
O exemplo a seguir mostra como usar a função `limitless_stat_get_snapshot_timestamp`.
```
SELECT * FROM rds_aurora.limitless_stat_get_snapshot_timestamp();
subcluster_id | subcluster_type | snapshot_timestamp
---------------+-----------------+--------------------
1 | router |
2 | router |
3 | shard |
4 | shard |
5 | shard |
(5 rows)
```
**limitless\$1stat\$1prepared\$1xacts**
A função `limitless_stat_prepared_xacts` retorna informações sobre transações em todos os nós que estão atualmente preparados para a confirmação em duas fases. Para obter mais informações, consulte [pg\$1prepared\$1xacts](https://www.postgresql.org/docs/current/view-pg-prepared-xacts.html) na documentação do PostgreSQL.
O exemplo a seguir mostra como usar a função `limitless_stat_prepared_xacts`.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_prepared_xacts;
subcluster_id | subcluster_type | transaction_id | gid | prepared | owner_id | database_id
---------------+-----------------+----------------+------------------------------+-------------------------------+------------+--------------------
8 | shard | 5815978 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659603+00 | auroraperf | postgres_limitless
12 | shard | 4599138 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659637+00 | auroraperf | postgres_limitless
(2 rows)
```
**limitless\$1stat\$1relation\$1sizes**
A função `limitless_stat_relation_sizes` retorna os diferentes tamanhos de uma tabela no grupo de fragmentos de banco de dados.
Os parâmetros de entrada são os seguintes:
+ `relnspname` (nome): o nome do esquema que contém a tabela.
+ `relname` (nome): o nome da tabela.
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `subcluster_type` (texto): o tipo de subcluster ao qual esse processo pertence: `router` ou `shard`.
+ `main_size`: o tamanho em bytes da bifurcação de dados principal nesse nó.
+ `fsm_size`: o tamanho em bytes do mapa de espaço livre da tabela nesse nó.
+ `vm_size`: o tamanho em bytes do mapa de visibilidade da tabela nesse nó.
+ `init_size`: o tamanho em bytes da inicialização da tabela nesse nó.
+ `toast_size`: o tamanho em bytes da tabela toast associada à tabela nessa bifurcação.
+ `index_size`: o tamanho em bytes de todos os índices da tabela nesse nó.
+ `total_size`: o tamanho em bytes de todos os segmentos da tabela nesse nó.
O exemplo a seguir mostra como usar a função `limitless_stat_relation_sizes` (algumas colunas são omitidas).
```
SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customers');
subcluster_id | subcluster_type | main_size | fsm_size | vm_size | toast_size | table_size | total_size
---------------+-----------------+-----------+----------+---------+------------+------------+------------
1 | router | 0 | 0 | 0 | 0 | 0 | 0
2 | router | 0 | 0 | 0 | 0 | 0 | 0
3 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928
4 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928
5 | shard | 3981312 | 4227072 | 1409024 | 1409024 | 11026432 | 11026432
(5 rows)
```
**limitless\$1stat\$1reset**
A função `limitless_stat_reset` redefine todos os contadores de estatísticas do banco de dados atual para zero (0). Se `track_functions` estiver habilitado, a coluna `stats_reset` em `limitless_stat_database` mostrará a última vez em que as estatísticas foram redefinidas para o banco de dados. Por padrão, `limitless_stat_reset` pode ser executado apenas por um superusuário. Outros usuários podem receber permissão usando o privilégio `EXECUTE`.
O exemplo a seguir mostra como usar a função `limitless_stat_reset`.
```
SELECT tup_inserted, tup_deleted FROM pg_stat_database
WHERE datname = 'postgres_limitless';
tup_inserted | tup_deleted
--------------+-------------
896 | 0
(1 row)
SELECT rds_aurora.limitless_stat_reset();
limitless_stat_reset
---------------------
(1 row)
SELECT tup_inserted, tup_deleted FROM pg_stat_database
WHERE datname = 'postgres_limitless';
tup_inserted | tup_deleted
-------------+-------------
0 | 0
(1 row)
```
**limitless\$1stat\$1statements\$1reset**
A função `limitless_stat_statements_reset` descarta as estatísticas coletadas até o momento por `limitless_stat_statements` correspondentes aos parâmetros `username`, `dbname`, `distributed_query_id` e `queryid` especificados. Se algum dos parâmetros não for especificado, o valor padrão `""` ou `0` (inválido) será usado para cada um deles e as estatísticas que corresponderem a outros parâmetros serão redefinidas. Se nenhum parâmetro for especificado, ou se todos os parâmetros especificados forem `""` ou `0` (inválidos), a função descartará todas as estatísticas. Se todas as estatísticas na visualização `limitless_stat_statements` forem descartadas, a função também redefinirá as estatísticas na visualização `limitless_stat_statements_info`.
Os parâmetros de entrada são os seguintes:
+ `username` (nome): o usuário que consultou a instrução.
+ `dbname` (nome): o banco de dados onde a consulta foi executada.
+ `distributed_query_id` (bigint): o ID da consulta principal do nó coordenador. Essa coluna é `NULL` se for a consulta principal. O nó coordenador envia o ID da consulta distribuída para os nós participantes. Portanto, para os nós participantes, os valores para o ID de consulta distribuída e o ID de consulta são diferentes.
+ `queryid` (bigint): o ID de consulta da instrução.
O exemplo a seguir mostra como usar a função `limitless_stat_statements_reset` para redefinir todas as estatísticas coletadas pelo `limitless_stat_statements`.
```
SELECT rds_aurora.limitless_stat_statements_reset();
```
**limitless\$1stat\$1system\$1waits**
A função `limitless_stat_system_waits` retorna uma visão consolidada dos dados do evento de espera de `aurora_stat_system_waits`, que relata a atividade de espera em todo o sistema em uma instância, de todos os nós. As colunas `subcluster_id` e `subcluster_type` mostram de qual nó os dados são provenientes.
O exemplo a seguir mostra como usar a função `limitless_stat_system_waits`.
```
postgres_limitless=> SELECT *
FROM rds_aurora.limitless_stat_system_waits() lssw, pg_catalog.aurora_stat_wait_event() aswe
WHERE lssw.event_id=aswe.event_id and aswe.event_name='LimitlessTaskScheduler';
subcluster_id | subcluster_type | type_id | event_id | waits | wait_time | event_name
---------------+-----------------+---------+-----------+--------+--------------+------------------------
1 | router | 12 | 201326607 | 677068 | 616942216307 | LimitlessTaskScheduler
2 | router | 12 | 201326607 | 678586 | 616939897111 | LimitlessTaskScheduler
3 | shard | 12 | 201326607 | 756640 | 616965545172 | LimitlessTaskScheduler
4 | shard | 12 | 201326607 | 755184 | 616958057620 | LimitlessTaskScheduler
5 | shard | 12 | 201326607 | 757522 | 616963183539 | LimitlessTaskScheduler
(5 rows)
```
**limitless\$1terminate\$1session**
A função `limitless_terminate_session` funciona de forma semelhante a `pg_terminate_backend`, mas tenta encerrar todos os processos de backend relacionados ao ID de sessão distribuído fornecido enviando um `SIGTERM` (sinal de término).
O parâmetro de entrada é o seguinte:
+ `distributed_session_id` (texto): o ID da sessão distribuída a ser encerrada.
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `pid` (texto): o ID do processo de backend.
+ `success` (booleano): se o processo foi encerrado com sucesso.
O exemplo a seguir mostra como usar a função `limitless_terminate_session`.
```
SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1wait\$1report**
A função `limitless_wait_report` retorna a atividade de eventos de espera por um período de todos os nós. As colunas `subcluster_id` e `subcluster_type` mostram de qual nó os dados são provenientes.
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `subcluster_type` (texto): o tipo de subcluster ao qual esse processo pertence: `router` ou `shard`.
As demais colunas são as mesmas que em `aurora_wait_report`.
O exemplo a seguir mostra como usar a função `limitless_wait_report`.
```
postgres_limitless=> select * from rds_aurora.limitless_wait_report();
subcluster_id | subcluster_type | type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
---------------+-----------------+-----------+------------+-------+-----------+-------------+--------------- +-------------
1 | router | Client | ClientRead | 57 | 741550.14 | 13009.652 | 0.19 | 2505.237
5 | shard | Client | ClientRead | 54 | 738897.68 | 13683.290 | 0.18 | 2496.276
4 | shard | Client | ClientRead | 54 | 738859.53 | 13682.584 | 0.18 | 2496.147
2 | router | Client | ClientRead | 53 | 719223.64 | 13570.257 | 0.18 | 2429.810
3 | shard | Client | ClientRead | 54 | 461720.40 | 8550.378 | 0.18 | 1559.86
```
# Visualizações do Aurora PostgreSQL Limitless Database
A tabela a seguir mostra as novas visualizações do Aurora PostgreSQL Limitless Database.
**nota**
As visualizações listadas nessa tabela estão localizadas no esquema `rds_aurora`. Ao usar uma visualização do Limitless Database, inclua o nome do objeto totalmente qualificado: `rds_aurora`.`object_name`.
| Visualização do Aurora PostgreSQL Limitless Database | Visualização correspondente do Aurora PostgreSQL |
| --- | --- |
| [limitless\$1database](#limitless_database) | pg\$1database |
| [limitless\$1locks](#limitless_locks) | pg\$1locks |
| [limitless\$1stat\$1activity](#limitless_stat_activity) | pg\$1stat\$1activity |
| [limitless\$1stat\$1all\$1indexes](#limitless_stat_all_indexes) | pg\$1stat\$1all\$1indexes |
| [limitless\$1stat\$1all\$1tables](#limitless_stat_all_tables) | pg\$1stat\$1all\$1tables |
| [limitless\$1stat\$1database](#limitless_stat_database) | pg\$1stat\$1database |
| [limitless\$1stat\$1progress\$1vacuum](#limitless_stat_progress_vacuum) | pg\$1stat\$1progress\$1vacuum |
| [limitless\$1stat\$1statements](#limitless_stat_statements) | pg\$1stat\$1statements |
| [limitless\$1stat\$1subclusters](#limitless_stat_subclusters) | Nenhum |
| [limitless\$1stat\$1statements\$1info](#limitless_stat_statements_info) | pg\$1stat\$1statements\$1info |
| [limitless\$1statio\$1all\$1indexes](#limitless_statio_all_indexes) | pg\$1statio\$1all\$1indexes |
| [limitless\$1statio\$1all\$1tables](#limitless_statio_all_tables) | pg\$1statio\$1all\$1tables |
| [limitless\$1tables](#limitless_tables) | pg\$1tables |
| [limitless\$1table\$1collocations](#limitless_table_collocations) | Nenhum |
| [limitless\$1table\$1collocation\$1distributions](#limitless_table_collocation_distributions) | Nenhum |
Os exemplos a seguir fornecem detalhes sobre as visualizações do Aurora PostgreSQL Limitless Database. Para obter mais informações sobre visualizações do PostgreSQL, consulte [Viewing statistics](https://www.postgresql.org/docs/15/monitoring-stats.html#MONITORING-STATS-VIEWS) na documentação do PostgreSQL.
**nota**
Algumas visualizações de estatísticas podem retornar resultados inconsistentes se você tiver transações em andamento.
**limitless\$1database**
Essa visualização contém informações sobre os bancos de dados disponíveis no grupo de fragmentos de banco de dados. Por exemplo:
```
postgres_limitless=> SELECT subcluster_id, subcluster_type, oid, datname, datacl FROM rds_aurora.limitless_database;
subcluster_id | subcluster_type | oid | datname | datacl
---------------+-----------------+-------+--------------------+------------------------------------------------------------------------------------------------------------------------
2 | router | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
2 | router | 5 | postgres |
2 | router | 16384 | rdsadmin | {rdsadmin=CTc/rdsadmin,rds_aurora_limitless_metadata_admin=c/rdsadmin,rds_aurora_limitless_heat_mgmt_admin=c/rdsadmin}
2 | router | 16477 | postgres_limitless |
2 | router | 1 | template1 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
6 | shard | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin}
```
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster (nó)
+ `subcluster_type` (texto): o tipo de subcluster (nó), roteador ou fragmento
As demais colunas são as mesmas que em `pg_database`.
**limitless\$1locks**
Essa visualização contém uma linha por processo por nó. Ela fornece acesso às informações sobre os bloqueios mantidos pelos processos ativos no servidor do banco de dados.
**Example de criação de um bloqueio com duas transações**
Neste exemplo, executamos duas transações simultaneamente em dois roteadores.
```
# Transaction 1 (run on router 1)
BEGIN;
SET search_path = public;
SELECT * FROM customers;
INSERT INTO customers VALUES (400,'foo','bar');
# Transaction 2 (run on router 2)
BEGIN;
SET search_path = public;
ALTER TABLE customers ADD COLUMN phone VARCHAR;
```
A primeira transação é executada. As transações subsequentes precisam esperar até que a primeira transação seja concluída. Portanto, a segunda transação é bloqueada com um bloqueio. Para verificar a causa raiz disso, executamos um comando unindo `limitless_locks` com `limitless_stat_activity`.
```
# Run on router 2
SELECT distributed_session_id, state, usename, query, query_start
FROM rds_aurora.limitless_stat_activity
WHERE distributed_session_id in (
SELECT distributed_session_id
FROM rds_aurora.limitless_locks
WHERE relname = 'customers'
);
distributed_session_id | state | usename | query | query_start
------------------------+---------------------+--------------------------+---------------------------------- -------------+-------------------------------
47BDE66E9A5E8477 | idle in transaction | limitless_metadata_admin | INSERT INTO customers VALUES (400,'foo','bar'); | 2023-04-13 17:44:45.152244+00
2AD7F370202D0FA9 | active | limitless_metadata_admin | ALTER TABLE customers ADD COLUMN phone VARCHAR; | 2023-04-13 17:44:55.113388+00
47BDE66E9A5E8477 | | limitless_auth_admin | |
2AD7F370202D0FA9 | | limitless_auth_admin | |
47BDE66E9A5E8477 | | limitless_auth_admin | |
2AD7F370202D0FA9 | | limitless_auth_admin | |
(6 rows)
```
**Example de criação de um bloqueio de forma explícita**
Neste exemplo, criamos um bloqueio explicitamente e, em seguida, usamos a visualização `limitless_locks` para ver os bloqueios (algumas colunas são omitidas).
```
BEGIN;
SET search_path = public;
LOCK TABLE customers IN ACCESS SHARE MODE;
SELECT * FROM rds_aurora.limitless_locks WHERE relname = 'customers';
subcluster_id | subcluster_type | distributed_session_id | locktype | datname | relnspname | relname | virtualtransaction | pid | mode
---------------+-----------------+------------------------+----------+--------------------+------------+ ----------+--------------------+-------+-----------------
1 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600787 | 59564 | AccessShareLock
2 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600405 | 67130 | AccessShareLock
3 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 15/473401 | 27735 | AccessShareLock
4 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473524 | 27734 | AccessShareLock
5 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/472935 | 27737 | AccessShareLock
6 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473015 | 48660 | AccessShareLock
(6 rows)
```
**limitless\$1stat\$1activity**
Essa visualização contém uma linha por processo por nó. Ela pode ser usada para monitorar a integridade geral do sistema e triar processos que estão demorando muito. Por exemplo:
```
postgres=# SELECT
subcluster_id,
subcluster_type,
distributed_session_id,
distributed_session_state,
datname,
distributed_query_id,
is_sso_query
FROM
rds_aurora.limitless_stat_activity
WHERE
distributed_session_id in ('D2470C97E3D07E06', '5A3CD7B8E5FD13FF')
order by distributed_session_id;
subcluster_id | subcluster_type | distributed_session_id | distributed_session_state | datname | distributed_query_id | is_sso_query
---------------+-----------------+------------------------+---------------------------+--------------------+----------------------+--------------
2 | router | 5A3CD7B8E5FD13FF | coordinator | postgres_limitless | | f
3 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 |
4 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 |
2 | router | D2470C97E3D07E06 | coordinator | postgres_limitless | | t
3 | shard | D2470C97E3D07E06 | participant | postgres_limitless | 4058400544464210222 |
(5 rows)
```
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `subcluster_type` (texto): o tipo de subcluster ao qual esse processo pertence: `router` ou `shard`.
+ `distributed_session_id` (texto): o ID da sessão distribuída à qual esse processo pertence.
+ `distributed_session_state` (texto): se este é um coordenador, participante ou processo autônomo/não distribuído (mostrado como `NULL`).
+ `datname` (texto): o banco de dados ao qual esse processo está conectado.
+ `distributed_query_id` (bigint): o ID da consulta principal do nó coordenador. Essa coluna é `NULL` se for a consulta principal. O nó coordenador envia o ID da consulta distribuída para os nós participantes. Portanto, para os nós participantes, os valores para o ID de consulta distribuída e o ID de consulta são diferentes.
+ `is_sso_query` (texto) — isso nos permite saber se a consulta está otimizada para um único fragmento ou não.
As demais colunas são as mesmas que em `pg_stat_activity`.
**limitless\$1stat\$1all\$1indexes**
Essa visualização contém estatísticas de uso em índices no grupo de fragmentos de banco de dados. Por exemplo:
```
postgres_limitless=> SELECT schemaname, relname, indexrelname, idx_scan
FROM rds_aurora.limitless_stat_all_indexes
WHERE relname LIKE 'orders_ts%' ORDER BY indexrelname LIMIT 10;
schemaname | relname | indexrelname | idx_scan
------------+----------------+---------------------+----------
ec_sample | orders_ts00001 | orders_ts00001_pkey | 196801
ec_sample | orders_ts00002 | orders_ts00002_pkey | 196703
ec_sample | orders_ts00003 | orders_ts00003_pkey | 196376
ec_sample | orders_ts00004 | orders_ts00004_pkey | 197966
ec_sample | orders_ts00005 | orders_ts00005_pkey | 195301
ec_sample | orders_ts00006 | orders_ts00006_pkey | 195673
ec_sample | orders_ts00007 | orders_ts00007_pkey | 194475
ec_sample | orders_ts00008 | orders_ts00008_pkey | 191694
ec_sample | orders_ts00009 | orders_ts00009_pkey | 193744
ec_sample | orders_ts00010 | orders_ts00010_pkey | 195421
(10 rows)
```
**limitless\$1stat\$1all\$1tables**
Essa visualização contém estatísticas sobre todas as tabelas no banco de dados atual no grupo de fragmentos de banco de dados. Isso é útil ao rastrear operações de limpeza e operações de Linguagem de Manipulação de Dados (DML). Por exemplo:
```
postgres_limitless=> SELECT subcluster_id, subcluster_type, relname, n_ins_since_vacuum, n_tup_ins, last_vacuum
FROM rds_aurora.limitless_stat_all_tables
WHERE relname LIKE 'orders_ts%' ORDER BY relname LIMIT 10;
subcluster_id | subcluster_type | relname | n_ins_since_vacuum | n_tup_ins | last_vacuum
---------------+-----------------+----------------+--------------------+-----------+-------------
5 | shard | orders_ts00001 | 34779 | 196083 |
5 | shard | orders_ts00002 | 34632 | 194721 |
5 | shard | orders_ts00003 | 34950 | 195965 |
5 | shard | orders_ts00004 | 34745 | 197283 |
5 | shard | orders_ts00005 | 34879 | 195754 |
5 | shard | orders_ts00006 | 34340 | 194605 |
5 | shard | orders_ts00007 | 33779 | 192203 |
5 | shard | orders_ts00008 | 33826 | 191293 |
5 | shard | orders_ts00009 | 34660 | 194117 |
5 | shard | orders_ts00010 | 34569 | 195560 |
(10 rows)
```
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `subcluster_type` (texto): o tipo de subcluster ao qual esse processo pertence: `router` ou `shard`.
+ `relname` (nome): o nome da tabela.
As demais colunas são as mesmas que em `pg_stat_all_tables`.
**limitless\$1stat\$1database**
Essa visualização contém estatísticas sobre todos os bancos de dados no grupo de fragmentos de banco de dados. Retorna uma linha por banco de dados por nó. Por exemplo:
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
datname,
blks_read,
blks_hit
FROM
rds_aurora.limitless_stat_database
WHERE
datname='postgres_limitless';
subcluster_id | subcluster_type | datname | blks_read | blks_hit
---------------+-----------------+--------------------+-----------+----------
1 | router | postgres_limitless | 484 | 34371314
2 | router | postgres_limitless | 673 | 33859317
3 | shard | postgres_limitless | 1299 | 17749550
4 | shard | postgres_limitless | 1094 | 17492849
5 | shard | postgres_limitless | 1036 | 17485098
6 | shard | postgres_limitless | 1040 | 17437257
(6 rows)
```
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `subcluster_type` (texto): o tipo de subcluster ao qual esse processo pertence: `router` ou `shard`.
+ `datname` (nome): o nome do banco de dados.
As demais colunas são as mesmas que em `pg_stat_database`.
**limitless\$1stat\$1progress\$1vacuum**
Essa visualização contém informações sobre as operações de limpeza em andamento. Por exemplo:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_progress_vacuum;
-[ RECORD 1 ]----------+------------------
subcluster_id | 3
subcluster_type | shard
distributed_session_id | A56D96E2A5C9F426
pid | 5270
datname | postgres
nspname | public
relname | customer_ts2
phase | vacuuming heap
heap_blks_total | 130500
heap_blks_scanned | 100036
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 11184810
num_dead_tuples | 0
-[ RECORD 2 ]----------+------------------
subcluster_id | 3
subcluster_type | shard
distributed_session_id | 56DF26A89EC23AB5
pid | 6854
datname | postgres
nspname | public
relname | sales_ts1
phase | vacuuming heap
heap_blks_total | 43058
heap_blks_scanned | 24868
heap_blks_vacuumed | 0
index_vacuum_count | 0
max_dead_tuples | 8569523
num_dead_tuples | 0
```
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `subcluster_type` (texto): o tipo de subcluster ao qual esse processo pertence: `router` ou `shard`.
+ `distributed_session_id` (texto): o identificador da sessão que iniciou a operação de limpeza.
+ `datname` (nome): o banco de dados em que a limpeza está sendo feita.
+ `nspname` (nome): o nome do esquema da tabela que está sendo limpa. É `null` se a tabela que está sendo limpa não estiver no mesmo banco de dados ao qual o usuário está conectado.
+ `relname` (nome): o nome da tabela que está sendo limpa. É `null` se a tabela que está sendo limpa não estiver no mesmo banco de dados ao qual o usuário está conectado.
As demais colunas são as mesmas que em `pg_stat_progress_vacuum`.
**limitless\$1stat\$1statements**
Essa visualização fornece um meio de rastrear o planejamento e a execução de estatísticas de todas as instruções SQL executadas em todos os nós.
É necessário instalar a extensão [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) para usar a visualização `limitless_stat_statements`.
```
-- CREATE EXTENSION must be run by a superuser
CREATE EXTENSION pg_stat_statements;
-- Verify that the extension is created on all nodes in the DB shard group
SELECT distinct node_id
FROM rds_aurora.limitless_stat_statements
LIMIT 10;
```
O exemplo a seguir mostra o uso da visualização `limitless_stat_statements`.
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
distributedqueryid,
username,
dbname,
sso_calls
FROM
rds_aurora.limitless_stat_statements;
subcluster_id | subcluster_type | distributedqueryid | username | dbname | sso_calls
---------------+-----------------+----------------------+-------------------------------------+--------------------+-----------
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 0
2 | router | | postgres | postgres_limitless | 1
3 | shard | -7975178695405682176 | postgres | postgres_limitless |
[...]
```
Os parâmetros de saída são os seguintes:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
+ `subcluster_type` (texto): o tipo de subcluster ao qual esse processo pertence: `router` para ou `shard`.
+ `distributedqueryid` (bigint): o ID da consulta principal do nó coordenador. Essa coluna é `NULL` se for a consulta principal. O nó coordenador envia o ID da consulta distribuída para os nós participantes. Portanto, para os nós participantes, os valores para o ID de consulta distribuída e o ID de consulta são diferentes.
+ `username` (nome): o usuário que consultou a instrução.
+ `dbname` (nome): o banco de dados onde a consulta foi executada.
+ `sso_calls` (nome) — o número de vezes que a instrução foi otimizada para um único fragmento.
As demais colunas são as mesmas que em [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html).
**limitless\$1stat\$1statements\$1info**
Essa visualização contém estatísticas para a visualização `limitless_stat_statements`. Cada linha contém dados para a visualização [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7) de cada nó. A coluna `subcluster_id` identifica cada nó.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_statements_info;
subcluster_id | subcluster_type | dealloc | stats_reset
---------------+-----------------+---------+-------------------------------
1 | router | 0 | 2023-06-30 21:22:09.524781+00
2 | router | 0 | 2023-06-30 21:21:40.834111+00
3 | shard | 0 | 2023-06-30 21:22:10.709942+00
4 | shard | 0 | 2023-06-30 21:22:10.740179+00
5 | shard | 0 | 2023-06-30 21:22:10.774282+00
6 | shard | 0 | 2023-06-30 21:22:10.808267+00
(6 rows)
```
O parâmetro de saída é o seguinte:
+ `subcluster_id` (texto): o ID do subcluster ao qual esse processo pertence.
As demais colunas são as mesmas que em [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7).
**limitless\$1stat\$1subclusters**
Essa visualização contém estatísticas de rede entre roteadores e outros nós. Ela contém uma linha por par de roteador e outro nó, por exemplo:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_subclusters;
orig_subcluster | orig_instance_az | dest_subcluster | dest_instance_az | latency_us | latest_collection | failed_requests | received_bytes | sent_bytes | same_az_requests | cross_az_requests | stat_reset_timestamp
-----------------+------------------+-----------------+------------------+------------+-------------------------------+-----------------+----------------+------------+------------------+-------------------+-------------------------------
3 | us-west-2b | 2 | us-west-2a | 847 | 2024-10-07 17:25:39.518617+00 | 0 | 35668633 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.239675+00
3 | us-west-2b | 4 | us-west-2b | 419 | 2024-10-07 17:25:39.546376+00 | 0 | 101190464 | 248795719 | 883478 | 0 | 2024-10-05 12:39:55.231218+00
3 | us-west-2b | 5 | us-west-2c | 1396 | 2024-10-07 17:25:39.52122+00 | 0 | 72864849 | 172086292 | 0 | 557726 | 2024-10-05 12:39:55.196412+00
3 | us-west-2b | 6 | us-west-2c | 729 | 2024-10-07 17:25:39.54828+00 | 0 | 35668584 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.247334+00
3 | us-west-2b | 7 | us-west-2a | 1702 | 2024-10-07 17:25:39.545307+00 | 0 | 71699576 | 171634844 | 0 | 556278 | 2024-10-05 12:39:52.715168+00
2 | us-west-2a | 3 | us-west-2b | 868 | 2024-10-07 17:25:40.293927+00 | 0 | 35659611 | 92011872 | 0 | 302817 | 2024-10-05 12:39:54.420758+00
2 | us-west-2a | 4 | us-west-2b | 786 | 2024-10-07 17:25:40.296863+00 | 0 | 102437253 | 251838024 | 0 | 895060 | 2024-10-05 12:39:54.404081+00
2 | us-west-2a | 5 | us-west-2c | 1232 | 2024-10-07 17:25:40.292021+00 | 0 | 71990027 | 168828110 | 0 | 545453 | 2024-10-05 12:39:36.769549+00
```
Os parâmetros de saída são os seguintes:
+ `orig_subcluster` (texto): o ID do roteador de onde as comunicações se originam
+ `orig_subcluster_az` (texto): a zona de disponibilidade (AZ) do roteador de origem
+ `dest_subcluster` (texto): o ID do nó de destino
+ `dest_subcluster_az` (texto): a última AZ coletada do nó de destino
+ `latency_us` (bigint): a última latência de rede coletada entre os nós, em microssegundos. O valor é `0` se o nó estiver inacessível.
+ `latest_collection` (data e hora): a data e hora da coleta mais recente de AZ e latência para o nó de destino
+ `failed_requests` (bigint): a contagem cumulativa de solicitações internas com falha
+ `received_bytes` (bigint): o número cumulativo estimado de bytes recebidos desse nó
+ `sent_bytes` (bigint): o número cumulativo estimado de bytes enviados para esse nó
+ `same_az_requests` (bigint): o número cumulativo de solicitações internas de banco de dados para esse nó quando ele está na mesma AZ do roteador de origem
+ `cross_az_requests` (bigint): o número cumulativo de solicitações internas de banco de dados para esse nó quando ele está em uma AZ diferente do roteador de origem
+ `stat_reset_timestamp` (data e hora): a data e hora de quando as estatísticas cumulativas dessa visualização foram redefinidas pela última vez
**limitless\$1statio\$1all\$1indexes**
Essa visualização contém estatísticas de entrada/saída (E/S) de todos os índices do grupo de fragmentos de banco de dados. Por exemplo:
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_statio_all_indexes WHERE relname like'customers_ts%';
subcluster_id | subcluster_type | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit
---------------+-----------------+------------+-------------------+-------------------------------------+ --------------+--------------
3 | shard | public | customers_ts00002 | customers_ts00002_customer_name_idx | 1 | 0
3 | shard | public | customers_ts00001 | customers_ts00001_customer_name_idx | 1 | 0
4 | shard | public | customers_ts00003 | customers_ts00003_customer_name_idx | 1 | 0
4 | shard | public | customers_ts00004 | customers_ts00004_customer_name_idx | 1 | 0
5 | shard | public | customers_ts00005 | customers_ts00005_customer_name_idx | 1 | 0
5 | shard | public | customers_ts00006 | customers_ts00006_customer_name_idx | 1 | 0
6 | shard | public | customers_ts00007 | customers_ts00007_customer_name_idx | 1 | 0
6 | shard | public | customers_ts00008 | customers_ts00008_customer_name_idx | 1 | 0
(8 rows)
```
**limitless\$1statio\$1all\$1tables**
Essa visualização contém estatísticas de entrada/saída (E/S) de todas as tabelas do grupo de fragmentos de banco de dados. Por exemplo:
```
postgres_limitless=> SELECT
subcluster_id,
subcluster_type,
schemaname,
relname,
heap_blks_read,
heap_blks_hit
FROM
rds_aurora.limitless_statio_all_tables
WHERE
relname LIKE 'customers_ts%';
subcluster_id | subcluster_type | schemaname | relname | heap_blks_read | heap_blks_hit
---------------+-----------------+------------+-------------------+----------------+---------------
3 | shard | public | customers_ts00002 | 305 | 57780
3 | shard | public | customers_ts00001 | 300 | 56972
4 | shard | public | customers_ts00004 | 302 | 57291
4 | shard | public | customers_ts00003 | 302 | 57178
5 | shard | public | customers_ts00006 | 300 | 56932
5 | shard | public | customers_ts00005 | 302 | 57386
6 | shard | public | customers_ts00008 | 300 | 56881
6 | shard | public | customers_ts00007 | 304 | 57635
(8 rows)
```
**limitless\$1tables**
Essa visualização contém informações sobre tabelas no Aurora PostgreSQL Limitless Database.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables;
table_gid | local_oid | schema_name | table_name | table_status | table_type | distribution_key
-----------+-----------+-------------+-------------+--------------+-------------+------------------
5 | 18635 | public | placeholder | active | placeholder |
6 | 18641 | public | ref | active | reference |
7 | 18797 | public | orders | active | sharded | HASH (order_id)
2 | 18579 | public | customer | active | sharded | HASH (cust_id)
(4 rows)
```
**limitless\$1table\$1collocations**
Essa visualização contém informações sobre tabelas fragmentadas colocalizadas.
No exemplo a seguir, as tabelas `orders` e `customers` são colocalizadas, e as tabelas `users` e `followers` são colocalizadas. As tabelas colocalizadas têm o mesmo `collocation_id`.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocations ORDER BY collocation_id;
collocation_id | schema_name | table_name
----------------+-------------+------------
2 | public | orders
2 | public | customers
5 | public | users
5 | public | followers
(4 rows)
```
**limitless\$1table\$1collocation\$1distributions**
Essa visualização mostra a distribuição de chaves para cada colocação.
```
postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocation_distributions ORDER BY collocation_id, lower_bound;
collocation_id | subcluster_id | lower_bound | upper_bound
----------------+---------------+----------------------+----------------------
2 | 6 | -9223372036854775808 | -4611686018427387904
2 | 5 | -4611686018427387904 | 0
2 | 4 | 0 | 4611686018427387904
2 | 3 | 4611686018427387904 | 9223372036854775807
5 | 6 | -9223372036854775808 | -4611686018427387904
5 | 5 | -4611686018427387904 | 0
5 | 4 | 0 | 4611686018427387904
5 | 3 | 4611686018427387904 | 9223372036854775807
(8 rows)
```
# Eventos de espera do Aurora PostgreSQL Limitless Database
Um evento de espera no Aurora PostgreSQL indica um recurso pelo qual uma sessão está aguardando, como entrada/saída (E/S) e bloqueios. Os eventos de espera são úteis para descobrir por que as sessões estão aguardando recursos e identificar gargalos. Para ter mais informações, consulte [Eventos de espera do Aurora PostgreSQL](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.waits).
O Aurora PostgreSQL Limitless Database tem seus próprios eventos de espera relacionados a roteadores e fragmentos. Muitos deles são para roteadores que aguardam fragmentos para concluir tarefas. Os eventos de espera de fragmento contêm detalhes sobre as tarefas que estão sendo realizadas.
**Topics**
+ [Consulta de eventos de espera](#limitless-monitoring-waits.query)
+ [Eventos de espera do Limitless Database](limitless-waits-reference.md)
## Consulta de eventos de espera
Você pode usar a visualização [limitless\$1stat\$1activity](limitless-monitoring-views.md#limitless_stat_activity) para consultar eventos de espera, conforme mostrado no exemplo a seguir.
```
SELECT wait_event FROM rds_aurora.limitless_stat_activity WHERE wait_event_type='AuroraLimitless';
wait_event
----------------------
RemoteStatementSetup
RemoteStatementSetup
(2 rows)
```
Você também pode usar a função `aurora_stat_system_waits` para listar o número de esperas e o tempo total gasto em cada evento de espera, conforme mostrado no exemplo a seguir.
```
postgres_limitless=> 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()
WHERE type_name='AuroraLimitless'
ORDER BY wait_time DESC;
type_name | event_name | waits | wait_time
-----------------+---------------------------+---------+-------------
AuroraLimitless | RemoteStatementSetup | 7518 | 75236507897
AuroraLimitless | RemoteStatementExecution | 40 | 132986
AuroraLimitless | Connect | 5 | 1453
(3 rows)
```
# Eventos de espera do Limitless Database
Os eventos de espera a seguir se aplicam ao Aurora PostgreSQL Limitless Database. Você pode monitorar esses eventos de espera para identificar gargalos no processamento do Aurora PostgreSQL Limitless Database.
**Topics**
+ [Evento de espera IO:TwophaseFilePoolWrite](#limitless-waits-TwophaseFilePoolWrite)
+ [Evento de espera IO:TwophaseFilePoolRead](#limitless-waits-TwophaseFilePoolRead)
+ [Evento de espera AuroraLimitless](#limitless-waits-Connect)
+ [Evento de espera AuroraLimitless:AsyncConnect](#limitless-waits-AsyncConnect)
+ [Evento de espera AuroraLimitless:RemoteStatementSetup](#limitless-waits-RemoteStatementSetup)
+ [Evento de espera AuroraLimitless:RemoteDDLExecution](#limitless-waits-RemoteDDLExecution)
+ [Evento de espera AuroraLimitless:RemoteStatementExecution](#limitless-waits-RemoteStatementExecution)
+ [Evento de espera AuroraLimitless:FetchRemoteResults](#limitless-waits-FetchRemoteResults)
+ [Evento de espera AuroraLimitless:AsyncGetInitialResponse](#limitless-waits-AsyncGetInitialResponse)
+ [Evento de espera AuroraLimitless:AsyncGetNextResponse](#limitless-waits-AsyncGetNextResponse)
+ [Evento de espera AuroraLimitless:AbortedCommandCleanup](#limitless-waits-AbortedCommandCleanup)
+ [Evento de espera AuroraLimitless:DistributedCommitPrepare](#limitless-waits-DistributedCommitPrepare)
+ [Evento de espera AuroraLimitless:DistributedCommit](#limitless-waits-DistributedCommit)
+ [Evento de espera AuroraLimitless:DistributedCommitPrepareThrottle](#limitless-waits-DistributedCommitPrepareThrottle)
+ [Evento de espera AuroraLimitless:PreparedTransactionResolution](#limitless-waits-PreparedTransactionResolution)
+ [Evento de espera AuroraLimitless:SendPreparedTransactionOutcome](#limitless-waits-SendPreparedTransactionOutcome)
+ [Evento de espera AuroraLimitless:CommitClockBarrier](#limitless-waits-CommitClockBarrier)
+ [Evento de espera AuroraLimitless:SnapshotClockBarrier](#limitless-waits-SnapshotClockBarrier)
+ [Evento de espera AuroraLimitless:ReaderSnapshotClockBarrier](#limitless-waits-ReaderSnapshotClockBarrier)
+ [Evento de espera AuroraLimitless:GatherDistributedDeadlockGraph](#limitless-waits-GatherDistributedDeadlockGraph)
+ [Evento de espera AuroraLimitless:DistributedDeadlockDetection](#limitless-waits-DistributedDeadlockDetection)
+ [Evento de espera AuroraLimitless:DistributedDeadlockAbort](#limitless-waits-DistributedDeadlockAbort)
+ [Evento de espera AuroraLimitless:GatherRemoteStats](#limitless-waits-GatherRemoteStats)
+ [Evento de espera AuroraLimitless:GlobalSequenceRefresh](#limitless-waits-GlobalSequenceRefresh)
+ [Evento de espera AuroraLimitless:GlobalVacuumTimeExchange](#limitless-waits-GlobalVacuumTimeExchange)
+ [Evento de espera AuroraLimitless:DistributedTransactionMonitorGather](#limitless-waits-DistributedTransactionMonitorGather)
+ [Evento de espera AuroraLimitlessActivity:AdminTaskSchedulerMain](#limitless-waits-AdminTaskSchedulerMain)
+ [Evento de espera AuroraLimitlessActivity:AdminTaskExecutorMain](#limitless-waits-AdminTaskExecutorMain)
+ [Evento de espera AuroraLimitlessActivity:AdminTaskMonitorMain](#limitless-waits-AdminTaskMonitorMain)
+ [Evento de espera AuroraLimitlessActivity:DatabaseCleanupMonitorMain](#limitless-waits-DatabaseCleanupMonitorMain)
+ [Evento de espera AuroraLimitlessActivity:TopologyCleanupMonitorMain](#limitless-waits-TopologyCleanupMonitorMain)
+ [Evento de espera AuroraLimitlessActivity:ToplogyChangeMonitorMain](#limitless-waits-ToplogyChangeMonitorMain)
+ [Evento de espera AuroraLimitlessActivity:DistributedTransactionMonitorMain](#limitless-waits-DistributedTransactionMonitorMain)
+ [Evento de espera AuroraLimitlessActivity:GlobalVacuumMonitorMain](#limitless-waits-GlobalVacuumMonitorMain)
## Evento de espera IO:TwophaseFilePoolWrite
Esperar por uma gravação de um arquivo de estado de duas fases dentro do grupo de arquivos de estado de duas fases. Este é um evento específico do Aurora.
### Causas
Os processos que executam um comando `PREPARED TRANSACTION`, incluindo participantes em uma transação distribuída do Limitless Database, devem persistir o estado da transação em um arquivo de duas fases. O Aurora usa um grupo de arquivos para melhorar o desempenho dessa operação.
### Ação
Essa é uma operação de E/S de gravação síncrona e, portanto, uma alta latência nesse evento tem causas semelhantes a `IO:XactSync` e pode ser investigada da mesma forma. Se estiver usando o Limitless Database, talvez seja necessário reduzir o número de transações distribuídas em execução.
## Evento de espera IO:TwophaseFilePoolRead
Esperar pela leitura de um arquivo de estado de duas fases dentro do grupo de arquivos de estado de duas fases.
### Causas
Os processos que executam um comando `COMMIT PREPARED` em uma transação previamente preparada, incluindo participantes de uma transação distribuída do Limitless Database, talvez precisem ler o estado da transação anteriormente persistido em um arquivo de duas fases. O Aurora usa um grupo de arquivos para melhorar o desempenho dessa operação.
### Ação
Esta é uma operação de E/S de leitura. Portanto, uma alta latência nesse evento tem causas semelhantes às de `IO:DataFileRead` e pode ser investigada da mesma forma. Se estiver usando o Limitless Database, talvez seja necessário reduzir o número de transações distribuídas em execução.
## Evento de espera AuroraLimitless
O processo está esperando o estabelecimento de uma conexão com outro nó no cluster.
### Causas
As conexões são estabelecidas entre processos e nós remotos para executar consultas, transações distribuídas e realizar DDLs.
### Ação
Reduza o número de conexões simultâneas ao cluster ou ajuste o uso de consultas entre fragmentos.
## Evento de espera AuroraLimitless:AsyncConnect
Esse evento é semelhante a `Connect`, mas representa um processo que espera o estabelecimento de conexões paralelas com um conjunto de nós.
### Causas
O estabelecimento de conexão paralela é mais comumente feito ao executar instruções DDL.
### Ação
Reduza o número de instruções DDL ou combine várias DDLs na mesma sessão para melhorar a reutilização da conexão.
## Evento de espera AuroraLimitless:RemoteStatementSetup
O processo está esperando a configuração da execução da consulta remota, como abertura, fechamento do cursor ou criação de uma instrução preparada.
### Causas
Esse evento de espera aumenta com o número de varreduras em tabelas fragmentadas em que a instrução não pôde ser otimizada para um único fragmento.
### Ação
Otimize as consultas para reduzir o número de operações de varredura ou aumentar a elegibilidade para a otimização de um único fragmento.
## Evento de espera AuroraLimitless:RemoteDDLExecution
O processo está esperando a conclusão de um comando DDL remoto.
### Causas
Ao emitir um comando DDL em um grupo de fragmentos de banco de dados, ele deve ser distribuído para outros roteadores e nós de fragmento antes de confirmar a operação. Algumas operações de DDL podem ser executadas por um longo período, porque os dados devem ser adaptados às alterações do esquema.
### Ação
Identifique comandos DDL de longa duração para poder otimizá-los.
## Evento de espera AuroraLimitless:RemoteStatementExecution
Um processo está esperando a conclusão de um comando remoto.
### Causas
Um comando SQL está sendo executado em um nó remoto. Esse evento aparecerá com frequência em comunicações internas, como verificações de `auto_analyze` e de pulsação.
### Ação
Identifique comandos de longa execução usando a exibição limitless\$1stat\$1statements. Em muitos casos, esse é um evento esperado, principalmente em processos em segundo plano ou processos internos, e nenhuma ação é necessária.
## Evento de espera AuroraLimitless:FetchRemoteResults
Um processo está esperando para recuperar linhas de um nó remoto.
### Causas
Esse evento de espera pode aumentar ao buscar muitas linhas de uma tabela remota, como uma tabela fragmentada ou de referência.
### Ação
Identifique consultas `SELECT` não otimizadas usando a exibição `limitless_stat_statements`. Otimize as consultas para recuperar somente os dados necessários. Também é possível ajustar o parâmetro `rds_aurora.limitless_maximum_adaptive_fetch_size`.
## Evento de espera AuroraLimitless:AsyncGetInitialResponse
O processo está esperando uma resposta inicial quando o modo pipeline é usado na execução da consulta.
### Causas
Isso normalmente será observado durante a execução do roteador para o fragmento em consultas com posicionamento de dados em um único fragmento e é uma parte esperada da execução normal.
### Ação
Nenhuma outra ação é necessária.
## Evento de espera AuroraLimitless:AsyncGetNextResponse
O processo está esperando respostas adicionais quando o modo pipeline é usado na execução da consulta.
### Causas
Isso normalmente será observado durante a execução do roteador para o fragmento em consultas com posicionamento de dados em um único fragmento e é uma parte esperada da execução normal.
### Ação
Nenhuma outra ação é necessária.
## Evento de espera AuroraLimitless:AbortedCommandCleanup
O processo está esperando o resultado de uma consulta de limpeza remota. As consultas de limpeza são emitidas para os nós de fragmento para retorná-los ao estado apropriado quando uma transação distribuída é encerrada.
### Causas
A limpeza de transação é feita quando uma transação é abortada porque um erro foi encontrado ou porque um usuário emitiu um comando ABORT explícito ou cancelou a consulta em execução.
### Ação
Investigue a causa do cancelamento da transação.
## Evento de espera AuroraLimitless:DistributedCommitPrepare
O processo está confirmando uma transação distribuída e esperando que todos os participantes reconheçam o comando de preparo.
### Causas
As transações que modificam vários nós devem realizar uma confirmação distribuída. Uma longa espera em `DistributedCommitPrepare` pode ser causada por longas esperas no evento `IO:TwophaseFilePoolWrite` nos nós participantes.
### Ação
Reduza o número de transações que modificam dados em vários nós. Investigue eventos `IO:TwophaseFilePoolWrite` em outros nós do cluster.
## Evento de espera AuroraLimitless:DistributedCommit
O processo está confirmando uma transação distribuída e esperando que o participante principal reconheça o comando de confirmação.
### Causas
As transações que modificam vários nós devem realizar uma confirmação distribuída. Uma longa espera em `DistributedCommit` pode ser causada por longas esperas no evento `IO:XactSync` no participante principal.
### Ação
Reduza o número de transações que modificam dados em vários nós. Investigue eventos `IO:XactSync` em outros nós do cluster.
## Evento de espera AuroraLimitless:DistributedCommitPrepareThrottle
O processo está tentando preparar uma transação distribuída e está com controle de utilização devido às transações preparadas existentes.
### Causas
As transações que modificam vários nós devem realizar uma confirmação distribuída. Os participantes dessas transações devem realizar uma operação de preparação como parte do protocolo de confirmação. O Aurora limita o número de preparações simultâneas. Se esse limite for excedido, o processo aguardará no evento `DistributedCommitPrepareThrottle`.
### Ação
Reduza o número de transações que modificam dados em vários nós. Investigue os eventos `IO:TwophaseFilePoolWrite`, pois o aumento do tempo nesses eventos pode fazer com que as transações preparadas existentes se acumulem, resultando em controle de utilização de novas tentativas de preparação.
## Evento de espera AuroraLimitless:PreparedTransactionResolution
O processo encontrou uma tupla modificada por uma transação distribuída que está no estado de preparo. O processo deve determinar se a transação distribuída ficará visível no snapshot.
### Causas
As transações que modificam vários nós devem realizar uma confirmação distribuída que inclui uma fase de preparo. Um alto número de transações distribuídas ou o aumento da latência em confirmações distribuídas podem fazer com que outros processos encontrem o evento de espera `PreparedTransactionResolution`.
### Ação
Reduza o número de transações que modificam dados em vários nós. Investigue eventos relacionados a confirmações distribuídas, pois o aumento do tempo nesses eventos pode aumentar a latência no caminho de confirmação das transações distribuídas. Também investigue as cargas da rede e da CPU.
## Evento de espera AuroraLimitless:SendPreparedTransactionOutcome
O processo está sendo executado em um nó que está coordenando uma transação distribuída e outro processo perguntou sobre o estado dessa transação, ou o processo confirmou uma transação distribuída e está enviando o resultado aos participantes.
### Causas
Os processos que encontrarem o evento de espera `PreparedTransactionResolution` consultarão o coordenador da transação. A resposta no coordenador da transação encontrará SendPreparedTransactionOutcome.
### Ação
Reduza o número de transações que modificam dados em vários nós. Investigue eventos relacionados à confirmação distribuída e eventos `IO:TwophaseFilePoolWrite` e `IO:TwophaseFilePoolRead`, pois esses eventos podem aumentar a latência no caminho de confirmação das transações distribuídas. Também investigue as cargas da rede e da CPU.
## Evento de espera AuroraLimitless:CommitClockBarrier
O processo está confirmando uma transação e deve esperar para garantir que o tempo de confirmação atribuído seja garantidamente passado para todos os nós do cluster.
### Causas
A saturação da CPU ou da rede pode causar um aumento no desvio do relógio, resultando no tempo gasto nesse evento de espera.
### Ação
Investigue a saturação da CPU ou da rede no cluster.
## Evento de espera AuroraLimitless:SnapshotClockBarrier
O processo recebeu um horário de snapshot de outro nó com um relógio no futuro e está esperando que seu próprio relógio atinja esse horário.
### Causas
Isso geralmente ocorre depois que o processo recebe resultados de uma função que foi enviada para um fragmento e há um desvio de relógio entre os nós. A saturação da CPU ou da rede pode causar um aumento no desvio do relógio, resultando no tempo gasto nesse evento de espera.
### Ação
Investigue a saturação da CPU ou da rede no cluster.
## Evento de espera AuroraLimitless:ReaderSnapshotClockBarrier
Esse evento ocorre nos nós de leitura. O processo está esperando que o nó de leitura reproduza o fluxo de gravação para que todas as gravações que ocorreram antes do horário do snapshot do processo sejam aplicadas.
### Causas
Um aumento no atraso da réplica do Aurora pode causar um aumento no tempo de espera nesse evento.
### Ação
Investigue o atraso da réplica do Aurora.
## Evento de espera AuroraLimitless:GatherDistributedDeadlockGraph
O processo está se comunicando com outros nós para coletar gráficos de bloqueio como parte da detecção de impasse distribuído.
### Causas
Quando um processo está esperando um bloqueio, ele executa uma verificação de impasse distribuído após esperar mais de `rds_aurora.limitless_distributed_deadlock_timeout`.
### Ação
Investigue as causas da contenção de bloqueios na aplicação e considere ajustar o `rds_aurora.limitless_distributed_deadlock_timeout`.
## Evento de espera AuroraLimitless:DistributedDeadlockDetection
O processo está se comunicando com outros nós para detectar um impasse distribuído.
### Causas
Quando um processo está esperando um bloqueio, ele executa uma verificação de impasse distribuído após esperar mais de `rds_aurora.limitless_distributed_deadlock_timeout`.
### Ação
Investigue as causas da contenção de bloqueios na aplicação e considere ajustar o `rds_aurora.limitless_distributed_deadlock_timeout`.
## Evento de espera AuroraLimitless:DistributedDeadlockAbort
O processo está se comunicando com outro nó para abortar uma sessão escolhida como vítima em um impasse distribuído.
### Causas
Os padrões de aplicações estão resultando em impasses distribuídos.
### Ação
Investigue os padrões de aplicações que resultam em impasses distribuídos.
## Evento de espera AuroraLimitless:GatherRemoteStats
O processo está coletando estatísticas de outros nós no cluster.
### Causas
As consultas e visualizações de monitoramento ou atividade, como `limitless_stat_activity`, recuperarão estatísticas de outros nós.
### Ação
Nenhuma outra ação é necessária.
## Evento de espera AuroraLimitless:GlobalSequenceRefresh
O processo está gerando um novo valor de sequência e deve solicitar uma nova parte da sequência global.
### Causas
Uma alta taxa de geração de valor de sequência pode resultar em paralisações nesse evento se `rds_aurora.limitless_sequence_chunk_size` for insuficiente.
### Ação
Essa é uma ocorrência normal. Se você observar um tempo excessivo nesse evento, considere ajustar o `rds_aurora.limitless_sequence_chunk_size`. Consulte a documentação sobre sequências no Limitless Database.
## Evento de espera AuroraLimitless:GlobalVacuumTimeExchange
O processo está trocando dados de snapshot para oferecer suporte à limpeza.
### Causas
Os nós no Limitless Database trocam dados de horário do snapshot ativo mais antigo com outros nós para calcular o tempo de corte correto para a execução da limpeza.
### Ação
Nenhuma outra ação é necessária.
## Evento de espera AuroraLimitless:DistributedTransactionMonitorGather
O processo está reunindo metadados de transações de outros nós para oferecer suporte à limpeza de transações distribuídas.
### Causas
Os nós no Limitless Database trocam metadados de transações com outros nós para determinar quando o estado de transação distribuída pode ser eliminado.
### Ação
Nenhuma outra ação é necessária.
## Evento de espera AuroraLimitlessActivity:AdminTaskSchedulerMain
Esperando no loop principal do processo de agendamento de tarefas.
## Evento de espera AuroraLimitlessActivity:AdminTaskExecutorMain
Esperando no loop principal do processo do executor de tarefas.
## Evento de espera AuroraLimitlessActivity:AdminTaskMonitorMain
Esperando no loop principal do processo de monitoramento de tarefas.
## Evento de espera AuroraLimitlessActivity:DatabaseCleanupMonitorMain
Esperando no loop principal do processo de monitoramento de limpeza do banco de dados.
## Evento de espera AuroraLimitlessActivity:TopologyCleanupMonitorMain
Esperando no loop principal do processo de monitoramento de limpeza de topologia.
## Evento de espera AuroraLimitlessActivity:ToplogyChangeMonitorMain
Esperando no loop principal do processo de monitoramento de alterações de topologia.
## Evento de espera AuroraLimitlessActivity:DistributedTransactionMonitorMain
Esperando no loop principal do processo de monitoramento de transações distribuídas.
## Evento de espera AuroraLimitlessActivity:GlobalVacuumMonitorMain
Esperando no loop principal do processo de monitoramento de limpeza global.
# Usar funções para aumentar a eficiência
Por padrão, as funções definidas pelo usuário não são otimizadas para um único fragmento, mas podem ser configuradas para serem executadas como operações de fragmento único. As funções podem encapsular a lógica e garantir que ela seja executada de maneira otimizada para um único fragmento.
## Por que as operações de fragmento único são importantes
A utilização de recursos é importante para o desempenho e o custo-benefício. As operações de fragmento único usam significativamente menos recursos em comparação com as operações entre fragmentos. Por exemplo, ao executar uma função para inserir 1 milhão de linhas, a execução de um único fragmento usa aproximadamente 90,5 ACUs, enquanto a execução entre fragmentos usa 126,5 ACUs, uma melhoria de 35% na eficiência dos recursos.
A execução de um único fragmento também oferece:
+ Throughput 35% mais alto que as operações entre fragmentos.
+ Tempos de resposta mais previsíveis.
+ Melhor escalabilidade à medida que os dados crescem.
## Operações e funções de fragmento único
As funções são executadas em fragmentos quando um destes pré-requisitos é atendido:
+ A função é criada como imutável e incluída em uma consulta otimizada para um único fragmento.
+ A função é distribuída por um usuário.
As funções executadas em fragmentos têm melhor desempenho e escalam melhor porque são executadas onde os dados estão localizados.
## Funções e volatilidade
Para verificar a volatilidade de uma função, use esta consulta em tabelas de sistema do PostgreSQL:
```
SELECT DISTINCT nspname, proname, provolatile
FROM pg_proc PRO
JOIN pg_namespace NSP ON PRO.pronamespace = NSP.oid
WHERE proname IN ('random', 'md5');
```
Resultado do exemplo:
```
nspname | proname | provolatile
------------+---------+-------------
pg_catalog | md5 | i
pg_catalog | random | v
(2 rows)
```
Neste exemplo, `md5()` é imutável e `random()` é volátil. Isso significa que uma instrução otimizada para um único fragmento que inclua `md5()` permanece otimizada para um único fragmento, ao contrário de uma instrução que inclua `random()`.
Exemplo com função imutável:
```
EXPLAIN ANALYZE
SELECT pg_catalog.md5('123')
FROM s1.t1
WHERE col_a = 776586194
AND col_b = 654849524
AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5';
```
```
QUERY PLAN
----------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=3.409..3.409 rows=1 loops=1)
Single Shard Optimized
Planning Time: 0.313 ms
Execution Time: 4.253 ms
(4 rows)
```
Exemplo com função volátil:
```
EXPLAIN ANALYZE
SELECT pg_catalog.random()
FROM s1.t1
WHERE col_a = 776586194
AND col_b = 654849524
AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5';
```
```
QUERY PLAN
------------------------------------------------------
Foreign Scan on t1_fs00001 t1
(cost=100.00..15905.15 rows=1 width=8)
(actual time=0.658..0.658 rows=1 loops=1)
Planning Time: 0.263 ms
Execution Time: 2.892 ms
(3 rows)
```
A saída mostra que, na função `md5()`, aplica-se pushdown para executá-la como otimizada para um único fragmento, ao contrário de `random()`.
## Funções de distribuição
Uma função que acessa dados em apenas um fragmento deve ser executada nesse fragmento para obter benefícios de desempenho. A função deve ser distribuída e a assinatura da função deve incluir a chave de fragmento completa. Todas as colunas na chave de fragmento devem ser transmitidas como parâmetros à função.
Exemplos de função:
```
CREATE OR REPLACE FUNCTION s1.func1(
param_a bigint,
param_b bigint,
param_c char(100)
)
RETURNS int AS $$
DECLARE
res int;
BEGIN
SELECT COUNT(*) INTO res
FROM s1.t1
WHERE s1.t1.col_a = param_a
AND s1.t1.col_b = param_b
AND s1.t1.col_c = param_c;
RETURN res;
END
$$ LANGUAGE plpgsql;
```
Antes da distribuição, a função não é otimizada para um único fragmento:
```
EXPLAIN ANALYZE
SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5');
```
```
QUERY PLAN
------------------------------------------------------------------------------------------------------
Function Scan on func1 (cost=0.25..0.26 rows=1 width=4)
(actual time=37.503..37.503 rows=1 loops=1)
Planning Time: 0.901 ms
Execution Time: 51.647 ms
(3 rows)
```
Para distribuir a função:
```
SELECT rds_aurora.limitless_distribute_function(
's1.func1(bigint,bigint,character)',
ARRAY['param_a','param_b','param_c'],
's1.t1'
);
```
Após distribuição, a função é otimizada para um único fragmento:
```
EXPLAIN ANALYZE
SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5');
```
```
QUERY PLAN
------------------------------------------------------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=4.332..4.333 rows=1 loops=1)
Single Shard Optimized
Planning Time: 0.857 ms
Execution Time: 5.116 ms
(4 rows)
```
É possível confirmar a otimização de fragmento único verificando a coluna `sso_calls` em `rds_aurora.limitless_stat_statements`:
```
subcluster_id | subcluster_type | calls | sso_calls | query
--------------+-----------------+-------+-----------+--------------------------------------
2 | router | 2 | 1 | SELECT * FROM s1.func1( $1, $2, $3 )
3 | router | 1 | 1 | SELECT * FROM s1.func1( $1, $2, $3 )
(2 rows)
```
## Funções e padrões de eficiência
Executar a lógica próximo aos dados é mais eficiente, e as funções desempenham um papel fundamental para conseguir isso. Há dois casos de uso principais para melhorar a eficiência com funções:
1. Extrair a chave de fragmento de dados complexos para invocar uma função separada otimizada para um único fragmento
1. Transformar workloads entre fragmentos em otimizadas para um único fragmento separando a lógica entre fragmentos das instruções otimizadas para um único fragmento
### Extrair a chave de fragmento de dados complexos
Considere uma função com assinatura `s3.func3(p_json_doc json)` que executa várias operações de banco de dados. Essas operações serão executadas em todos os fragmentos em uma transação que abrange todos os fragmentos. Se o documento JSON contiver a chave de fragmento, será possível criar uma função otimizada para um único fragmento e realizar as operações do banco de dados.
Padrão original:
```
s3.func3(p_json_doc json)
database operation 1;
database operation 2;
database operation 3;
```
Padrão otimizado:
```
s3.func3(p_json_doc json)
DECLARE
v_a bigint;
BEGIN
v_a := (p_json_doc->>'field_a')::bigint;
SELECT s3.func3_INNER(v_a, p_json_doc);
END;
```
O que a função interna faz:
```
s3.func3_INNER(p_a, p_json_doc)
database operation 1 WHERE shard_key = p_a;
database operation 2 WHERE shard_key = p_a;
database operation 3 WHERE shard_key = p_a;
```
Nesse padrão, a chave de fragmento é encapsulada em um tipo de dados complexo ou pode ser deduzida de outros parâmetros. A lógica, o acesso aos dados e as funções podem determinar, extrair ou criar a chave de fragmento e, em seguida, invocar uma função otimizada para um único fragmento que execute operações relacionadas apenas a um único fragmento. Como a interface da aplicação não muda, a otimização é comparativamente fácil de testar.
### Adiar uma chave de fragmento de outras funções ou dados
Outro padrão de design se aplica quando a lógica ou o acesso aos dados calcula ou determina a chave de fragmento. Isso é útil quando uma função pode ser executada em um único fragmento para a maioria das invocações, mas ocasionalmente requeira a execução entre fragmentos.
Padrão original:
```
NEWORD(INTEGER, …) RETURNS NUMERIC
DECLARE
all_whid_local := true;
LOOP through the order lines
Generate warehouse ID;
IF generated warehouse ID == input warehouse ID
THEN
ol_supply_whid := input warehouse ID;
ELSE
all_whid_local := false;
ol_supply_whid := generated warehouse ID;
END IF;
…
END LOOP;
…
RETURN no_s_quantity;
```
Padrão otimizado com funções separadas:
```
CREATE OR REPLACE FUNCTION NEWORD_sso(no_w_id INTEGER, …)
RETURNS NUMERIC
…
RETURN no_s_quantity;
…
END;
LANGUAGE 'plpgsql';
SELECT rds_aurora.limitless_distribute_function(
'NEWORD_sso(int,…)',
ARRAY['no_w_id'],
'warehouse'
);
CREATE OR REPLACE FUNCTION NEWORD_crosshard(no_w_id INTEGER, …)
RETURNS NUMERIC
…
RETURN no_s_quantity;
…
END;
LANGUAGE 'plpgsql';
```
Em seguida, faça com que a função principal chame a versão otimizada para um único fragmento ou a versão entre fragmentos:
```
IF all_whid_local THEN
SELECT NEWORD_sso(…) INTO no_s_quantity;
ELSE
SELECT NEWORD_crosshard(…) INTO no_s_quantity;
END IF;
```
Essa abordagem permite que a maioria das invocações se beneficie da otimização de fragmento único, mantendo o comportamento correto para casos que exigem execução entre fragmentos.
## Verificar operações de fragmento único
Use `EXPLAIN` para verificar se uma instrução é otimizada para um único fragmento. A saída relata explicitamente “Single Shard Optimized” para operações otimizadas.
Invocação entre fragmentos antes da distribuição:
```
QUERY PLAN
---------------------------------------------------------------------
Function Scan on func1 (cost=0.25..0.26 rows=1 width=4)
(actual time=59.622..59.623 rows=1 loops=1)
Planning Time: 0.925 ms
Execution Time: 60.211 ms
```
Invocação de fragmento único após a distribuição:
```
QUERY PLAN
----------------------------------------------------------------------
Foreign Scan (cost=100.00..101.00 rows=100 width=0)
(actual time=4.576..4.577 rows=1 loops=1)
Single Shard Optimized
Planning Time: 1.483 ms
Execution Time: 5.404 ms
```
A diferença nos tempos de execução demonstra o benefício de desempenho da otimização de fragmento único.