Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Surveillance d’Aurora PostgreSQL Limitless Database
Vous pouvez utiliser Amazon CloudWatch, Enhanced Monitoring et Performance Insights pour surveiller la base de données Aurora PostgreSQL Limitless. De nouvelles fonctions et vues statistiques, ainsi que des événements d’attente, sont également disponibles dans Aurora PostgreSQL Limitless Database et peuvent être utilisés à des fins de surveillance et de diagnostic.
**Topics**
+ [Surveillance d’Aurora PostgreSQL Limitless Database avec Amazon CloudWatch](limitless-monitoring.cw.md)
+ [Surveillance d’Aurora PostgreSQL Limitless Database avec CloudWatch Database Insights](limitless-monitoring.cwdbi.md)
+ [Surveillance d’Aurora PostgreSQL Limitless Database avec Amazon CloudWatch Logs](limitless-monitoring.cwl.md)
+ [Surveillance d’Aurora PostgreSQL Limitless Database à l’aide d’Enhanced Monitoring](limitless-monitoring.em.md)
+ [Surveillance d’Aurora PostgreSQL Limitless Database avec Performance Insights](limitless-monitoring.pi.md)
+ [Surveillance d’Aurora PostgreSQL Limitless Database avec Amazon GuardDuty RDS Protection](limitless-monitoring.gd.md)
+ [Fonctions et vues dans Aurora PostgreSQL Limitless Database](limitless-monitoring-fns-views.md)
+ [Événements d’attente dans Aurora PostgreSQL Limitless Database](limitless-monitoring-waits.md)
+ [Construire pour l'efficacité grâce aux fonctions](limitless-performance-functions.md)
# Surveillance d’Aurora PostgreSQL Limitless Database avec Amazon CloudWatch
Les métriques CloudWatch pour Aurora PostgreSQL Limitless Database sont présentées selon les dimensions suivantes :
+ [DBShardGroup](#limitless-monitoring.cw.DBShardGroup)
+ [DBShardGroupRouterAggregation](#limitless-monitoring.cw.DBShardGroupRouterAggregate)
+ [DBShardGroupInstance](#limitless-monitoring.cw.DBShardGroupInstance)
+ [DBClusterIdentifier](#limitless-monitoring.cw.DBClusterIdentifier)
Pour plus d’informations sur les métriques CloudWatch, consultez [Surveillance des métriques (Amazon Aurora) avec Amazon CloudWatch](monitoring-cloudwatch.md).
## Métriques DBShardGroup
Pour consulter les métriques `DBShardGroup` relatives à Aurora PostgreSQL Limitless Database dans la console CloudWatch, choisissez **RDS**, puis **DBShardGroup**.
Vous pouvez suivre les métriques CloudWatch suivantes :
+ `DBShardGroupACUUtilization` : utilisation de l’unité de capacité Aurora (ACU) en pourcentage calculé à partir de la `DBShardGroupCapacity` divisée par `DBShardGroupMaxACU`.
+ `DBShardGroupCapacity` : nombre d’ACU consommées par les instances d’écriture du groupe de partitions de base de données.
+ `DBShardGroupComputeRedundancyCapacity` : nombre d’ACU consommées par les instances de secours du groupe de partitions de base de données.
+ `DBShardGroupMaxACU` ; nombre maximum d’ACU configurées pour le groupe de partitions de base de données.
+ `DBShardGroupMinACU` : nombre minimum d’ACU requis par le groupe de partitions de base de données.
La clé de dimension `DBShardGroupIdentifier` est disponible pour agréger les métriques `DBShardGroup`.
## Métriques DBShardGroupRouterAggregation
Pour consulter les métriques `DBShardGroupRouterAggregation` relatives à Aurora PostgreSQL Limitless Database dans la console CloudWatch, choisissez **RDS**, puis **DBShardGroupRouterAggregation**.
Vous pouvez suivre les métriques CloudWatch suivantes :
+ `CommitThroughput` : le nombre moyen d’opérations de validation par seconde sur tous les nœuds de routeur du groupe de partitions de base de données.
+ `DatabaseConnections` : la somme de toutes les connexions entre tous les nœuds de routeur du groupe de partitions de base de données.
## Métriques DBShardGroupInstance
Une métrique DBShardGroupInstance est l’instance de base de données individuelle au sein de chaque partition ou sous-cluster de routeur.
Pour consulter les métriques `DBShardGroupInstance` relatives à Aurora PostgreSQL Limitless Database dans la console CloudWatch, choisissez **RDS**, puis **DBShardGroupInstance**.
Vous pouvez suivre les métriques CloudWatch suivantes :
+ `ACUUtilization` : le pourcentage calculé comme la métrique `ServerlessDatabaseCapacity` divisée par le nombre maximal d’ACU attribuées au sous-cluster.
+ `AuroraReplicaLag` : pour les clusters Limitless où la redondance de calcul est activée, cette valeur indique la latence lors de la réplication des mises à jour depuis l’instance principale du sous-cluster.
+ `AuroraReplicaLagMaximum` : pour les clusters Limitless où la redondance de calcul est activée, cette valeur indique la latence maximale lors de la réplication des mises à jour depuis l’instance principale du sous-cluster. Lorsque les réplicas en lecture sont supprimés ou renommés, il peut y avoir un pic temporaire de latence de réplication, le temps que l’ancienne ressource soit recyclée. Utilisez cette métrique pour déterminer si un basculement s’est produit en raison d’une latence de réplication élevée sur l’un de ses lecteurs.
+ `AuroraReplicaLagMinimum` : pour les clusters Limitless où la redondance de calcul est activée, cette valeur indique la latence minimale lors de la réplication des mises à jour depuis l’instance principale du sous-cluster.
+ `BufferCacheHitRatio` : le pourcentage de données et d’index fournis à partir du cache mémoire d’une instance (par opposition au volume de stockage).
+ `CommitLatency` : la durée moyenne nécessaire au moteur et au stockage pour effectuer les opérations de validation pour un nœud particulier (routeur ou partition).
+ `CommitThroughput` : nombre moyen d’opérations de validation par seconde.
+ `CPUUtilization`— Utilisation de l’UC en pourcentage de la valeur d’ACU maximale attribuée au sous-cluster.
+ `FreeableMemory` : la quantité de mémoire inutilisée qui est disponible lorsque le groupe de partitions est mis à l’échelle jusqu’à sa capacité maximale. Cette valeur est déterminée par les ACU attribuées au groupe de partitions. Pour chaque ACU dont la capacité actuelle est inférieure à la capacité maximale, cette valeur augmente d’environ 2 Gio. Ainsi, cette métrique ne tend pas vers zéro tant que le groupe de partitions de base de données n’a pas été augmenté verticalement jusqu’à sa limite maximale.
+ `MaximumUsedTransactionIDs` : l’âge de l’ID de transaction non vidée le plus ancien, en transactions. Si cette valeur atteint 2 146 483 648 (2^31 - 1 000 000), la base de données est forcée à passer en mode de lecture seule afin d’éviter le bouclage des ID de transaction. Pour plus d’informations, consultez [Prévention des échecs de bouclage de l’ID de transaction](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) dans la documentation PostgreSQL.
+ `NetworkReceiveThroughput` : quantité de débit réseau reçue des clients par chaque instance du groupe de partitions de base de données. Ce débit n’inclut pas le trafic réseau entre les instances du groupe de partitions de base de données et le volume de cluster.
+ `NetworkThroughput` : le débit réseau agrégé (transmis et reçu) entre les clients et les routeurs, ainsi que les routeurs et les partitions du groupe de partitions de base de données. Ce débit n’inclut pas le trafic réseau entre les instances du groupe de partitions de base de données et le volume de cluster.
+ `NetworkTransmitThroughput` : quantité de débit réseau envoyée aux clients par chaque instance du groupe de partitions de base de données. Ce débit n’inclut pas le trafic réseau entre les instances du groupe de partitions de base de données et le volume de cluster.
+ `ReadIOPS` : le nombre moyen d’opérations d’entrée/sortie de lecture sur le disque par seconde (IOPS).
+ `ReadLatency` : le temps moyen nécessaire pour chaque opération d’entrée/sortie (E/S) de lecture sur le disque.
+ `ReadThroughput` : le nombre moyen d’octets lus sur le disque par seconde.
+ `ServerlessDatabaseCapacity` : la capacité actuelle de la partition de base de données ou du sous-cluster de routeurs au sein du groupe de partitions de base de données.
+ `StorageNetworkReceiveThroughput` : quantité de débit réseau reçue du sous-système de stockage Aurora par chaque instance du groupe de partitions de base de données.
+ `StorageNetworkThroughput` : le débit réseau agrégé à la fois transmis vers et reçu depuis le sous-système de stockage Aurora, par chaque instance du groupe de partitions de base de données.
+ `StorageNetworkTransmitThroughput` : la quantité de débit réseau envoyée au sous-système de stockage Aurora par chaque instance du groupe de partitions de base de données.
+ `SwapUsage` : la quantité d’espace d’échange utilisé par le groupe de partitions de base de données.
+ `TempStorageIOPS` : le nombre moyen d’opérations d’E/S réalisées sur le stockage local attaché à l’instance de base de données. Cette valeur prend en compte les opérations d’E/S de lecture et d’écriture.
La métrique `TempStorageIOPS` peut être utilisée avec `TempStorageThroughput` pour diagnostiquer les rares cas où l’activité du réseau pour les transferts entre vos instances de base de données et vos périphériques de stockage locaux est responsable d’augmentations de capacité inattendues.
+ `TempStorageThroughput` : le volume de données transférées depuis et vers le stockage local associé à un router ou à une partition.
+ `WriteIOPS` : le nombre moyen d’IOPS d’écriture sur le disque.
+ `WriteLatency` : le temps moyen nécessaire pour chaque opération d’entrée/sortie (E/S) d’écriture sur le disque.
+ `WriteThroughput` : le nombre moyen d’octets écrits sur le disque par seconde.
Les clés de dimension suivantes sont disponibles pour agréger les métriques `DBShardGroupInstance` :
+ `DBClusterIdentifier` : le cluster de bases de données Aurora PostgreSQL.
+ `DBShardGroupIdentifier` : le groupe de partitions de base de données auquel appartient l’instance.
+ `DBShardGroupSubClusterType` : le type de nœud, soit `Distributed Transaction Router` (routeur), soit `Data Access Shard` (partition).
+ `DBShardGroupSubClusterIdentifier` : le nom du routeur ou de la partition auxquels appartient l’instance.
Voici des exemples d’agrégation de métriques CloudWatch :
+ `CPUUtilization` totale de toutes les instances appartenant à une partition ou à un routeur donné(e) dans un groupe de partitions de base de données.
+ `CPUUtilization` totale de toutes les instances d’un groupe de partitions de base de données.
## Métriques DBClusterIdentifier
Pour consulter les métriques `DBClusterIdentifier` relatives à Aurora PostgreSQL Limitless Database dans la console CloudWatch, choisissez **RDS**, puis **DBClusterIdentifier**.
Lorsque vous utilisez Aurora PostgreSQL Limitless Database, le nombre d’opérations d’entrée/sortie (E/S) peut être supérieur à celui d’un cluster de bases de données Aurora. Vous pouvez suivre les métriques CloudWatch suivantes pour votre cluster Limitless Database :
+ `VolumeReadIops` : le nombre d’opérations d’E/S de lecture facturées depuis un volume de cluster, rapportées par intervalles de 5 minutes.
+ `VolumeWriteIops` : le nombre d’opérations d’E/S d’écriture disque sur le volume de cluster, rapportées par intervalles de 5 minutes.
Aurora PostgreSQL Limitless Database utilise la configuration de stockage en cluster. Aurora I/O-Optimized. Avec Aurora I/O-Optimized, vous payez un tarif mensuel fixe pour toutes vos opérations d’E/S, au lieu d’être facturé par million de requêtes E/S. Pour plus d’informations, consultez [Configurations de stockage pour les clusters de bases de données Amazon Aurora](Aurora.Overview.StorageReliability.md#aurora-storage-type).
Vous pouvez également bénéficier d’une capacité de stockage plus importante qu’avec un cluster de bases de données Aurora. Vous pouvez suivre les métriques CloudWatch suivantes pour le stockage :
+ `BackupRetentionPeriodStorageUsed` : l’utilisation totale de stockage de sauvegarde continue facturée pour votre cluster Aurora PostgreSQL Limitless Database.
+ `SnapshotStorageUsed` : l’utilisation totale de stockage d’instantanés facturée pour votre cluster Aurora PostgreSQL Limitless Database.
+ `TotalBackupStorageBilled` : la somme des coûts liés à la rétention des sauvegardes automatiques et aux instantanés du cluster de bases de données.
Pour plus d’informations sur les coûts de stockage des sauvegardes, consultez [Comprendre l’utilisation du stockage de sauvegarde Amazon Aurora](aurora-storage-backup.md).
+ `VolumeBytesUsed` : la quantité de stockage utilisée par votre cluster Aurora PostgreSQL Limitless Database, rapportée par intervalles de 5 minutes.
# Surveillance d’Aurora PostgreSQL Limitless Database avec CloudWatch Database Insights
Le mode standard de Database Insights est requis pour activer Aurora PostgreSQL Limitless Database. Vous pouvez l’utiliser pour surveiller la charge de base de données (DB Load) de vos instances de base de données Limitless Database en temps réel. La charge de la base de données mesure le niveau d’activité de la session de votre base de données. Vous pouvez utiliser Database Insights pour analyser et résoudre les problèmes liés aux performances de vos instances de base de données Aurora PostgreSQL Limitless Database à grande échelle.
Pour plus d’informations sur CloudWatch Database Insights, consultez les rubriques suivantes.
+ [Surveillance des bases de données Amazon Aurora à l’aide de CloudWatch Database Insights](USER_DatabaseInsights.md)
+ [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html) dans le *Guide de l’utilisateur Amazon CloudWatch*
+ [Démarrer avec CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Get-Started.html) dans le *Guide de l’utilisateur Amazon CloudWatch*
+ [Configuration de votre base de données pour surveiller les requêtes SQL lentes avec Database Insights pour Amazon Aurora](USER_DatabaseInsights.SlowSQL.md)
Pour en savoir plus sur l’activation du mode Avancé ou du mode Standard de Database Insights, consultez les rubriques suivantes.
**Topics**
+ [Activation du mode Avancé de Database Insights pour Aurora PostgreSQL Limitless Database](limitless-monitoring.cwdbi.advanced.md)
+ [Activation du mode Standard de Database Insights pour Aurora PostgreSQL Limitless Database](limitless-monitoring.cwdbi.standard.md)
# Activation du mode Avancé de Database Insights pour Aurora PostgreSQL Limitless Database
Pour activer le mode Avancé de Database Insights pour Aurora PostgreSQL Limitless Database, suivez les procédures suivantes.
## Activation du mode Avancé de Database Insights lors de la création d’un cluster de bases de données pour Aurora PostgreSQL Limitless Database
Activez le mode Avancé de Database Insights lors de la création d’une base de données pour Aurora PostgreSQL Limitless Database.
------
#### [ Console ]
Dans la console, vous pouvez activer le mode Avancé de Database Insights lorsque vous créez un cluster de bases de données. Les paramètres de Database Insights s’appliquent à toutes les instances de base de données de votre cluster de bases de données.
**Pour activer le mode Avancé de Database Insights lors de la création d’un cluster de bases de données à l’aide de la console**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choisissez **Bases de données**.
1. Choisissez **Create database (Créer une base de données)**.
1. Dans la section **Database Insights**, sélectionnez le **mode Avancé**. Choisissez ensuite les options suivantes :
+ **Conservation** – Durée de conservation des données de Performance Insights. La période de conservation du mode Avancé de Database Insights doit être comprise entre 15 et 24 mois.
+ **AWS KMS key** – Spécifiez votre clé KMS. Performance Insights chiffre toutes les données potentiellement sensibles à l’aide votre clé KMS. Les données sont chiffrées en transit et au repos. Pour plus d’informations, consultez [Chiffrement des ressources Amazon Aurora](Overview.Encryption.md).
1. Choisissez **Create database (Créer une base de données)**.
------
#### [ AWS CLI ]
Pour activer le mode Avancé de Database Insights lors de la création d’un cluster de bases de données, appelez la commande [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) de l’AWS CLI et fournissez les valeurs suivantes :
+ `--db-cluster-identifier` : l’identifiant du cluster de bases de données.
+ `--database-insights-mode advanced` pour activer le mode Avancé de Database Insights.
+ `--engine` : le cluster de bases de données doit utiliser le moteur de base de données `aurora-postgresql`.
+ `--engine-version` : le cluster de bases de données doit utiliser l’une des versions du moteur de base de données.
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type` : le cluster de bases de données doit utiliser la configuration de stockage du cluster de bases de données `aurora-iopt1`.
+ `--cluster-scalability-type` : spécifie le mode de capacité de mise à l’échelle du cluster de bases de données Aurora. Lorsqu’il est défini sur `limitless`, le cluster fonctionne comme une base de données Aurora PostgreSQL Limitless Database. Lorsqu’il est défini sur `standard` (valeur par défaut), le cluster utilise la création d’instance de base de données normale.
**Note**
Ce paramètre ne peut plus être modifié une fois le cluster de bases de données créé.
+ `--master-username` : le nom de l’utilisateur principal du cluster de bases de données.
+ `--master-user-password` : le mot de passe de l’utilisateur principal.
+ `--enable-performance-insights` pour activer Performance Insights pour Database Insights.
+ `--performance-insights-retention-period` : période de conservation des données de votre cluster de bases de données. Pour activer Database Insights, la période de conservation doit être d’au moins 465 jours.
+ `--monitoring-interval` : l’intervalle, en secondes, entre les points lorsque des métriques Enhanced Monitoring sont collectées pour le cluster de bases de données. Cette valeur ne peut pas être `0`.
+ `--monitoring-role-arn` : l’Amazon Resource Name (ARN) du rôle IAM qui autorise RDS à envoyer des métriques Enhanced Monitoring à Amazon CloudWatch Logs.
+ `--enable-cloudwatch-logs-exports` : vous devez exporter les journaux `postgresql` vers CloudWatch Logs.
Dans l’exemple suivant, le mode Avancé de Database Insights est activé lors de la création d’un cluster de bases de données.
Pour 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
```
Pour 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 ]
Pour activer le mode Avancé de Database Insights lors de la création d’un cluster de bases de données , définissez les paramètres suivants pour votre opération [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) de l’API Amazon RDS.
+ `DatabaseInsightsMode` sur `advanced`
+ `Engine` sur `aurora-postgresql`
+ `EngineVersion` sur une version de moteur disponible pour Limitless Database
+ `StorageType` sur `aurora-iopt1`
+ `ClusterScalabilityType` sur `limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights` sur `True`
+ `PerformanceInsightsRetentionPeriod` sur au moins `465` jours
+ `MonitoringInterval` sur une valeur qui n’est pas `0`
+ `MonitoringRoleArn` sur l’Amazon Resource Name (ARN) du rôle IAM qui autorise RDS à envoyer des métriques Enhanced Monitoring à Amazon CloudWatch Logs.
------
## Activation du mode Avancé de Database Insights lors de la modification d’un cluster de bases de données pour Aurora PostgreSQL Limitless Database
Activation de Database Insights lors de la modification d’une base de données pour Aurora PostgreSQL Limitless Database.
**Note**
Pour activer Database Insights, il est nécessaire que chaque instance de base de données d’un cluster de bases de données ait les mêmes paramètres Performance Insights et Enhanced Monitoring.
------
#### [ Console ]
Dans la console, vous pouvez activer le mode Avancé de Database Insights lorsque vous modifiez un cluster de bases de données. Les paramètres de Database Insights s’appliquent à toutes les instances de base de données de votre cluster de bases de données.
**Pour activer le mode Avancé de Database Insights lors de la modification d’un cluster de bases de données à l’aide de la console**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choisissez **Bases de données**.
1. Choisissez un cluster de bases de données, puis **Modifier**.
1. Dans la section **Database Insights**, sélectionnez le **mode Avancé**. Choisissez ensuite les options suivantes :
+ **Conservation** – Durée de conservation des données de Performance Insights. La période de conservation du mode Avancé de Database Insights doit être comprise entre 15 et 24 mois.
+ **AWS KMS key** – Spécifiez votre clé KMS. Performance Insights chiffre toutes les données potentiellement sensibles à l’aide votre clé KMS. Les données sont chiffrées en transit et au repos. Pour plus d’informations, consultez [Chiffrement des ressources Amazon Aurora](Overview.Encryption.md).
1. Choisissez **Continuer**.
1. Pour **Scheduling of Modifications (Planification des modifications)**, choisissez **Appliquer immédiatement**. Si vous choisissez **Appliquer pendant la fenêtre de maintenance planifiée suivante**, votre base de données ignore ce paramètre et active immédiatement le mode Avancé de Performance Insights.
1. Choisissez **Modifier le cluster**.
------
#### [ AWS CLI ]
Pour activer le mode Avancé de Database Insights lors de la modification d’un cluster de bases de données, appelez la commande [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) de l’AWS CLI et fournissez les valeurs suivantes :
+ `--database-insights-mode advanced` pour activer le mode Avancé de Database Insights.
+ `--db-cluster-identifier` : l’identifiant du cluster de bases de données.
+ `--enable-performance-insights` pour activer Performance Insights pour Database Insights.
+ `--performance-insights-retention-period` : période de conservation des données de votre cluster de bases de données. Pour activer le mode Avancé de Database Insights, la période de conservation doit être d’au moins 465 jours.
Dans l’exemple suivant, le mode Avancé Database Insights est activé lors de la modification d’un cluster de bases de données.
Pour 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
```
Pour 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 ]
Pour activer le mode Avancé de Database Insights lorsque vous modifiez un cluster de bases de données, renseignez les paramètres suivants pour l’opération [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) de l’API Amazon RDS.
+ `DatabaseInsightsMode` sur `advanced`
+ `EnablePerformanceInsights` sur `True`
+ `PerformanceInsightsRetentionPeriod` sur au moins `465` jours
------
# Activation du mode Standard de Database Insights pour Aurora PostgreSQL Limitless Database
Pour activer le mode Standard de Database Insights pour Aurora PostgreSQL Limitless Database, suivez les procédures suivantes.
## Activation du mode Standard de Database Insights lors de la création d’un cluster de bases de données pour Aurora PostgreSQL Limitless Database
Activez le mode Standard de Database Insights lors de la création d’une base de données pour Aurora PostgreSQL Limitless Database.
------
#### [ Console ]
Dans la console, vous pouvez activer le mode Standard de Database Insights lorsque vous créez un cluster de bases de données. Les paramètres de Database Insights s’appliquent à toutes les instances de base de données de votre cluster de bases de données.
**Pour activer le mode Standard de Database Insights lors de la création d’un cluster de bases de données à l’aide de la console**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choisissez **Bases de données**.
1. Choisissez **Create database (Créer une base de données)**.
1. Dans la section **Database Insights**, sélectionnez le **mode Standard**. Choisissez ensuite les options suivantes :
+ **Conservation** – Durée de conservation des données de Performance Insights. Vous devez définir une période de conservation d’au moins 31 jours pour pouvoir créer un cluster de bases de données Aurora PostgreSQL Limitless Database.
+ **AWS KMS key** – Spécifiez votre clé KMS. Performance Insights chiffre toutes les données potentiellement sensibles à l’aide votre clé KMS. Les données sont chiffrées en transit et au repos. Pour plus d’informations, consultez [Chiffrement des ressources Amazon Aurora](Overview.Encryption.md).
1. Choisissez **Create database (Créer une base de données)**.
------
#### [ AWS CLI ]
Pour activer le mode Standard de Database Insights lors de la création d’un cluster de bases de données, appelez la commande [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) de l’AWS CLI et fournissez les valeurs suivantes :
+ `--db-cluster-identifier` : l’identifiant du cluster de bases de données.
+ `--database-insights-mode standard` pour activer le mode Standard de Database Insights.
+ `--engine` : le cluster de bases de données doit utiliser le moteur de base de données `aurora-postgresql`.
+ `--engine-version` : le cluster de bases de données doit utiliser l’une des versions du moteur de base de données.
+ `16.4-limitless`
+ `16.6-limitless`
+ `--storage-type` : le cluster de bases de données doit utiliser la configuration de stockage du cluster de bases de données `aurora-iopt1`.
+ `--cluster-scalability-type` : spécifie le mode de capacité de mise à l’échelle du cluster de bases de données Aurora. Lorsqu’il est défini sur `limitless`, le cluster fonctionne comme une base de données Aurora PostgreSQL Limitless Database. Lorsqu’il est défini sur `standard` (valeur par défaut), le cluster utilise la création d’instance de base de données normale.
**Note**
Ce paramètre ne peut plus être modifié une fois le cluster de bases de données créé.
+ `--master-username` : le nom de l’utilisateur principal du cluster de bases de données.
+ `--master-user-password` : le mot de passe de l’utilisateur principal.
+ `--enable-performance-insights` pour activer Performance Insights pour Database Insights.
+ `--performance-insights-retention-period` : période de conservation des données de votre cluster de bases de données. Vous devez définir une période de conservation d’au moins 31 jours pour pouvoir créer un cluster de bases de données Aurora PostgreSQL Limitless Database.
+ `--monitoring-interval` : l’intervalle, en secondes, entre les points lorsque des métriques Enhanced Monitoring sont collectées pour le cluster de bases de données. Cette valeur ne peut pas être `0`.
+ `--monitoring-role-arn` : l’Amazon Resource Name (ARN) du rôle IAM qui autorise RDS à envoyer des métriques Enhanced Monitoring à Amazon CloudWatch Logs.
+ `--enable-cloudwatch-logs-exports` : vous devez exporter les journaux `postgresql` vers CloudWatch Logs.
Dans l’exemple suivant, le mode Standard de Database Insights est activé lors de la création d’un cluster de bases de données.
Pour 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
```
Pour 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 ]
Pour activer le mode Standard de Database Insights lorsque vous créez un cluster de bases de données , définissez les paramètres suivants pour votre opération [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) de l’API Amazon RDS.
+ `DatabaseInsightsMode` sur `standard`
+ `Engine` sur `aurora-postgresql`
+ `EngineVersion` vers une version de moteur disponible pour Limitless Database
+ `StorageType` sur `aurora-iopt1`
+ `ClusterScalabilityType` sur `limitless`
+ `MasterUsername`
+ `MasterUserPassword`
+ `EnablePerformanceInsights` sur `True`
+ `PerformanceInsightsRetentionPeriod` sur au moins `31` jours
+ `MonitoringInterval` à une valeur qui n’est pas `0`
+ `MonitoringRoleArn` à l’Amazon Resource Name (ARN) du rôle IAM qui autorise RDS à envoyer des métriques Enhanced Monitoring à Amazon CloudWatch Logs.
------
## Activation du mode Standard de Database Insights lors de la modification d’un cluster de bases de données pour Aurora PostgreSQL Limitless Database
Activation de Database Insights lors de la modification d’une base de données pour Aurora PostgreSQL Limitless Database.
**Note**
Pour activer Database Insights, il est nécessaire que chaque instance de base de données d’un cluster de bases de données ait les mêmes paramètres Performance Insights et Enhanced Monitoring.
------
#### [ Console ]
Dans la console, vous pouvez activer le mode Standard de Database Insights lorsque vous créez un cluster de bases de données. Les paramètres de Database Insights s’appliquent à toutes les instances de base de données de votre cluster de bases de données.
**Pour activer le mode Standard de Database Insights lors de la modification d’un cluster de bases de données à l’aide de la console**
1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choisissez **Bases de données**.
1. Choisissez un cluster de bases de données, puis **Modifier**.
1. Dans la section **Database Insights**, sélectionnez le **mode Standard**. Choisissez ensuite les options suivantes :
+ **Conservation** – Durée de conservation des données de Performance Insights. Vous devez définir une période de conservation d’au moins 31 jours pour pouvoir créer un cluster de bases de données Aurora PostgreSQL Limitless Database.
+ **AWS KMS key** – Spécifiez votre clé KMS. Performance Insights chiffre toutes les données potentiellement sensibles à l’aide votre clé KMS. Les données sont chiffrées en transit et au repos. Pour plus d’informations, consultez [Chiffrement des ressources Amazon Aurora](Overview.Encryption.md).
1. Choisissez **Continuer**.
1. Pour **Scheduling of Modifications (Planification des modifications)**, choisissez **Appliquer immédiatement**. Si vous choisissez **Appliquer lors de la prochaine fenêtre de maintenance planifiée**, votre base de données ignore ce paramètre et active immédiatement le mode Standard de Database Insights.
1. Choisissez **Modifier le cluster**.
------
#### [ AWS CLI ]
Pour activer le mode Standard de Database Insights lors de la modification d’un cluster de bases de données, appelez la commande [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) de l’AWS CLI et fournissez les valeurs suivantes :
+ `--db-cluster-identifier` : l’identifiant du cluster de bases de données.
+ `--database-insights-mode standard` pour activer le mode Standard de Database Insights.
+ `--enable-performance-insights` pour activer Performance Insights pour Database Insights.
+ `--performance-insights-retention-period` : période de conservation des données de votre cluster de bases de données. Pour activer le mode Standard de Database Insights, la période de conservation doit être d’au moins 31 jours.
Dans l’exemple suivant, le mode Standard de Database Insights est activé lors de la modification d’un cluster de bases de données.
Pour 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
```
Pour 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 ]
Pour activer le mode Standard de Database Insights lorsque vous modifiez un cluster de bases de données, fournissez les paramètres suivants pour l’opération [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) de l’API Amazon RDS.
+ `DatabaseInsightsMode` sur `standard`
+ `EnablePerformanceInsights` sur `True`
+ `PerformanceInsightsRetentionPeriod` sur au moins `31` jours
------
# Surveillance d’Aurora PostgreSQL Limitless Database avec Amazon CloudWatch Logs
L’exportation des journaux PostgreSQL vers CloudWatch Logs est requise dans le cadre de l’activation d’Aurora PostgreSQL Limitless Database. Vous pouvez accéder à ces journaux et les analyser dans CloudWatch Logs Insights, de la même manière que vous accédez aux journaux PostgreSQL d’un cluster de bases de données Aurora PostgreSQL standard. Pour plus d’informations, consultez [Analyse des journaux PostgreSQL à l’aide de CloudWatch Logs Insights](AuroraPostgreSQL.CloudWatch.Analyzing.md).
Le nom du groupe de journaux pour le cluster de bases de données est le même que dans Aurora PostgreSQL :
```
/aws/rds/cluster/DB_cluster_ID/postgresql
```
Le nom du groupe de journaux pour le groupe de partitions de base de données prend la forme suivante :
```
/aws/rds/cluster/DB_cluster_ID/DB_shard_group_ID/postgresql
```
Il existe des flux de journaux pour chaque nœud (routeur ou partition). Leurs noms présentent le format suivant :
```
[DistributedTransactionRouter|DataAccessShard]/node_cluster_serial_ID-node_instance_serial_ID/n
```
Exemples :
+ Routeur – `DistributedTransactionRouter/6-6.2`
+ Partition – `DataAccessShard/22-22.0`
**Note**
Vous ne pouvez pas afficher les fichiers journaux PostgreSQL du groupe de partitions de bases de données directement dans la console RDS, l’AWS CLI ou l’API RDS, comme c’est possible pour un cluster de bases de données. Vous devez utiliser CloudWatch Logs Insights pour les afficher.
# Surveillance d’Aurora PostgreSQL Limitless Database à l’aide d’Enhanced Monitoring
La fonctionnalité Enhanced Monitoring est requise pour activer Aurora PostgreSQL Limitless Database. Vous pouvez l’utiliser pour surveiller le système d’exploitation de vos instances de base de données Limitless Database en temps réel.
Aurora publie les métriques Enhanced Monitoring dans CloudWatch Logs. Parmi les principales métriques disponibles figurent les connexions à la base de données, l’utilisation du stockage et la latence des requêtes. Ces métriques peuvent vous aider à identifier les goulots d’étranglement au niveau des performances.
Pour plus d’informations sur les métriques de surveillance améliorée, consultez [Métriques de système d’exploitation pour Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS).
# Surveillance d’Aurora PostgreSQL Limitless Database avec Performance Insights
Utilisez Performance Insights pour surveiller votre cluster Aurora PostgreSQL Limitless Database. Performance Insights fonctionne de la même manière pour Aurora PostgreSQL Limitless Database que pour les clusters de bases de données Aurora standard. Cependant, dans Aurora PostgreSQL Limitless Database, le suivi des métriques s’effectue au niveau du groupe de partitions.
Les deux principales métriques à surveiller dans Performance Insights sont les suivantes :
+ Charge de la base de données : mesure le niveau d’activité de votre base de données. La métrique clé de Performance Insights est `DBLoad`, qui est collectée toutes les secondes.
L’unité de la métrique `DBLoad` dans Performance Insights est le nombre moyen de sessions actives (AAS). Pour obtenir les sessions actives en moyenne, Performance Insights échantillonne le nombre de sessions exécutant simultanément une requête. L’AAS correspond au nombre total de sessions divisé par le nombre total d’échantillons pour une période déterminée. Pour plus d’informations sur `DBLoad` et AAS, consultez [Charge de base de données](USER_PerfInsights.Overview.ActiveSessions.md).
+ Utilisation maximale de l’UC : la puissance de calcul maximale disponible pour votre base de données. Pour voir si les sessions actives dépassent l’utilisation maximale de l’UC, examinez leur relation sur la ligne `Max vCPU`. La valeur `Max vCPU` est déterminée par le nombre de cœurs de vCPU (UC virtuelle) pour votre instance de base de données. Pour plus d’informations sur `Max vCPU`, consultez [Utilisation maximale de l’UC](USER_PerfInsights.Overview.MaxCPU.md).
En outre, vous pouvez « découper » la métrique `DBLoad` en *dimensions*, qui représentent des sous-catégories de cette métrique. Les dimensions les plus utiles sont les suivantes :
+ Instances principales : affichent la charge de base de données relative pour vos instances (partitions et routeurs) par ordre décroissant.
+ Événement d’attente : indiquent que les requêtes SQL attendent la réalisation d’événements spécifiques avant de pouvoir s’exécuter. Les événements d’attente révèlent les endroits où l’activité est freinée.
+ Principaux éléments SQL : indiquent les requêtes qui contribuent le plus à la charge de la base de données.
Pour plus d’informations sur les dimensions de Performance Insights, consultez [Dimensions](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions).
La figure suivante montre la dimension **Instances principales** d’un groupe de partitions de base de données.
![\[Dimension des instances principales pour un groupe de partitions de base de données.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
**Topics**
+ [Analyse de la charge de la base de données pour la base de données Aurora PostgreSQL Limitless à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.AnalyzeLimitlessTables.md)
# Analyse de la charge de la base de données pour la base de données Aurora PostgreSQL Limitless à l’aide du tableau de bord de Performance Insights
Avec Performance Insights, vous pouvez suivre les métriques au niveau du groupe de partitions et au niveau de l’instance pour une base de données Aurora PostgreSQL Limitless. Lorsque vous analysez la charge de base de données pour une base de données Aurora PostgreSQL Limitless, vous pouvez si vous le souhaitez comparer la charge de base de données pour chaque partition et routeur au nombre maximal de vCPU.
**Note**
Performance Insights et Enhanced Monitoring sont toujours activés dans la base de données Aurora PostgreSQL Limitless. La période de conservation minimale des données Performance Insights pour Limitless Database est de 31 jours (1 mois).
La vue **Absolue** indique le nombre moyen de sessions actives (AAS) et le nombre estimé de vCPU. La vue **Relative** montre le rapport entre l’AAS et le vCPU estimé.
**Topics**
+ [Analyse de la charge de la base de données relative pour la base de données Aurora PostgreSQL Limitless à l’aide du tableau de bord de Performance Insights](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad)
+ [Analyse de la charge de la base de données en temps d’attente pour la base de données Aurora PostgreSQL Limitless à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md)
+ [Analyse de la répartition de la charge de la base de données Aurora PostgreSQL Limitless à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md)
## Analyse de la charge de la base de données relative pour la base de données Aurora PostgreSQL Limitless à l’aide du tableau de bord de Performance Insights
Vous pouvez si vous le souhaitez être améliorer les performances de votre base de données Aurora PostgreSQL Limitless en suivant la charge de base de données relative. Pour analyser la charge de base de données relative par instance pour votre base de données Aurora PostgreSQL Limitless, utilisez la procédure suivante.
**Pour analyser la charge de base de données relative pour la base de données Aurora PostgreSQL Limitless à l’aide de la console**
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Performance Insights**.
1. Choisissez une base de données Aurora PostgreSQL Limitless. Le tableau de bord de Performance Insights s’affiche pour cette base de données Aurora PostgreSQL Limitless.
1. Dans la section **Charge de base de données**, choisissez **Instances** pour **Divisé par**. Pour connaître le ratio entre le nombre moyen de sessions actives (AAS) et le nombre de cœurs de vCPU pour toutes les instances de votre base de données Aurora PostgreSQL Limitless, choisissez **Relative** for **Considéré comme**.
Le graphique Nombre moyen de sessions actives affiche la charge de base de données pour les instances de votre base de données d’Aurora PostgreSQL Limitless.
![\[Consultez le tableau de bord Performances Insights pour votre base de données Aurora PostgreSQL Limitless, divisé par instances.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png)
1. Pour afficher les principales instances, cliquez sur l’onglet **Les meilleures instances**.
Dans l’exemple suivant, l’instance avec la charge de base de données la plus élevée est `DTR-2-2`.
![\[Utilisez l’onglet Les meilleures instances pour une base de données Aurora PostgreSQL Limitless découpée par instances.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png)
1. (Facultatif) Pour analyser la charge de base de données d’une instance dans votre base de données Aurora PostgreSQL Limitless, choisissez le nom de l’instance dans la colonne **Instances**. Pour afficher la charge de base de données pour `DTR-2-2`, choisissez `DTR-2-2` dans la colonne **Instances**.
**Note**
Vous pouvez consulter les métriques Performance Insights uniquement pour les instances d’une base de données Aurora PostgreSQL Limitless.
# Analyse de la charge de la base de données en temps d’attente pour la base de données Aurora PostgreSQL Limitless à l’aide du tableau de bord de Performance Insights
Vous souhaiterez peut-être améliorer les performances de votre base de données Aurora PostgreSQL Limitless en suivant les événements d’attente. Pour analyser les événements de charge de base de données par attente pour votre base de données Aurora PostgreSQL Limitless, suivez la procédure suivante.
**Pour analyser la charge de base de données par temps d’attente pour la base de données Aurora PostgreSQL Limitless à l’aide de la console**
1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Performance Insights**.
1. Choisissez une base de données Aurora PostgreSQL Limitless. Le tableau de bord de Performance Insights s’affiche pour cette base de données Aurora PostgreSQL Limitless.
1. Dans la section **Charge de base de données**, choisissez **Attentes** pour **Divisé par**. Pour afficher le nombre d’AAS et le nombre estimé de vCPU, choisissez **Absolues** pour **Considéré comme**.
Le graphique Nombre moyen de sessions actives affiche la charge de base de données pour les instances de votre base de données d’Aurora PostgreSQL Limitless.
![\[Divisé par attentes.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png)
1. Faites défiler jusqu’à l’onglet **Top SQL** (Principaux éléments SQL).
Dans l’exemple suivant, l’instruction SQL dont la charge par attentes est la plus élevée est l’instruction `DELETE`.
![\[Onglet SQL supérieur lorsqu’il est divisé par attente.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png)
1. Choisissez l’instruction SQL pour afficher ses instructions de composants.
Dans l’exemple suivant, l’instruction `SELECT` comporte 3 instructions de composants.
![\[Choisissez une instruction SQL pour l’agrandir.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql-selected.png)
# Analyse de la répartition de la charge de la base de données Aurora PostgreSQL Limitless à l’aide du tableau de bord de Performance Insights
Vous souhaiterez peut-être équilibrer la répartition de la charge pour les instances de votre base de données Aurora PostgreSQL Limitless. Pour analyser la répartition de la charge des instances sur une base de données Aurora PostgreSQL Limitless, suivez la procédure suivante.
**Pour analyser la répartition de la charge des instances sur une base de données Aurora PostgreSQL Limitless à l’aide de la console**
1. Ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Performance Insights**.
1. Choisissez une base de données Aurora PostgreSQL Limitless. Le tableau de bord de Performance Insights s’affiche pour cette base de données Aurora PostgreSQL Limitless.
1. Dans la section **Charge de base de données**, choisissez **Instances** pour **Divisé par**. Pour afficher le nombre d’AAS et le nombre estimé de vCPU pour toutes les instances de votre base de données Aurora PostgreSQL Limitless, choisissez **Absolues** pour **Considéré comme**.
Le graphique Nombre moyen de sessions actives affiche la charge de base de données pour les instances de votre base de données d’Aurora PostgreSQL Limitless.
![\[Consultez le tableau de bord absolu des Performances Insights pour votre base de données Aurora PostgreSQL Limitless, divisé par instances.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png)
1. Pour voir un graphique de répartition de la charge des instances dans votre base de données Aurora PostgreSQL Limitless, choisissez l’onglet **Répartition de charge**.
Dans l’exemple suivant, l’instance avec la charge de base de données la plus élevée est `DTR-2-2`.
![\[Onglet SQL supérieur lorsque vous effectuez une division par attentes au niveau de l’instance.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png)
# Surveillance d’Aurora PostgreSQL Limitless Database avec Amazon GuardDuty RDS Protection
Amazon GuardDuty est un service de détection des menaces qui vous aide à protéger vos comptes, vos conteneurs, vos charges de travail et les données de votre environnement AWS. Grâce à des modèles de machine learning (ML) et à des fonctions de détection des anomalies et des menaces, GuardDuty surveille en continu diverses sources de journaux et les activités d’exécution afin d’identifier et de hiérarchiser les risques de sécurité potentiels ainsi que les activités malveillantes dans votre environnement.
GuardDuty RDS Protection analyse et établit un profil pour les événements de connexion afin de détecter les menaces d’accès potentielles à vos bases de données Amazon Aurora. Lorsque vous activez la protection RDS, GuardDuty consomme les événements de connexion RDS de vos bases de données Aurora. RDS Protection surveille ces événements et en établit le profil pour détecter les menaces potentielles de l’intérieur ou des acteurs externes.
Pour plus d’informations sur GuardDuty RDS Protection dans Aurora, consultez [Surveillance des menaces avec Amazon GuardDuty RDS Protection pour Amazon Aurora](guard-duty-rds-protection.md).
Pour plus d’informations sur l’activation de GuardDuty RDS Protection, consultez [GuardDuty RDS Protection](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html) dans le *Guide de l’utilisateur Amazon GuardDuty*.
# Fonctions et vues dans Aurora PostgreSQL Limitless Database
Aurora PostgreSQL Limitless Database propose des fonctions et des vues supplémentaires. Elles sont basées sur les fonctions et les vues Aurora PostgreSQL correspondantes.
**Note**
Certaines statistiques peuvent produire des résultats incohérents si des transactions sont en cours d’exécution.
**Topics**
+ [Fonctions d’Aurora PostgreSQL Limitless Database](limitless-monitoring-functions.md)
+ [Vues d’Aurora PostgreSQL Limitless Database](limitless-monitoring-views.md)
# Fonctions d’Aurora PostgreSQL Limitless Database
Le tableau suivant présente les nouvelles fonctions d’Aurora PostgreSQL Limitless Database.
**Note**
Les fonctions répertoriées dans ce tableau se trouvent dans le schéma `rds_aurora`. Lorsque vous utilisez une fonction Limitless Database, assurez-vous d’inclure le nom d’objet entièrement qualifié : `rds_aurora`.`object_name`.
| Fonctions d’Aurora PostgreSQL Limitless Database | Fonction d’Aurora PostgreSQL correspondante |
| --- | --- |
| [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 |
Les exemples suivants fournissent des détails sur les fonctions d’Aurora PostgreSQL Limitless Database. Pour plus d’informations sur les fonctions PostgreSQL, consultez [Fonctions et opérateurs](https://www.postgresql.org/docs/15/functions.html) dans la documentation PostgreSQL.
**limitless\$1backend\$1dsid**
La fonction `limitless_backend_dsid` renvoie l’ID de la session distribuée pour la session en cours. Une session distribuée s’exécute sur un routeur d’un groupe de partitions de base de données et implique des processus dorsaux sur une ou plusieurs partitions du groupe de partitions de base de données.
L’exemple suivant montre comment utiliser la fonction `limitless_backend_dsid`.
```
SELECT rds_aurora.limitless_backend_dsid();
limitless_backend_dsid
------------------------
8CACD7B04D0FC2A5
(1 row)
```
**limitless\$1cancel\$1session**
La fonction `limitless_cancel_session` se comporte comme `pg_cancel_backend`, à la différence qu’elle essaie d’annuler tous les processus dorsaux liés à l’ID de session distribuée spécifié en leur envoyant un `SIGINT` (signal d’interruption).
Le paramètre d’entrée est le suivant :
+ `distributed_session_id` (texte) : l’ID de la session distribuée à annuler.
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `pid` (texte) : l’ID du processus dorsal.
+ `success` (booléen) : indique si l’annulation s’est déroulée avec succès.
L’exemple suivant montre comment utiliser la fonction `limitless_cancel_session`.
```
SELECT * FROM rds_aurora.limitless_cancel_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1stat\$1clear\$1snapshot**
La fonction `limitless_stat_clear_snapshot` supprime l’instantané des statistiques actuelles ou les informations mises en cache sur tous les nœuds.
L’exemple suivant montre comment utiliser la fonction `limitless_stat_clear_snapshot`.
```
SELECT rds_aurora.limitless_stat_clear_snapshot();
```
**limitless\$1stat\$1database\$1size**
La fonction `limitless_stat_database_size` renvoie les tailles d’une base de données dans le groupe de partitions de base de données.
Le paramètre d’entrée est le suivant :
+ `dbname` (nom) : la base de données dont vous souhaitez obtenir les tailles.
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`.
+ `db_size` : la taille de la base de données de ce sous-cluster en octets.
L’exemple suivant montre comment utiliser la fonction `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**
La fonction `limitless_stat_get_snapshot_timestamp` renvoie l’horodatage de l’instantané des statistiques en cours, ou `NULL` si aucun instantané n’a été créé. Un instantané est créé lors de la première consultation des statistiques cumulées dans une transaction, lorsque `stats_fetch_consistency` est défini sur `snapshot`. Renvoie une vue consolidée des horodatages des instantanés de tous les nœuds. Les colonnes `subcluster_id` et `subcluster_type` indiquent de quel nœud proviennent les données.
L’exemple suivant montre comment utiliser la fonction `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**
La fonction `limitless_stat_prepared_xacts` renvoie des informations sur les transactions sur tous les nœuds actuellement préparés pour une validation en deux phases. Pour plus d’informations, consultez [pg\$1prepared\$1xacts](https://www.postgresql.org/docs/current/view-pg-prepared-xacts.html) dans la documentation PostgreSQL.
L’exemple suivant montre comment utiliser la fonction `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**
La fonction `limitless_stat_relation_sizes` renvoie les différentes tailles d’une table dans le groupe de partitions de base de données.
Les paramètres d’entrée sont les suivants :
+ `relnspname` (nom) : le nom du schéma contenant la table.
+ `relname` (nom) : le nom de la table.
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`.
+ `main_size` : la taille en octets du jeu de données principal de ce nœud.
+ `fsm_size` : la taille en octets de la carte de l’espace libre de la table dans ce nœud.
+ `vm_size` : la taille en octets de la carte de visibilité de la table dans ce nœud.
+ `init_size` : la taille en octets de l’initialisation de la table dans ce nœud.
+ `toast_size` : la taille en octets de la table Toast associée à la table de ce fork.
+ `index_size` : la taille en octets de tous les indexes de la table dans ce nœud.
+ `total_size` : la taille en octets de tous les segments de la table dans ce nœud.
L’exemple suivant montre comment utiliser la fonction `limitless_stat_relation_sizes` (certaines colonnes ont été omises).
```
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**
La fonction `limitless_stat_reset` remet à zéro (0) l’ensemble des compteurs de statistiques de la base de données actuelle. Si `track_functions` est activé, la colonne `stats_reset` dans `limitless_stat_database` indique la dernière fois que les statistiques ont été réinitialisées pour la base de données. Par défaut, `limitless_stat_reset` ne peut être exécuté que par un super-utilisateur. Les autres utilisateurs peuvent obtenir une autorisation en utilisant le privilège `EXECUTE`.
L’exemple suivant montre comment utiliser la fonction `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**
La fonction `limitless_stat_statements_reset` ignore les statistiques collectées jusqu’à présent par `limitless_stat_statements` correspondant aux paramètres spécifiés `username`, `dbname`, `distributed_query_id` et `queryid`. Si aucun paramètre n’est spécifié, la valeur par défaut `""` ou `0` (non valide) est utilisée pour chacun d’entre eux, et les statistiques correspondant aux autres paramètres sont réinitialisées. Si aucun paramètre n’est spécifié, ou si tous les paramètres spécifiés sont `""` ou `0` (non valides), la fonction ignore toutes les statistiques. Si toutes les statistiques de la vue `limitless_stat_statements` sont supprimées, la fonction réinitialise également les statistiques de la vue `limitless_stat_statements_info`.
Les paramètres d’entrée sont les suivants :
+ `username` (nom) : l’utilisateur qui a interrogé l’instruction.
+ `dbname` (nom) : la base de données dans laquelle la requête a été exécutée.
+ `distributed_query_id` (bigint) : l’ID de requête de la requête parent provenant du nœud coordinateur. Cette colonne est `NULL` s’il s’agit de la requête parent. Le nœud coordinateur transmet l’ID de requête distribué aux nœuds participants. Ainsi, pour les nœuds participants, les valeurs de l’ID de requête distribuée et de l’ID de requête sont différentes.
+ `queryid` (bigint) : l’ID de requête de l’instruction.
L’exemple suivant montre comment utiliser la fonction `limitless_stat_statements_reset` pour réinitialiser toutes les statistiques collectées par `limitless_stat_statements`.
```
SELECT rds_aurora.limitless_stat_statements_reset();
```
**limitless\$1stat\$1system\$1waits**
La fonction `limitless_stat_system_waits` renvoie une vue consolidée des données d’événements d’attente provenant de `aurora_stat_system_waits`, qui rapporte l’activité d’attente à l’échelle du système pour une instance, à partir de tous les nœuds. Les colonnes `subcluster_id` et `subcluster_type` indiquent de quel nœud proviennent les données.
L’exemple suivant montre comment utiliser la fonction `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**
La fonction `limitless_terminate_session` se comporte comme `pg_terminate_backend`, à la différence qu’elle essaie d’interrompre tous les processus dorsaux liés à l’ID de session distribuée spécifié en leur envoyant un `SIGTERM` (signal de fin).
Le paramètre d’entrée est le suivant :
+ `distributed_session_id` (texte) : l’ID de la session distribuée à terminer.
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `pid` (texte) : l’ID du processus dorsal.
+ `success` (booléen) : indique si le processus s’est bien terminé.
L’exemple suivant montre comment utiliser la fonction `limitless_terminate_session`.
```
SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B');
subcluster_id | pid | success
---------------+-------+---------
1 | 26920 | t
(1 row)
```
**limitless\$1wait\$1report**
La fonction `limitless_wait_report` renvoie l’activité des événements d’attente sur une période donnée, en provenance de l’ensemble des nœuds. Les colonnes `subcluster_id` et `subcluster_type` indiquent de quel nœud proviennent les données.
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`.
Les autres colonnes sont les mêmes que dans `aurora_wait_report`.
L’exemple suivant montre comment utiliser la fonction `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
```
# Vues d’Aurora PostgreSQL Limitless Database
Le tableau suivant présente les nouvelles vues d’Aurora PostgreSQL Limitless Database.
**Note**
Les vues répertoriées dans ce tableau se trouvent dans le schéma `rds_aurora`. Lorsque vous utilisez une vue Limitless Database, assurez-vous d’inclure le nom d’objet entièrement qualifié : `rds_aurora`.`object_name`.
| Vue d’Aurora PostgreSQL Limitless Database | Vue d’Aurora PostgreSQL correspondante |
| --- | --- |
| [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) | Aucun |
| [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) | Aucun |
| [limitless\$1table\$1collocation\$1distributions](#limitless_table_collocation_distributions) | Aucun |
Les exemples suivants fournissent des détails sur les vues d’Aurora PostgreSQL Limitless Database. Pour plus d’informations sur les vues de PostgreSQL, consultez [Affichage des statistiques](https://www.postgresql.org/docs/15/monitoring-stats.html#MONITORING-STATS-VIEWS) dans la documentation PostgreSQL.
**Note**
Certaines vues de statistiques peuvent produire des résultats incohérents si des transactions sont en cours d’exécution.
**limitless\$1database**
Cette vue contient des informations sur les bases de données disponibles dans le groupe de partitions de base de données. Exemples :
```
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}
```
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster (nœud)
+ `subcluster_type` (texte) : le type de sous-cluster (nœud), de routeur ou de partition
Les autres colonnes sont les mêmes que dans `pg_database`.
**limitless\$1locks**
Cette vue contient une ligne par processus et par nœud. Elle fournit un accès aux informations sur les verrous détenus par les processus actifs du serveur de base de données.
**Example de créer un verrou avec deux transactions**
Dans cet exemple, nous exécutons deux transactions simultanément sur deux routeurs.
```
# 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;
```
La première transaction est exécutée. Les transactions suivantes doivent attendre que la première transaction soit terminée. La deuxième transaction est donc bloquée par un verrou. Pour en vérifier la cause racine, nous exécutons une commande en joignant `limitless_locks` à `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 créer un verrou de manière explicite**
Dans cet exemple, nous créons un verrou de manière explicite, puis nous utilisons la vue `limitless_locks` pour afficher les verrous (certaines colonnes sont omises).
```
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**
Cette vue contient une ligne par processus et par nœud. Elle peut être utilisée pour suivre l’état général du système et les processus de triage qui prennent du temps. Exemples :
```
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)
```
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`.
+ `distributed_session_id` (texte) : l’ID de la session distribuée à laquelle appartient ce processus.
+ `distributed_session_state` (texte) : précise si le processus est un coordinateur, un participant ou un processus indépendant/non distribué (indiqué comme `NULL`).
+ `datname` (texte) : la base de données à laquelle ce processus est connecté.
+ `distributed_query_id` (bigint) : l’ID de requête de la requête parent provenant du nœud coordinateur. Cette colonne est `NULL` s’il s’agit de la requête parent. Le nœud coordinateur transmet l’ID de requête distribué aux nœuds participants. Ainsi, pour les nœuds participants, les valeurs de l’ID de requête distribuée et de l’ID de requête sont différentes.
+ `is_sso_query` (texte) : indique si la requête est optimisée pour une seule partition ou non.
Les autres colonnes sont les mêmes que dans `pg_stat_activity`.
**limitless\$1stat\$1all\$1indexes**
Cette vue contient des statistiques d’utilisation sur les index du groupe de partitions de base de données. Exemples :
```
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**
Cette vue contient des statistiques sur toutes les tables de la base de données actuelle du groupe de partitions de base de données. Elle est particulièrement utile pour le suivi des processus de vacuum et des opérations de manipulation de données (DML). Exemples :
```
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)
```
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`.
+ `relname` (nom) : le nom de la table.
Les autres colonnes sont les mêmes que dans `pg_stat_all_tables`.
**limitless\$1stat\$1database**
Cette vue contient des statistiques sur toutes les tables du groupe de partitions de base de données. Renvoie une ligne par base de données et par nœud. Exemples :
```
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)
```
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`.
+ `datname` (nom) : le nom de la base de données.
Les autres colonnes sont les mêmes que dans `pg_stat_database`.
**limitless\$1stat\$1progress\$1vacuum**
Cette vue contient des informations sur les opérations de vacuum en cours. Exemples :
```
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
```
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`.
+ `distributed_session_id` (texte) : l’identifiant de la session qui a lancé l’opération de vacuum.
+ `datname` (nom) : la base de données dans laquelle le vacuum est effectué.
+ `nspname` (name) : le nom du schéma de la table en cours de vacuum. La valeur est `null` si la table en cours de vacuum ne se trouve pas dans la même base de données que celle à laquelle l’utilisateur est connecté.
+ `relname` (nom) : le nom de la table en cours de vacuum. La valeur est `null` si la table en cours de vacuum ne se trouve pas dans la même base de données que celle à laquelle l’utilisateur est connecté.
Les autres colonnes sont les mêmes que dans `pg_stat_progress_vacuum`.
**limitless\$1stat\$1statements**
Cette vue permet de suivre la planification et d’exécuter les statistiques de toutes les instructions SQL exécutées sur tous les nœuds.
Vous devez installer l’extension [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) pour utiliser la vue `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;
```
L’exemple suivant illustre l’utilisation de la vue `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 |
[...]
```
Les paramètres de sortie sont les suivants :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
+ `subcluster_type` (texte) : le type de sous-cluster auquel appartient ce processus : `router` ou `shard`.
+ `distributedqueryid` (bigint) : l’ID de requête de la requête parent provenant du nœud coordinateur. Cette colonne est `NULL` s’il s’agit de la requête parent. Le nœud coordinateur transmet l’ID de requête distribué aux nœuds participants. Ainsi, pour les nœuds participants, les valeurs de l’ID de requête distribuée et de l’ID de requête sont différentes.
+ `username` (nom) : l’utilisateur qui a interrogé l’instruction.
+ `dbname` (nom) : la base de données dans laquelle la requête a été exécutée.
+ `sso_calls` (nom) : le nombre de fois où l’instruction a été optimisée pour une seule partition.
Les autres colonnes sont les mêmes que dans [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html).
**limitless\$1stat\$1statements\$1info**
Cette vue contient les statistiques de la vue `limitless_stat_statements`. Chaque ligne contient les données de la vue [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7) pour chaque nœud. La colonne `subcluster_id` identifie chaque nœud.
```
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)
```
Le paramètre de sortie est le suivant :
+ `subcluster_id` (texte) : l’ID du sous-cluster auquel appartient ce processus.
Les autres colonnes sont les mêmes que dans [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7).
**limitless\$1stat\$1subclusters**
Cette vue contient les statistiques du réseau entre les routeurs et les autres nœuds. Elle contient une ligne par paire composée d’un routeur et d’un autre nœud, par exemple :
```
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
```
Les paramètres de sortie sont les suivants :
+ `orig_subcluster` (texte) : l’ID du routeur d’où proviennent les communications
+ `orig_subcluster_az` (texte) : la zone de disponibilité (AZ) du routeur d’origine
+ `dest_subcluster` (texte) : l’ID du nœud de destination
+ `dest_subcluster_az` (texte) : la dernière zone de disponibilité collectée du nœud de destination
+ `latency_us` (bigint) : la dernière latence réseau collectée entre les nœuds, en microsecondes. La valeur est `0` si le nœud est inaccessible.
+ `latest_collection` (horodatage) : l’horodatage de la dernière collecte des informations de zone de disponibilité et de latence pour le nœud de destination.
+ `failed_requests` (bigint) : le nombre cumulé de demandes internes ayant échoué
+ `received_bytes` (bigint) : le nombre cumulé estimé d’octets reçus de ce nœud
+ `sent_bytes` (bigint) : le nombre cumulé estimé d’octets envoyés à ce nœud
+ `same_az_requests` (bigint) : le nombre cumulé de demandes de base de données internes adressées à ce nœud lorsqu’il se trouve dans la même zone de disponibilité que le routeur d’origine
+ `cross_az_requests` (bigint) : le nombre cumulé de demandes de base de données internes adressées à ce nœud lorsqu’il se trouve dans une zone de disponibilité différente de celle du routeur d’origine
+ `stat_reset_timestamp` (horodatage) : l’horodatage auquel les statistiques cumulées pour cette vue ont été réinitialisées pour la dernière fois
**limitless\$1statio\$1all\$1indexes**
Cette vue contient les statistiques d’entrée/sortie (E/S) pour tous les index du groupe de partitions de base de données. Exemples :
```
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**
Cette vue contient les statistiques d’entrée/sortie (E/S) pour toutes les tables du groupe de partitions de base de données. Exemples :
```
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**
Cette vue contient des informations sur les tables d’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**
Cette vue contient des informations sur les tables partitionnées colocalisées.
Dans l’exemple suivant, les tables `orders` et `customers` sont colocalisées, tout comme les tables `users` et `followers`. Les tables colocalisées présentent le même `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**
Cette vue affiche la diffusion des clés pour chaque collocation.
```
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)
```
# Événements d’attente dans Aurora PostgreSQL Limitless Database
Un événement d’attente dans Aurora PostgreSQL indique une ressource pour laquelle une session est en attente, telle qu’une entrée/sortie (E/S) et des verrous. Les événements d’attente permettent de déterminer les raisons pour lesquelles les sessions attendent des ressources et d’identifier les goulots d’étranglement. Pour plus d’informations, consultez [Événements d'attente Aurora PostgreSQL](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.waits).
Aurora PostgreSQL Limitless Database possède ses propres événements d’attente liés aux routeurs et aux partitions. La plupart d’entre eux concernent les routeurs qui attendent que des partitions soient disponibles pour exécuter leurs tâches. Les événements d’attente de partition contiennent des détails sur les tâches en cours d’exécution.
**Topics**
+ [Interrogation des événements d’attente](#limitless-monitoring-waits.query)
+ [Événements d’attente Limitless Database](limitless-waits-reference.md)
## Interrogation des événements d’attente
Vous pouvez utiliser la vue [limitless\$1stat\$1activity](limitless-monitoring-views.md#limitless_stat_activity) pour interroger des événements d’attente, comme illustré dans l’exemple suivant.
```
SELECT wait_event FROM rds_aurora.limitless_stat_activity WHERE wait_event_type='AuroraLimitless';
wait_event
----------------------
RemoteStatementSetup
RemoteStatementSetup
(2 rows)
```
Vous pouvez également utiliser la fonction `aurora_stat_system_waits` pour répertorier le nombre d’attentes et le temps total consacré à chaque événement d’attente, comme indiqué dans l’exemple suivant.
```
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)
```
# Événements d’attente Limitless Database
Les événements d’attente suivants sont propres à Aurora PostgreSQL Limitless Database. Vous pouvez surveiller ces événements d’attente pour identifier les goulots d’étranglement dans le traitement au sein d’Aurora PostgreSQL Limitless Database.
**Topics**
+ [Événement d’attente IO:TwophaseFilePoolWrite](#limitless-waits-TwophaseFilePoolWrite)
+ [Événement d’attente IO:TwophaseFilePoolRead](#limitless-waits-TwophaseFilePoolRead)
+ [Événement d’attente AuroraLimitless:Connect](#limitless-waits-Connect)
+ [Événement d’attente AuroraLimitless:AsyncConnect](#limitless-waits-AsyncConnect)
+ [Événement d’attente AuroraLimitless:RemoteStatementSetup](#limitless-waits-RemoteStatementSetup)
+ [Événement d’attente AuroraLimitless:RemoteDDLExecution](#limitless-waits-RemoteDDLExecution)
+ [Événement d’attente AuroraLimitless:RemoteStatementExecution](#limitless-waits-RemoteStatementExecution)
+ [Événement d’attente AuroraLimitless:FetchRemoteResults](#limitless-waits-FetchRemoteResults)
+ [Événement d’attente AuroraLimitless:AsyncGetInitialResponse](#limitless-waits-AsyncGetInitialResponse)
+ [Événement d’attente AuroraLimitless:AsyncGetNextResponse](#limitless-waits-AsyncGetNextResponse)
+ [Événement d’attente AuroraLimitless:AbortedCommandCleanup](#limitless-waits-AbortedCommandCleanup)
+ [Événement d’attente AuroraLimitless:DistributedCommitPrepare](#limitless-waits-DistributedCommitPrepare)
+ [Événement d’attente AuroraLimitless:DistributedCommit](#limitless-waits-DistributedCommit)
+ [Événement d’attente AuroraLimitless:DistributedCommitPrepareThrottle](#limitless-waits-DistributedCommitPrepareThrottle)
+ [Événement d’attente AuroraLimitless:PreparedTransactionResolution](#limitless-waits-PreparedTransactionResolution)
+ [Événement d’attente AuroraLimitless:SendPreparedTransactionOutcome](#limitless-waits-SendPreparedTransactionOutcome)
+ [Événement d’attente AuroraLimitless:CommitClockBarrier](#limitless-waits-CommitClockBarrier)
+ [Événement d’attente AuroraLimitless:SnapshotClockBarrier](#limitless-waits-SnapshotClockBarrier)
+ [Événement d’attente AuroraLimitless:ReaderSnapshotClockBarrier](#limitless-waits-ReaderSnapshotClockBarrier)
+ [Événement d’attente AuroraLimitless:GatherDistributedDeadlockGraph](#limitless-waits-GatherDistributedDeadlockGraph)
+ [Événement d’attente AuroraLimitless:DistributedDeadlockDetection](#limitless-waits-DistributedDeadlockDetection)
+ [Événement d’attente AuroraLimitless:DistributedDeadlockAbort](#limitless-waits-DistributedDeadlockAbort)
+ [Événement d’attente AuroraLimitless:GatherRemoteStats](#limitless-waits-GatherRemoteStats)
+ [Événement d’attente AuroraLimitless:GlobalSequenceRefresh](#limitless-waits-GlobalSequenceRefresh)
+ [Événement d’attente AuroraLimitless:GlobalVacuumTimeExchange](#limitless-waits-GlobalVacuumTimeExchange)
+ [Événement d’attente AuroraLimitless:DistributedTransactionMonitorGather](#limitless-waits-DistributedTransactionMonitorGather)
+ [Événement d’attente AuroraLimitlessActivity:AdminTaskSchedulerMain](#limitless-waits-AdminTaskSchedulerMain)
+ [Événement d’attente AuroraLimitlessActivity:AdminTaskExecutorMain](#limitless-waits-AdminTaskExecutorMain)
+ [Événement d’attente AuroraLimitlessActivity:AdminTaskMonitorMain](#limitless-waits-AdminTaskMonitorMain)
+ [Événement d’attente AuroraLimitlessActivity:DatabaseCleanupMonitorMain](#limitless-waits-DatabaseCleanupMonitorMain)
+ [Événement d’attente AuroraLimitlessActivity:TopologyCleanupMonitorMain](#limitless-waits-TopologyCleanupMonitorMain)
+ [Événement d’attente AuroraLimitlessActivity:ToplogyChangeMonitorMain](#limitless-waits-ToplogyChangeMonitorMain)
+ [Événement d’attente AuroraLimitlessActivity:DistributedTransactionMonitorMain](#limitless-waits-DistributedTransactionMonitorMain)
+ [Événement d’attente AuroraLimitlessActivity:GlobalVacuumMonitorMain](#limitless-waits-GlobalVacuumMonitorMain)
## Événement d’attente IO:TwophaseFilePoolWrite
En attente de l’écriture d’un fichier d’état à deux phases dans le pool de fichiers d’état à deux phases. Il s’agit d’un événement spécifique à Aurora.
### Causes
Les processus exécutant une commande `PREPARED TRANSACTION`, y compris les participants à une transaction distribuée Limitless Database, doivent conserver l’état de la transaction dans un fichier en deux phases. Aurora utilise un pool de fichiers pour améliorer les performances de cette opération.
### Action
Cette opération correspond à une écriture d’E/S synchrone ; ainsi, une latence importante sur cet événement résulte des mêmes causes que pour `IO:XactSync` et se traite de façon identique. Si vous utilisez Limitless Database, vous devrez peut-être réduire le nombre de transactions distribuées exécutées.
## Événement d’attente IO:TwophaseFilePoolRead
En attente de la lecture d’un fichier d’état à deux phases dans le pool de fichiers d’état à deux phases.
### Causes
Les processus qui exécutent une commande `COMMIT PREPARED` sur une transaction déjà préparée, y compris les participants d’une transaction distribuée Limitless Database, peuvent être amenés à lire l’état de transaction précédemment enregistré dans un fichier d’état à deux phases. Aurora utilise un pool de fichiers pour améliorer les performances de cette opération.
### Action
Il s’agit d’une opération d’E/S. Par conséquent, une latence importante sur cet événement résulte des mêmes causes que pour `IO:DataFileRead` et se traite de façon identique. Si vous utilisez Limitless Database, vous devrez peut-être réduire le nombre de transactions distribuées exécutées.
## Événement d’attente AuroraLimitless:Connect
Le processus attend qu’une connexion soit établie avec un autre nœud du cluster.
### Causes
Des connexions sont établies entre les processus et les nœuds distants pour exécuter des requêtes, des transactions distribuées et des DDL.
### Action
Réduisez le nombre de connexions simultanées au cluster ou optimisez l’utilisation des requêtes inter-partitions.
## Événement d’attente AuroraLimitless:AsyncConnect
Cet événement, semblable à `Connect`, représente l’attente d’un processus pendant l’établissement de connexions parallèles avec plusieurs nœuds.
### Causes
L’établissement de connexions parallèles est le plus souvent effectué lors de l’exécution d’instructions DDL.
### Action
Réduisez le nombre d’instructions DDL ou regroupez-en plusieurs au sein d’une même session afin d’améliorer la réutilisation des connexions.
## Événement d’attente AuroraLimitless:RemoteStatementSetup
Le processus est en attente de la configuration de l’exécution d’une requête distante, telle que l’ouverture ou la fermeture d’un curseur, ou la création d’une instruction préparée.
### Causes
Cet événement d’attente augmente avec le nombre d’analyses effectuées sur des tables partitionnées lorsque l’instruction ne peut pas être optimisée pour une seule partition.
### Action
Optimisez les requêtes pour réduire le nombre d’opérations d’analyse ou augmenter l’éligibilité à l’optimisation à partition unique.
## Événement d’attente AuroraLimitless:RemoteDDLExecution
Le processus attend la fin d’une commande DDL à distance.
### Causes
Lorsque vous exécutez une commande DDL sur un groupe de partitions de base de données, celle-ci doit être distribuée aux autres routeurs et nœuds de partition avant la validation de l’opération. Certaines opérations DDL peuvent s’exécuter pendant une longue période, car les données doivent être adaptées aux modifications du schéma.
### Action
Identifiez les commandes DDL de longue durée afin de les optimiser.
## Événement d’attente AuroraLimitless:RemoteStatementExecution
Un processus attend la fin d’une commande à distance.
### Causes
Une commande SQL est en cours d’exécution sur un nœud distant. Cet événement apparaîtra fréquemment dans le cadre des communications internes, telles que `auto_analyze` et les vérifications de pulsations.
### Action
Identifiez les commandes de longue durée à l’aide de la vue limitless\$1stat\$1statements. Dans de nombreux cas, cet événement est attendu, en particulier pour les processus en arrière-plan ou internes, et aucune action n’est requise.
## Événement d’attente AuroraLimitless:FetchRemoteResults
Un processus attend de récupérer les lignes d’un nœud distant.
### Causes
Cet événement d’attente tend à se produire davantage lorsqu’un grand volume de lignes est extrait d’une table distante, comme une table partitionnée ou une table de référence.
### Action
Identifiez les requêtes `SELECT` non optimisées à l’aide de la vue `limitless_stat_statements`. Optimisez les requêtes pour récupérer uniquement les données nécessaires. Vous pouvez également ajuster le paramètre `rds_aurora.limitless_maximum_adaptive_fetch_size`.
## Événement d’attente AuroraLimitless:AsyncGetInitialResponse
Le processus attend une réponse initiale lorsque le mode pipeline est utilisé pour l’exécution des requêtes.
### Causes
Cet événement est généralement observé lors de l’exécution d’une requête entre le routeur et la partition lorsque les données sont situées sur une seule partition ; il s’agit d’un fonctionnement attendu.
### Action
Aucune action supplémentaire n’est requise.
## Événement d’attente AuroraLimitless:AsyncGetNextResponse
Le processus attend des réponses supplémentaires lorsque le mode pipeline est utilisé pour l’exécution des requêtes.
### Causes
Cet événement est généralement observé lors de l’exécution d’une requête entre le routeur et la partition lorsque les données sont situées sur une seule partition ; il s’agit d’un fonctionnement attendu.
### Action
Aucune action supplémentaire n’est requise.
## Événement d’attente AuroraLimitless:AbortedCommandCleanup
Le processus attend le résultat d’une requête de nettoyage à distance. Des requêtes de nettoyage sont envoyées aux nœuds de partition afin de les ramener à un état approprié lorsque qu’une transaction distribuée se termine.
### Causes
Le nettoyage d’une transaction est effectué lorsqu’une transaction est annulée soit parce qu’une erreur a été détectée, soit parce qu’un utilisateur a émis une commande ABORT explicite ou annulé la requête en cours d’exécution.
### Action
Recherchez la cause de l’annulation de la transaction.
## Événement d’attente AuroraLimitless:DistributedCommitPrepare
Le processus valide une transaction distribuée et attend que chaque participant confirme la commande de préparation.
### Causes
Les transactions qui modifient plusieurs nœuds doivent effectuer une validation distribuée. Une durée d’attente prolongée pour `DistributedCommitPrepare` peut résulter d’attentes importantes sur l’événement `IO:TwophaseFilePoolWrite` des nœuds participants.
### Action
Réduisez le nombre de transactions qui modifient les données sur plusieurs nœuds. Étudiez les événements `IO:TwophaseFilePoolWrite` survenus sur d’autres nœuds du cluster.
## Événement d’attente AuroraLimitless:DistributedCommit
Le processus valide une transaction distribuée et attend que le participant principal confirme la commande de préparation.
### Causes
Les transactions qui modifient plusieurs nœuds doivent effectuer une validation distribuée. Une durée d’attente prolongée pour `DistributedCommit` peut résulter d’attentes importantes sur l’événement `IO:XactSync` le participant principal.
### Action
Réduisez le nombre de transactions qui modifient les données sur plusieurs nœuds. Étudiez les événements `IO:XactSync` survenus sur d’autres nœuds du cluster.
## Événement d’attente AuroraLimitless:DistributedCommitPrepareThrottle
Le processus tente de préparer une transaction distribuée et est limité en raison de transactions préparées existantes.
### Causes
Les transactions qui modifient plusieurs nœuds doivent effectuer une validation distribuée. Les participants à ces transactions doivent effectuer une opération de préparation dans le cadre du protocole de validation. Aurora limite le nombre de préparations simultanées ; si cette limite est dépassée, le processus attendra lors de l’événement `DistributedCommitPrepareThrottle`.
### Action
Réduisez le nombre de transactions qui modifient les données sur plusieurs nœuds. Examinez les événements `IO:TwophaseFilePoolWrite`, car une augmentation de leur durée pourrait entraîner une accumulation de transactions préparées existantes, ce qui ralentirait les nouvelles tentatives de préparation.
## Événement d’attente AuroraLimitless:PreparedTransactionResolution
Le processus a rencontré un tuple modifié par une transaction distribuée qui est à l’état préparé. Le processus doit déterminer si la transaction distribuée sera visible dans son instantané.
### Causes
Les transactions qui modifient plusieurs nœuds doivent effectuer une validation distribuée comprenant une phase de préparation. Un nombre élevé de transactions distribuées ou une latence accrue lors des validations distribuées peuvent provoquer la survenue de l’événement d’attente `PreparedTransactionResolution` dans d’autres processus.
### Action
Réduisez le nombre de transactions qui modifient les données sur plusieurs nœuds. Examinez les événements liés aux validations distribuées, car un allongement de leur durée peut augmenter la latence du processus de validation des transactions distribuées. Il peut aussi être utile d’analyser les charges du réseau et du CPU.
## Événement d’attente AuroraLimitless:SendPreparedTransactionOutcome
Le processus s’exécute sur un nœud qui coordonne une transaction distribuée et un autre processus s’est renseigné sur l’état de cette transaction, ou le processus a validé une transaction distribuée et envoie le résultat aux participants.
### Causes
Les processus confrontés à l’événement d’attente `PreparedTransactionResolution` interrogeront le coordinateur des transactions. La réponse sur le coordinateur de transactions rencontrera l’événement SendPreparedTransactionOutcome.
### Action
Réduisez le nombre de transactions qui modifient les données sur plusieurs nœuds. Examinez les événements liés aux validations distribuées, ainsi que les événements `IO:TwophaseFilePoolWrite` et `IO:TwophaseFilePoolRead`, car ils peuvent augmenter la latence du processus de validation des transactions distribuées. Il peut aussi être utile d’analyser les charges du réseau et du CPU.
## Événement d’attente AuroraLimitless:CommitClockBarrier
Le processus procède à la validation d’une transaction et doit attendre que le temps de validation attribué soit assurément passé pour tous les nœuds du cluster.
### Causes
Une saturation du CPU ou du réseau peut accentuer la dérive de l’horloge, entraînant ainsi une perte de temps au cours de cet événement d’attente.
### Action
Examinez la saturation de l’UC ou du réseau dans votre cluster.
## Événement d’attente AuroraLimitless:SnapshotClockBarrier
Le processus a reçu d’un autre nœud une heure d’instantané dont l’horloge est en avance, et il attend que sa propre horloge atteigne cette heure.
### Causes
Cela se produit généralement lorsque le processus a reçu les résultats d’une fonction ayant été déléguée à une partition, et qu’il existe une dérive d’horloge entre les nœuds. Une saturation du CPU ou du réseau peut accentuer la dérive de l’horloge, entraînant ainsi une perte de temps au cours de cet événement d’attente.
### Action
Examinez la saturation de l’UC ou du réseau dans votre cluster.
## Événement d’attente AuroraLimitless:ReaderSnapshotClockBarrier
Cet événement se produit sur les nœuds de lecture. Le processus attend que le nœud de lecture rejoue le flux d’écriture afin que toutes les écritures effectuées avant l’heure d’instantané du processus aient été appliquées.
### Causes
Une augmentation du retard de réplica Aurora peut entraîner une hausse du temps d’attente pour cet événement.
### Action
Examinez le retard de réplica Aurora.
## Événement d’attente AuroraLimitless:GatherDistributedDeadlockGraph
Le processus communique avec les autres nœuds afin de collecter les graphes de verrous dans le cadre de la détection de blocages distribués.
### Causes
Lorsqu’un processus attend un verrou, il effectue une vérification des blocages distribués après une attente supérieure à `rds_aurora.limitless_distributed_deadlock_timeout`.
### Action
Examinez les causes de la contention sur les verrous dans votre application et envisagez d’ajuster le paramètre `rds_aurora.limitless_distributed_deadlock_timeout`.
## Événement d’attente AuroraLimitless:DistributedDeadlockDetection
Le processus communique avec les autres nœuds afin de détecter un blocage distribué.
### Causes
Lorsqu’un processus attend un verrou, il effectue une vérification des blocages distribués après une attente supérieure à `rds_aurora.limitless_distributed_deadlock_timeout`.
### Action
Examinez les causes de la contention sur les verrous dans votre application et envisagez d’ajuster le paramètre `rds_aurora.limitless_distributed_deadlock_timeout`.
## Événement d’attente AuroraLimitless:DistributedDeadlockAbort
Le processus communique avec un autre nœud afin d’interrompre une session choisie comme victime d’un interblocage distribué.
### Causes
Les modèles d’application entraînent des blocages distribués.
### Action
Examinez les modèles d’application entraînant des blocages distribués.
## Événement d’attente AuroraLimitless:GatherRemoteStats
Le processus collecte des statistiques à partir des autres nœuds du cluster.
### Causes
Les requêtes et les vues de surveillance ou d’activité, par exemple`limitless_stat_activity`, permettront de récupérer les statistiques provenant d’autres nœuds.
### Action
Aucune action supplémentaire n’est requise.
## Événement d’attente AuroraLimitless:GlobalSequenceRefresh
Le processus génère une nouvelle valeur de séquence et doit demander un nouveau fragment à partir de la séquence globale.
### Causes
Un taux élevé de génération de valeurs de séquence peut entraîner des blocages lors de cet événement si le paramètre `rds_aurora.limitless_sequence_chunk_size` est insuffisant.
### Action
Il s’agit d’un phénomène normal. Si vous constatez que cet événement dure trop longtemps, ajustez `rds_aurora.limitless_sequence_chunk_size`. Consultez la documentation sur les séquences dans Limitless Database.
## Événement d’attente AuroraLimitless:GlobalVacuumTimeExchange
Le processus échange des données d’instantané afin de prendre en charge l’opération de vacuum.
### Causes
Les nœuds de Limitless Database échangent les données relatives à l’heure du plus ancien instantané actif avec d’autres nœuds, afin de calculer le moment de coupure correct pour l’exécution du vacuum.
### Action
Aucune action supplémentaire n’est requise.
## Événement d’attente AuroraLimitless:DistributedTransactionMonitorGather
Le processus collecte les métadonnées des transactions à partir d’autres nœuds pour faciliter le nettoyage des transactions distribuées.
### Causes
Les nœuds de Limitless Database échangent les métadonnées de transaction avec d’autres nœuds afin de déterminer à quel moment l’état des transactions distribuées peut être purgé.
### Action
Aucune action supplémentaire n’est requise.
## Événement d’attente AuroraLimitlessActivity:AdminTaskSchedulerMain
En attente dans la boucle principale du processus du planificateur de tâches.
## Événement d’attente AuroraLimitlessActivity:AdminTaskExecutorMain
En attente dans la boucle principale du processus d’exécuteur de tâches.
## Événement d’attente AuroraLimitlessActivity:AdminTaskMonitorMain
En attente dans la boucle principale du processus de surveillance de tâches.
## Événement d’attente AuroraLimitlessActivity:DatabaseCleanupMonitorMain
En attente dans la boucle principale du processus de surveillance du nettoyage de la base de données.
## Événement d’attente AuroraLimitlessActivity:TopologyCleanupMonitorMain
En attente dans la boucle principale du processus de surveillance du nettoyage de la topologie.
## Événement d’attente AuroraLimitlessActivity:ToplogyChangeMonitorMain
En attente dans la boucle principale du processus de surveillance des changements de topologie.
## Événement d’attente AuroraLimitlessActivity:DistributedTransactionMonitorMain
En attente dans la boucle principale du processus de surveillance des transactions distribuées.
## Événement d’attente AuroraLimitlessActivity:GlobalVacuumMonitorMain
En attente dans la boucle principale du processus de surveillance du vacuum global.
# Construire pour l'efficacité grâce aux fonctions
Les fonctions définies par l'utilisateur ne sont pas optimisées par défaut pour une seule partition, mais elles peuvent être configurées pour s'exécuter en tant qu'opérations sur une seule partition. Les fonctions peuvent encapsuler la logique et garantir son exécution de manière optimisée pour une seule partition.
## Pourquoi les opérations sur une seule partition sont importantes
L'utilisation des ressources est importante pour les performances et la rentabilité. Les opérations sur une seule partition utilisent nettement moins de ressources que les opérations entre partitions. Par exemple, lors de l'exécution d'une fonction pour insérer un million de lignes, l'exécution d'une partition unique en utilise environ 90,5 ACUs contre 126,5 ACUs pour l'exécution entre partitions, soit une amélioration de 35 % de l'efficacité des ressources.
L'exécution d'une partition unique fournit également :
+ Débit 35 % supérieur à celui des opérations cross-shard
+ Des temps de réponse plus prévisibles
+ Meilleure évolutivité à mesure que les données augmentent
## Opérations et fonctions d'une seule partition
Les fonctions s'exécutent sur des partitions lorsque l'une de ces conditions préalables est remplie :
+ La fonction est créée de manière immuable et incluse dans une requête optimisée pour une seule partition
+ La fonction est distribuée par un utilisateur
Les fonctions qui s'exécutent sur des partitions sont plus performantes et évolutives car elles s'exécutent là où se trouvent les données.
## Fonctions et volatilité
Pour vérifier la volatilité d'une fonction, utilisez cette requête sur les tables système de PostgreSQL :
```
SELECT DISTINCT nspname, proname, provolatile
FROM pg_proc PRO
JOIN pg_namespace NSP ON PRO.pronamespace = NSP.oid
WHERE proname IN ('random', 'md5');
```
Exemple de sortie :
```
nspname | proname | provolatile
------------+---------+-------------
pg_catalog | md5 | i
pg_catalog | random | v
(2 rows)
```
Dans cet exemple, `md5()` est immuable et `random()` volatil. Cela signifie qu'une instruction optimisée pour une partition unique qui inclut `md5()` reste optimisée pour une seule partition, contrairement à une instruction qui inclut ne l'est pas. `random()`
Exemple avec fonction immuable :
```
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)
```
Exemple avec fonction volatile :
```
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)
```
La sortie indique que cela `md5()` est poussé vers le bas et exécuté en tant qu'optimisation pour une seule partition, alors que ce `random()` n'est pas le cas.
## Fonctions de distribution
Une fonction qui accède aux données d'une seule partition doit s'exécuter sur cette partition pour améliorer les performances. La fonction doit être distribuée et la signature de la fonction doit inclure la clé de partition complète : toutes les colonnes de la clé de partition doivent être transmises en tant que paramètres à la fonction.
Exemple de fonction :
```
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;
```
Avant la distribution, la fonction n'est pas optimisée pour un seul fragment :
```
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)
```
Pour distribuer la fonction :
```
SELECT rds_aurora.limitless_distribute_function(
's1.func1(bigint,bigint,character)',
ARRAY['param_a','param_b','param_c'],
's1.t1'
);
```
Après distribution, la fonction est optimisée pour une partition unique :
```
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)
```
Vous pouvez confirmer l'optimisation d'une partition unique en cochant la `sso_calls` colonne dans : `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)
```
## Fonctions et modèles d'efficacité
L'exécution de la logique à proximité des données est plus efficace, et les fonctions jouent un rôle clé à cet égard. Il existe deux principaux cas d'utilisation pour améliorer l'efficacité grâce aux fonctions :
1. Extraction d'une clé de partition à partir de données complexes pour invoquer une fonction distincte optimisée pour une partition unique
1. Transformation des charges de travail entre partitions en partitions optimisées pour une seule partition en séparant la logique entre partitions des instructions optimisées pour une seule partition
### Extraction d'une clé de partition à partir de données complexes
Prenons l'exemple d'une fonction avec signature `s3.func3(p_json_doc json)` qui effectue plusieurs opérations de base de données. Ces opérations s'exécuteront sur toutes les partitions au sein d'une transaction qui couvre toutes les partitions. Si le document JSON contient la clé de partition, vous pouvez créer une fonction optimisée pour une partition unique pour effectuer les opérations de base de données.
Motif original :
```
s3.func3(p_json_doc json)
database operation 1;
database operation 2;
database operation 3;
```
Motif optimisé :
```
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ù la fonction interne effectue :
```
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;
```
Dans ce modèle, la clé de partition est encapsulée dans un type de données complexe ou déductible à partir d'autres paramètres. La logique, l'accès aux données et les fonctions peuvent déterminer, extraire ou construire la clé de partition, puis invoquer une fonction optimisée pour une seule partition qui exécute des opérations concernant une seule partition. Comme l'interface de l'application ne change pas, l'optimisation est relativement facile à tester.
### Interférer la clé de partition à d'autres fonctions ou données
Un autre modèle de conception s'applique lorsque la logique ou l'accès aux données calcule ou détermine la clé de partition. Cela est utile lorsqu'une fonction peut être exécutée sur une seule partition pour la plupart des invocations, mais qu'elle nécessite parfois une exécution entre partitions.
Motif 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;
```
Modèle optimisé avec fonctions distinctes :
```
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';
```
Demandez ensuite à la fonction principale d'appeler la version optimisée pour une partition unique ou la version pour une partition croisée :
```
IF all_whid_local THEN
SELECT NEWORD_sso(…) INTO no_s_quantity;
ELSE
SELECT NEWORD_crosshard(…) INTO no_s_quantity;
END IF;
```
Cette approche permet à la majorité des invocations de bénéficier de l'optimisation d'une partition unique tout en conservant un comportement correct dans les cas nécessitant une exécution entre partitions.
## Vérification des opérations sur une seule partition
`EXPLAIN`À utiliser pour vérifier si une instruction est optimisée pour une partition unique. La sortie indique explicitement « Single Shard Optimized » pour des opérations optimisées.
Invocation croisée avant distribution :
```
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
```
Invocation d'une partition unique après distribution :
```
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
```
La différence entre les temps d'exécution démontre les avantages en termes de performances de l'optimisation d'une partition unique.