Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je travaille sur des bases 8 et 9 sous CentOS.
J'ai un script de maintenance qui tourne le dimanche avec la commande : reindexdb -a
Cela fait 2 dimanches de suite que le script s'arrête sur erreur.
En consultant les logs, j'ai trouvé :
[local] 1641 2012-01-22 09:58:11 EAT REINDEX 2 ERROR: could not open relation with OID 2183444
[local] 1641 2012-01-22 09:58:11 EAT REINDEX 3 STATEMENT: REINDEX DATABASE toto;
Je précise que le dimanche précédent, l'OID était différent.
Comment remonter au nom de l'objet à partir de son OID ?
Est-ce que cela peut être lié au fait qu'il y a de l'activité le dimanche ?
Certains traitement créent et dropent des tables temporaires à la volée, est-ce lié ?
Comment gérer ce problème ?
Hors ligne
select relname from pg_class where oid= xxx ?
Les tables droppées à la volée peuvent faire ce genre d'erreur oui, vu que reindexdb fait son «inventaire» des tables à traiter au démarrage.
Marc.
Hors ligne
Bonjour Marc,
C'est bien la commande que j'ai utililsé pour trouver l'objet mais qui ne me retourne rien.
Y-a-t'il un moyen de gérer ce problème de reindexdb ?
Faire une réindexation plus ciblée ?
ou autre ?
Hors ligne
Si l'oid n'existe pas, c'est bien que la table a disparu.
Ça arrête la réindexation ? (jamais eu le pb 
)
Sinon, le plus simple c'est peut-être d'ignorer l'erreur non ?
Marc.
Hors ligne
Comment savoir si la réindexation s'est intérrompue ou pas ?
J'ai reçu un code retour différent de 0 dans mon script.
Hors ligne
reindexdb envoie un REINDEX DATABASE toto. Si l'ordre SQL échoue, vous récupérez une erreur. Et le REINDEX DATABASE s'arrête.
Si vous avez des suppressions de tables pendant la réindexation, il ne vous reste plus qu'à écrire votre script à vous pour la réindexation.
Marc.
Hors ligne
mais est ce que l'interruption est automatique?
Hors ligne
Oui.
Guillaume.
Hors ligne
ok merci beaucoup pour l'info
Hors ligne
Pages : 1
