PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 29/06/2016 21:31:32

Mlan2
Membre

pg_restore

Je tente désespéremment à restaurer un ensemble des tables issues d'une autre base de données, à partir d'un fichier dump que j'ai généré à partir de la commande pg_dump exécuté sur l'autre base de données.

commande exécutée pour la génération du dump :

pg_dump -U test -t table1 -t table2 -t table3 -t table4 -t table5 -t table6 -t table7 -t table8 -Fct -w -f test_tab.dmp

Commande exécutée pour la restauration du dump :

pg_restore -Uuser2 -Ft -w -f test_tab.dmp

La commande est exécutée dans une fenêtre de console (plate forme windows, postgreSQL 9.4), mais ne se termine jamais.
Aucune activité des processeurs, un kill de la commande est nécessaire pour mettre fin à celle-ci.
Aucune trace dans le fichier log de postgreSQL du répertoire pg_log.

Que faire pour mieux diagnostiquer le problème et le résoudre ?

D'avance merci de votre retour.

Dernière modification par Mlan2 (29/06/2016 21:32:43)

Hors ligne

#2 29/06/2016 23:03:07

rjuju
Administrateur

Re : pg_restore

Bonjour,


pour pg_restore l'option -f spécifie le fichier de sortie, non le fichier à restaurer :


-f nom_fichier, --file=filename

    Spécifie le fichier en sortie pour le script généré ou pour la liste lorsqu'elle est utilisée avec -l. Par défaut, il s'agit de la sortie standard.  p


Regardez http://docs.postgresql.fr/9.4/app-pgrestore.html pour avoir la documentation entiière de cet outil.

Hors ligne

#3 30/06/2016 10:50:51

Mlan2
Membre

Re : pg_restore

Merci du retour,

La commande s'exécute  à présent, je constate sur la console de lancement, un défilement du déroulement du script.

Mais le résultat obtenu n'est pas celui attendu, car la table à recharger reste vide, je l'avais vidée dans les 2 bases avant de lancer la commande pour m'assurer du chargement à partir du dump.

Dans l'exemple, la table à recharger se nomme : plpacti.

Ci-dessous, la commande lancée :

pg_restore -Uspie -O -t plpacti -Ft -w test_tab.dmp >trt.log

Rappel du but à atteindre :
.Recharger une ou plusieurs tables à partir d'un fichier dump issu d'une base de données se nommant : test, dans une base de données différente se nommant : spie.


J'ai utilisé l'option -O afin de ne pas reprendre les informations du owner initial, en espérant que le owner retenu soit celui issu de la connexion.

Ci-dessous, un extrait du fichier trt.log :

--
-- PostgreSQL database dump
--

SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;

SET search_path = public, pg_catalog;

SET default_tablespace = '';

SET default_with_oids = true;

--
-- Name: plpacti; Type: TABLE; Schema: public; Owner: -; Tablespace:
--

CREATE TABLE plpacti (
    matri character varying(10) NOT NULL,
    dat timestamp(3) without time zone NOT NULL,
    hdeb character varying(4) NOT NULL,
    hfin character varying(4),
    codelieu character varying(10),
    codequal character varying(10),
    jour smallint,
    novac smallint,
    fixe character varying(1),
    valide character varying(1),
    prispost integer,
    finpost integer,
    duraff integer,
    flgmot character varying(1)
);


--
-- Data for Name: plpacti; Type: TABLE DATA; Schema: public; Owner: -
--

COPY plpacti (matri, dat, hdeb, hfin, codelieu, codequal, jour, novac, fixe, valide, prispost, finpost, duraff, flgmot) FROM stdin;
1700935    2016-06-06 00:00:00    0900    1200    00006621    V    1    1    0         0    0    180    0
0300209    2016-05-13 00:00:00    1148    1500    00016101    V    5    1    0         0    0    192    0
000001    2016-01-18 00:00:00    0800    1200    00006616    V    1    1    0         0    0    240    0
000001    2016-01-18 00:00:00    1400    1800    00006616    V    1    2    0         0    0    240    0
000001    2016-01-19 00:00:00    0800    1200    00006616    V    2    1    0         0    0    240    0
\.


