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. # Aspirer et analyser les tables manuellement Si votre base de données est aspirée par le procédé d'aspiration automatique, il est recommandé d'éviter d'utiliser trop fréquemment des aspirateurs manuels sur l'ensemble de la base de données. Un aspirateur manuel peut entraîner des I/O charges inutiles ou des pics de charge du processeur, et peut également ne pas éliminer les tuples morts. N'utilisez les aspirateurs manuels que si cela est vraiment nécessaire, par exemple lorsque le ratio de tuples vivants par rapport aux tuples morts est faible ou lorsqu'il y a de longs intervalles entre les aspirateurs automatiques. table-by-table En outre, vous devez utiliser des aspirateurs manuels lorsque l'activité de l'utilisateur est minimale. Autovacuum tient également à jour les statistiques d'une table. Lorsque vous exécutez la `ANALYZE` commande manuellement, elle reconstruit ces statistiques au lieu de les mettre à jour. La reconstruction des statistiques lorsqu'elles sont déjà mises à jour par le processus d'aspiration automatique normal peut entraîner une utilisation des ressources du système. Nous vous recommandons d'exécuter les commandes [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) et [ANALYZE](https://www.postgresql.org/docs/current/sql-analyze.html) manuellement dans les scénarios suivants : + Pendant les heures de pointe, sur des tables plus achalandées, l'aspiration automatique peut ne pas être suffisante. + Immédiatement après le chargement groupé des données dans la table cible. Dans ce cas, l'exécution `ANALYZE` manuelle reconstruit complètement les statistiques, ce qui est une meilleure option que d'attendre le démarrage de l'autovacuum. + Pour aspirer des tables temporaires (Autovacuum ne peut pas y accéder). Pour réduire l' I/O impact de l'exécution des `ANALYZE` commandes `VACUUM` et sur l'activité simultanée de la base de données, vous pouvez utiliser le `vacuum_cost_delay` paramètre. Dans de nombreuses situations, les commandes de maintenance telles que `VACUUM` et `ANALYZE` ne doivent pas nécessairement être exécutées rapidement. Toutefois, ces commandes ne devraient pas interférer avec la capacité du système à effectuer d'autres opérations de base de données. Pour éviter cela, vous pouvez activer les délais de mise sous vide basés sur les coûts en utilisant le `vacuum_cost_delay` paramètre. Ce paramètre est désactivé par défaut pour les `VACUUM` commandes émises manuellement. Pour l'activer, réglez-le sur une valeur différente de zéro. ## Exécution des opérations d'aspiration et de nettoyage en parallèle L'option de `VACUUM` commande [PARALLEL](https://www.postgresql.org/docs/current/sql-vacuum.html) utilise des travailleurs parallèles pour les phases d'aspiration et de nettoyage des index et est désactivée par défaut. Le nombre de travailleurs parallèles (le degré de parallélisme) est déterminé par le nombre d'index de la table et peut être spécifié par l'utilisateur. Si vous exécutez `VACUUM` des opérations parallèles sans argument entier, le degré de parallélisme est calculé en fonction du nombre d'index de la table. Les paramètres suivants vous aident à configurer l'aspiration parallèle dans Amazon RDS for PostgreSQL et la compatibilité avec Aurora PostgreSQL : + [max\_worker\_processes définit le nombre maximum de processus](https://www.postgresql.org/docs/current/runtime-config-resource.html) de travail simultanés. + [min\_parallel\_index\_scan\_size](https://www.postgresql.org/docs/current/runtime-config-query.html) définit la quantité minimale de données d'index qui doivent être analysées pour qu'une analyse parallèle soit prise en compte. + [max\_parallel\_maintenance\_workers](https://www.postgresql.org/docs/current/runtime-config-resource.html) définit le nombre maximum de travailleurs parallèles pouvant être démarrés par une seule commande utilitaire. **Note** L'`PARALLEL`option est utilisée uniquement à des fins d'aspiration. Cela n'affecte pas la `ANALYZE` commande. L'exemple suivant illustre le comportement d'une base de données lorsque vous l'utilisez manuellement `VACUUM` et `ANALYZE` sur une base de données. Voici un exemple de tableau dans lequel l'aspiration automatique a été désactivée (à des fins d'illustration uniquement ; la désactivation de l'aspiration automatique n'est pas recommandée) : ``` create table t1 ( a int, b int, c int ); alter table t1 set (autovacuum_enabled=false); ``` ``` apgl=> \d+ t1 Table "public.t1" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description --------+---------+-----------+----------+---------+---------+--------------+------------- a | integer | | | | plain | | b | integer | | | | plain | | c | integer | | | | plain | | Access method: heap Options: autovacuum_enabled=false ``` Ajoutez 1 million de lignes au tableau t1 : ``` apgl=> select count(*) from t1; count 1000000 (1 row) ``` Statistiques du tableau t1 : ``` select * from pg_stat_all_tables where relname='t1'; -[ RECORD 1 ]-------+-------- relid | 914744 schemaname | public relname | t1 seq_scan | 0 seq_tup_read | 0 idx_scan | idx_tup_fetch | n_tup_ins | 1000000 n_tup_upd | 0 n_tup_del | 0 n_tup_hot_upd | 0 n_live_tup | 1000000 n_dead_tup | 0 n_mod_since_analyze | 1000000 last_vacuum | last_autovacuum | last_analyze | last_autoanalyze | vacuum_count | 0 autovacuum_count | 0 analyze_count | 0 autoanalyze_count | 0 ``` Ajoutez un index : ``` create index i2 on t1 (b,a); ``` Exécutez la `EXPLAIN` commande (Plan 1) : ``` Bitmap Heap Scan on t1 (cost=10521.17..14072.67 rows=5000 width=4) Recheck Cond: (a = 5) → Bitmap Index Scan on i2 (cost=0.00..10519.92 rows=5000 width=0) Index Cond: (a = 5) (4 rows) ``` Exécutez la `EXPLAIN ANALYZE` commande (Plan 2) : ``` explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Bitmap Heap Scan on t1 (actual time=0.023..0.024 rows=1 loops=1) Recheck Cond: (b = 5) Heap Blocks: exact=1 Buffers: shared hit=4 → Bitmap Index Scan on i2 (actual time=0.016..0.016 rows=1 loops=1) Index Cond: (b = 5) Buffers: shared hit=3 Planning Time: 0.054 ms Execution Time: 0.076 ms (9 rows) ``` Les `EXPLAIN ANALYZE ` commandes `EXPLAIN ` et affichent des plans différents, car l'aspirateur automatique a été désactivé sur la table et la `ANALYZE` commande n'a pas été exécutée manuellement. Mettons maintenant à jour une valeur dans le tableau et régénérons le `EXPLAIN ANALYZE` plan : ``` update t1 set a=8 where b=5; explain (analyze,buffers,costs off) select a from t1 where b = 5; ``` La `EXPLAIN ANALYZE` commande (Plan 3) affiche désormais : ``` apgl=> explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Bitmap Heap Scan on t1 (actual time=0.075..0.076 rows=1 loops=1) Recheck Cond: (b = 5) Heap Blocks: exact=1 Buffers: shared hit=5 → Bitmap Index Scan on i2 (actual time=0.017..0.017 rows=2 loops=1) Index Cond: (b = 5) Buffers: shared hit=3 Planning Time: 0.053 ms Execution Time: 0.125 ms ``` Si vous comparez les coûts entre le plan 2 et le plan 3, vous constaterez les différences entre les délais de planification et d'exécution, car nous n'avons pas encore collecté de statistiques. Exécutons maintenant un manuel `ANALYZE` sur la table, puis vérifions les statistiques et régénérons le plan : ``` apgl=> analyze t1 apgl→ ; ANALYZE Time: 212.223 ms apgl=> select * from pg_stat_all_tables where relname='t1'; -[ RECORD 1 ]-------+------------------------------ relid | 914744 schemaname | public relname | t1 seq_scan | 3 seq_tup_read | 1000000 idx_scan | 3 idx_tup_fetch | 3 n_tup_ins | 1000000 n_tup_upd | 1 n_tup_del | 0 n_tup_hot_upd | 0 n_live_tup | 1000000 n_dead_tup | 1 n_mod_since_analyze | 0 last_vacuum | last_autovacuum | last_analyze | 2023-04-15 11:39:02.075089+00 last_autoanalyze | vacuum_count | 0 autovacuum_count | 0 analyze_count | 1 autoanalyze_count | 0 Time: 148.347 ms ``` Exécutez la `EXPLAIN ANALYZE` commande (Plan 4) : ``` apgl=> explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Index Only Scan using i2 on t1 (actual time=0.022..0.023 rows=1 loops=1) Index Cond: (b = 5) Heap Fetches: 1 Buffers: shared hit=4 Planning Time: 0.056 ms Execution Time: 0.068 ms (6 rows) Time: 138.462 ms ``` Si vous comparez tous les résultats du plan après avoir analysé manuellement le tableau et collecté des statistiques, vous remarquerez que le plan 4 de l'optimiseur est meilleur que les autres et qu'il réduit également le temps d'exécution des requêtes. Cet exemple montre à quel point il est important d'exécuter des activités de maintenance sur la base de données. ## Réécriture d'une table entière avec VACUUM FULL L'exécution de la `VACUUM ` commande avec le `FULL` paramètre réécrit l'intégralité du contenu d'une table dans un nouveau fichier disque sans espace supplémentaire et renvoie l'espace inutilisé au système d'exploitation. Cette opération est beaucoup plus lente et nécessite un `ACCESS EXCLUSIVE` verrou sur chaque table. Il nécessite également de l'espace disque supplémentaire, car il écrit une nouvelle copie de la table et ne libère pas l'ancienne copie tant que l'opération n'est pas terminée. `VACUUM FULL`peut être utile dans les cas suivants :**** + Lorsque vous souhaitez récupérer une quantité importante d'espace sur les tables. + Lorsque vous souhaitez récupérer de l'espace dans des tables à clés non primaires. Nous vous recommandons de l'utiliser `VACUUM FULL` lorsque vous avez des tables à clés non primaires, si votre base de données peut tolérer des interruptions de service. Comme `VACUUM FULL` le verrouillage est plus important que les autres opérations, il est plus coûteux de l'exécuter sur des bases de données cruciales. Pour remplacer cette méthode, vous pouvez utiliser l'`pg_repack `extension décrite dans la [section suivante](pg-repack.md). Cette option est similaire `VACUUM FULL` mais nécessite un verrouillage minimal et est prise en charge par Amazon RDS for PostgreSQL et par Aurora PostgreSQL compatible.