Vous n'êtes pas identifié(e).
Pages : 1
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
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.
Julien.
https://rjuju.github.io/
Hors ligne
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
oups : mal lu
Dernière modification par arthurr (30/06/2016 15:39:18)
Hors ligne
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
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
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
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
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
Pages : 1