--
-- PostgreSQL database dump complete
--

Quel peut être l'origine de mon problème ?

D'avance merci de votre retour.

Hors ligne

#4 30/06/2016 15:38:21

arthurr
Membre

Re : pg_restore

oups : mal lu

Dernière modification par arthurr (30/06/2016 15:39:18)

Hors ligne

#5 30/06/2016 21:49:44

gleu
Administrateur

Re : pg_restore

Vous oubliez d'indiquer dans quelle base vous voulez restaurer votre sauvegarde. C'est pour ça que vous récupérez le script SQL à exécuter dans votre fichier de log. Bref, vous devez utiliser l'option -d.


Guillaume.

Hors ligne

#6 01/07/2016 10:13:49

Mlan2
Membre

Re : pg_restore

Merci du retour,

J'avais  réalisé, depuis mon dernier message, un essai en utilisant l'option -d<nom de base>, mais la restauration s'effectue malgré tout dans le schéma d'origine.

Aussi, j'ai imaginé une possibilité de générer le dump sans les informations de schéma.
J'ai ajouté l'option -O dans la commande de pg_dump comme ci-dessous :

pg_dump -h ${PGSERVEUR} -U ${PGUSR} -p ${PGPORT} -Ft -O -f Data_sgbd.dmp ${PGDB}

Là encore, la restauration s'effectue dans le schéma d'origine.

pg_restore -Uspie -dSPIE -c -O -Ft -v  -w Data_sgbd.dmp >ml.log

Aussi, quelle est la bonne pratique pour restaurer un dump appartenant à un schéma d'origine, vers un schéma différent ?

Un autre point que j'ai essayé d'approfondir est la possibilité d'associer un schéma par défaut à un utilisateur.

Est-ce possible ?
Il semble que le schéma public soit toujours le schéma par défaut.
Pouvez-vous le confirmer ?

D'avance merci de votre retour.

Hors ligne

#7 01/07/2016 10:22:00

ruizsebastien
Membre

Re : pg_restore

Bonjour,

Aujourd'hui il n'y a pas de possibilité native pour faire un import d'un schéma vers un schéma différent (comme le remap d'Oracle).
J'ai pour ma part développé des scripts pour le faire. l'idée est de sortir le DDL avec pg_dump et de le modifier avec des commandes sed, d'appliquer ce nouveau DDL et d'importer ensuite les données.
Ça demande du boulot mais c'est faisable.


Cordialement,

Sébastien.

Hors ligne

#8 01/07/2016 11:24:02

Mlan2
Membre

Re : pg_restore

Merci du retour,

Si la restauration d'un schéma vers un autre n'est pas possible simplement, l'idée serait de définir ce schéma restauré comme le schéma par défaut de l'utilisateur, ceci afin de ne pas devoir préciser systématiquement le nom du schéma dans le préfixe des objets de type table ou autre.

Comment le réaliser simplement pour une exécution à partir de psql ?

Hors ligne

#9 01/07/2016 14:05:34

gleu
Administrateur

Re : pg_restore

L'option -O permet de ne pas s'occuper du propriétaire des objets. Ça n'a rien à avoir avec les schémas (je suppose que vous avez un background Oracle, mais Oracle et PostgreSQL n'ont pas du tout le même comportement au niveau schéma/user).

Il est possible d'associer un schéma par défaut à un utilisateur. Le plus simple est de créer un schéma du nom de l'utilisateur (ce n'est pas fait automatiquement, voir plus haut, pas le même comportement, blabla). Sinon, on peut modifier le search_path de l'utilisateur pour qu'il pointe vers le schéma qu'on souhaite associer à cet utilisateur.

Sébastien a raison sur le fait qu'on ne puisse pas importer une sauvegarde dans un schéma spécifique. Même si vous précisez un schéma par défaut pour l'utilisateur, la restauration surcharge cela. Donc pour le faire, il faut absolument modifier le script SQL.


Guillaume.

Hors ligne

Pied de page des forums