Discussion :

[MrSaladin]

Bonjour,

J'ai un petit soucis d'import export avec mes bases postgres.
j'ai un serveur sous redhat avec postgres 7.2 ou 7.3 je sais plus
ensuite j'ai un PC sous XP avec postgres 8.1

je voudrais faire un export complet de la base sous postgres 7.2 pour l'importer dans postgres 8.1...

j'ai donc fait : pg_dump -i -h localhost -p 5555 -U postgres -F c -b -v-c f /tmp/Mabase.backup Mabase

ensuite je vais sur le PC avec XP
je fais un createdb -U postgres Mabase et ensuite un pg_restore -i -h localhost -p 5555 -U postgres -F c Mabase.backup Mabase

et là j'ai trois tonnes de messages d'erreurs qui défilent, à la fin toute la structure de la base est bien créé mais elle est vide....

que faut-il faire de plus ? rajouter l'option create dans le pg_dump ???

pour info, sur le PC XP j'ai 1 autre base postgres et j'arrive, avec les même commandes, à faire un export de cette base pour l'importer dans une nouvelle base créé comme je dis au dessus...

donc si vous avez une idée, je suis preneur !
merci d'avance
MrSaladin

[GrandFather]

Bonjour,

il m'est déjà arrivé d'avoir ce genre de problème avec Postgres 7.3...

En fait, dans certains cas, pg_dump s'emmêle un peu les pinceaux dans le choix de l'ordre dans lequel la création des tables/séquences/fonctions/vues ou l'intégration des données (avec COPY) doit s'effectuer. Il peut par exemple mettre la création d'une vue avant la création des tables dont elle est composée, ce qui provoque évidemment l'échec de la création de la vue et au final un schéma de base incomplet. Ce problème est référencé (il est même mentionné dans la doc de Postgres 7.x), et se pose généralement pour des bases plutôt complexes.

Dans ton cas si la structure est a priori ok (je t'invite toutefois à t'en assurer complètement), c'est que le problème se situe au niveau de l'ordre de la récupération des données qui ne doit pas respecter une contrainte de clé étrangère dans une (ou plusieurs) tables. Si c'est cela, pas d'autre solution que d'éditer manuellement le script SQL pour replacer les commandes dans le bon ordre. Il faut par contre que tu abandonnes le format binaire pour ton dump (sélectionné avec l'option -b) et passer au format texte pour accéder aux commandes SQL.

[MrSaladin]

bonjour,

merci pour ces infos.

donc en fait j'ai refait un pg_dump avec l'option -C,
maintenant la creation se passe bien, c'est au moment de restaurer les données que ca plante....
j'ai essayé de faire un pg_dump -a, c'est pareil....

MrSaladin

[Spoutnik]

par expérience, quand ca merde, ajoute l'option '-d' voire '-D' lorsque tu crée ton dump de base.
C'est plus lent, mais ca plante moins souvent, en particulier lors de changements de version de pg.

++

[MrSaladin]

effectivement c'est bien plus long !
le dump non à part qu'il est un peu plus gros, par contre le restore ca fait 40min qu'il tourne !
....des que c'est fini je vous tiens au courant !

merci

[GrandFather]

le dump non à part qu'il est un peu plus gros, par contre le restore ca fait 40min qu'il tourne !

Rien d'étonnant, plutôt que d'utiliser COPY qui récupère toutes les données d'une table en une seule transaction, cette option utilise à la place un INSERT par enregistrement. Pour peu qu'en plus tu aies des triggers et des checks sur ta table, bonjour la lenteur...

D'autant que si comme je l'ai suggéré le souci vient d'un ordre erroné de chargement des tables, ça ne va pas régler le problème...

[Spoutnik]

Rien d'étonnant, plutôt que d'utiliser COPY qui récupère toutes les données d'une table en une seule transaction, cette option utilise à la place un INSERT par enregistrement. Pour peu qu'en plus tu aies des triggers et des checks sur ta table, bonjour la lenteur...

on est bien d'accord Mais entre une restauration qui marche pas et une restauration qui prend du temps Quitte à désactiver les triggers/index

D'autant que si comme je l'ai suggéré le souci vient d'un ordre erroné de chargement des tables, ça ne va pas régler le problème...

Idem , on est d'accord, mais MrSaladin a précisé que visiblement, c'est maintenant à la restauration des données que cela plante, d'où cette méthode peu orthodoxe

[MrSaladin]

bon alors hier soir en partant c'était pas fini alors j'ai laissé tourné mais ce matin c'était toujours bloqué sur la même table, j'ai fait un CTRL C, ça a continué rapidement sur les autres tables puis il y a eu des tonnes de messages d'erreurs : 400000 warnings !
alors que le dump fait 8Mo seulement...

[MrSaladin]

Dans ton cas si la structure est a priori ok (je t'invite toutefois à t'en assurer complètement), c'est que le problème se situe au niveau de l'ordre de la récupération des données qui ne doit pas respecter une contrainte de clé étrangère dans une (ou plusieurs) tables. Si c'est cela, pas d'autre solution que d'éditer manuellement le script SQL pour replacer les commandes dans le bon ordre. Il faut par contre que tu abandonnes le format binaire pour ton dump (sélectionné avec l'option -b) et passer au format texte pour accéder aux commandes SQL.

après vérif, la structure parait correcte
j'ai donc refait l'export sans l'option -b, j'ouvre le fichier mais comment voir ce qui va pas ?
c'est chaud....surtout quand on connait pas grand chose aux BDD....

merci
MrSaladin

[GrandFather]

c'est chaud....surtout quand on connait pas grand chose aux BDD....

Euh, oui, dans ce cas, c'est très chaud... Le 1er message d'erreur (attention, ERROR, pas WARNING) doit t'indiquer quelle est la contrainte qui est violée. Ne tiens pas compte des messages suivants, ils sont le plus souvent la conséquence du premier.

Par exemple, imagine que tu restaures une table A et une table B, la table B contenant des clés étrangères pointant sur la table A. L'ordre normal de restauration est donc A puis B. Si pg_dump se trompe, il tentera de restaurer B puis A, et le script échouera inévitablement avec un message d'erreur indiquant la violation d'une contrainte d'intégrité. Il suffira d'éditer le script et de replacer les commandes SQL dans le bon ordre pour que cela fonctionne.

[MrSaladin]

je vais essayer de regarder de plus pres....
merci