Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je remet le sujet de maintenance que j'ai demandé de l'aide et j'ai eu des réponse de "rjuju" et "gleu", je les remercie encore.
Après avoir ajuster les paramètres spécifiques de quelques relations (tables):
AUTOVACUUM_ANALYZE_SCALE_FACTOR
AUTOVACUUM_VACUUM_SCALE_FACTOR
AUTOVACUUM_FREEZE_MAX_AGE
Ordonnancer un traitement VACUUM/ANALYZE régulier ciblé.
=> J'ai bénéficié un résultat bien correcte, c'est le moins qu'on puisse le dire.
Je signale aussi que j'ai pu bénéficié des mise à jours HOT des lignes et ça fonctionne bien aussi. Donc l'augmentation de la taille des tables est correcte et le seuil du "bloat" aussi
Le seul bémol c'est qu'au niveau des indexes l'augmentation de la taille est conséquent.
Étant en version 11.9, ne pouvant pas bénéficier de l'option (concurrently '12+'), ne pouvant pas utiliser "pg_repack ou autres outils, je ne peux que faire un "REINDEX 'index xxxxx'"!
Le problème que je n'ai pas de fenêtre de maintenance (application 7/24).
En pensant faire un "pg_terminate_backend()" puis lancer un reindex derrière et refaire ceci pour chaque index, le risque est de perdre les transactions en cours.
Je peux aussi essayer de récupérer les transactions en allant les chercher avant le "pg_terminate_backend()" dans "pg_stat_activity.query" mais certaines requêtes ont des variables pour des valeurs non connues de type (INSERT into tablename col1 col2... values ($1,$2,$3...etc.) les UPDATE aussi).
Ma question:
* Y a t il une (des) idée(s) afin de passer entre les goutes:
- Passer le ré-index de qq tables (temps estimé <30 min.) en évitant en éventuel blocage.
- Une façon plus fiable pour récupérer les transactions avortées lors de la réindexation "pg_terminate_back_end".
Par avance merci
B. LEMJID
Hors ligne
Le mieux est de faire un CREATE INDEX CONCURRENTLY, puis de supprimer l'ancien index. Cependant, cela ne fonctionnera pas pour les index des contraintes.
Guillaume.
Hors ligne
Merci Guillaume pour cette proposition.
En revanche je suis toujours embêté pour les contraintes.
Merci encore
Hors ligne
Il ne vous reste plus qu'à mettre à jour votre version de PostgreSQL 
Guillaume.
Hors ligne
Pour réindexer des index sans avoir de fenêtre de maintenance, vous pouvez utiliser une technique appelée "index swapping". Cette technique consiste à créer un nouvel index en arrière-plan, à renommer l'ancien index avec un nom temporaire, puis à renommer le nouvel index avec le nom de l'ancien index. De cette manière, les requêtes en cours ne sont pas perturbées, car elles continuent d'utiliser l'ancien index jusqu'à ce que la renommée soit terminée.
Voici les étapes à suivre pour utiliser cette technique:
1) Créez un nouvel index sur la même colonne que l'index à réindexer. Vous pouvez créer cet index en arrière-plan en ajoutant l'option CONCURRENTLY à la commande CREATE INDEX.
2) Renommez l'ancien index en utilisant une commande ALTER INDEX pour lui donner un nom temporaire. Par exemple, vous pouvez le renommer en "nom_de_l_index_temp".
3) Renommez le nouvel index créé à l'étape 1 en utilisant une commande ALTER INDEX pour lui donner le nom de l'ancien index. Par exemple, vous pouvez le renommer en "nom_de_l_index".
4) Supprimez l'index temporaire créé à l'étape 2.
Cela devrait vous permettre de réindexer vos index sans perturber les transactions en cours.
En ce qui concerne la récupération des transactions avortées lors de la réindexation, il n'y a malheureusement pas de solution fiable à 100%. Vous pouvez utiliser la table pg_stat_activity pour trouver les transactions en cours et essayer de les récupérer en exécutant la même commande après la réindexation. Cependant, certaines transactions peuvent être perdues de cette manière.
Dernière modification par Raoka (09/05/2023 14:00:02)
Hors ligne
Pages : 1
