Vous n'êtes pas identifié(e).
Pages : 1
Sinon avec un outil Oracle gratuit comme SQL Developper, on peut afficher les données des tables et les exporter directement en format CSV, qu'on peut ensuite réimporter dans Postgresql via COPY
Si tu n'as pas énormément de tables et qu'elles ne sont pas très volumineuses c'est encore le plus rapide, ça évite de devoir faire un développement PL/SQL spécifique
Merci pour ta réponse
J'ai étudié la piste de la résolution DNS inverse avec notre administrateur réseau et ça ne donne rien :
- la résolution inverse est bien activée
- nous avons même fait un test en créant une entrée DNS qui à partir de l'adresse IP renvoie vers le nom du serveur utilisé dans la chaîne de connexion, mais le problème apparaît toujours
J'ai même désactivé le paramètre log_hostname dans le postgresql.conf au cas où ça aurait pu influer mais sans résultat ...
C'est d'autant plus bizarre que sur certains de nos serveurs Postgresql le problème ne se pose pas alors qu'ils sont tous configurés de la même manière et sont dans le même LAN ...
Enfin bon en tout cas j'ai au moins la solution de contournement consistant à déclarer dans le fichier /etc/hosts les serveurs sur lesquels Postgresql est susceptible de se connecter en dblink
Merci pour ton aide en tout cas
Bonjour
Avec Postgresql 8.2 sous Linux, j'essaie d'utiliser la contrib dblink pour me connecter à une base distante. J'utilise la commande suivante :
select dblink_connect('host=serveur_distant port=5432 dbname=BDD_DISTANTE user=user_distant password=le_pwd');
Le problème c'est que quand le serveur_distant est déclaré dans mon fichier /etc/hosts, la connexion se fait instantanément
Par contre quand le serveur_distant n'est pas déclaré dans mon fichier /etc/hosts, la connexion met environ 1 minute.
Pourtant, même quand le serveur_distant n'est pas déclaré dans le /etc/hosts, j'arrive ç faire un ping qui est instantané et une connexion du type " psql -h serveur_distant -d BDD_DISTANTE" est instantanée aussi donc je ne pense pas que cela puisse venir du réseau ni du temps de réponse de notre serveur DNS
Y a-t-il une particularité avec la fonction dblink_connect qui pourrait expliquait qu'il mette 1 minute à m'ouvrir la connexion ?
Merci d'avance
Merci pour ton retour
Que veux-tu dire par "il a du mal à faire une restauration partielle" ?
Tu veux dire qu'il arrive qu'une restauration à un instant passé ne fonctionne pas avec pg_rman même si on a fait une sauvegarde full avec les wal ? Si c'est ça effectivement c'est très dissuasif pour mettre en production 
Comme j'utilise déjà RMAN pour Oracle, c'est aussi pour cela que je teste pg_rman, ça a l'air assez similaire et simple à utiliser
Je vous tiens au courant et vous ferai mon retour d'expérience ;-)
Marc, ton retour d'expérience m'intéresse également !
Bonjour
Je souhaiterais mettre en place l'outil pg_rman (http://code.google.com/p/pg-rman/) pour les sauvegardes/restaurations de mes bases de production
Quelqu'un a-t-il déjà eu l'occasion de l'utiliser ? Vos avis m'intéressent ! ;-)
Merci d'avance
Merci pour ta réponse
Est-ce prévu dans une prochaine version de Postgresql ?
Car je trouve très ennuyeux de devoir faire du débuggage "bas niveau" en mettant des RAISE partout dans le code PL/PgSQL, alors qu'une trace côté Postgresql permettrait tout de suite de voir les requêtes consommatrices du code ...
Bonjour
J'ai une fonction f en PL/PgSQL qui exécute des requêtes insert. Quand j'active la trace Postgresql (avec paramètres log_min_duration_statement, ... etc) et que j'exécute ma fonction, je vois juste dans la trace "select f(...)" mais pas les requêtes exécutées au sein de ma fonction, y a-t-il moyen de les afficher dans la trace en mettant les paramètres qui vont bien dans le postgresql.conf ?
Merci d'avance
Pages : 1
