Vous n'êtes pas identifié(e).
Pages : 1
Bonjour rjuju,
Merci pour la confirmation, et la réponse avec un exemple
Cela semble plus simple que ce que j'imaginais.
Je vais essayer ça, et je reviens vous dire.
A plus tard
(et bon week-end tout le monde...)
Merci pour les explications.
Et est-ce que pg_dump peut créer un dump qui ne contienne que des tables?
Je n'ai pas la main la dessus, j'ai l'impression que l'on va me dire de faire avec ce que j'ai mais je pourrais toujours demander a ceux qui produisent cet export, si techniquement possible.
Bonjour,
Merci pour la réponse rapide.
Oui, désolé, je suis effectivement sur un pg_restore.
Au début, je pensais passer par psql, mais il semble que le type de fichiers que l'on va recevoir ( des *.backup ) ne corresponds pas, si j'ai bien compris.
Donc, on va tester cette idée de --list, je ne connais pas du tout le contenu de ce genre de fichiers et j'espère juste que on va pouvoir automatiser ce genre de tâche, car cela serait pour un import quotidien.
Un peu dommage qu'il n'y ait pas de fonctionalité native pour choisir d'importer uniquement un type d'objet...
@+
Bonjour,
Tout est dans le titre: est-il possible - comme avec Oracle - de faire un import en ligne de commande et de préciser que on ne veut importer qu'un seul type d'objets, comme les tables par exemple (toutes les tables, sans avoir a les citer précisemment)?
Merci!
@+
Bonjour,
Problème résolu avec un nouveau username / password chez la partie PostGreSQL.
Le mot de passe du premier contenait un "+", est-ce vraiment cela qui ne passait pas, je n'en sais rien - je ne saurais jamais d'ailleurs si il n'y avait pas un autre problème de leur côté.
M'enfin .. ça fonctionne maintenant, je passe à autre chose.
Merci pour ceux qui ont essayé de m'aider !
@+
Bonjour,
Merci de la réponse et le détail sur la partie "réseau".
Je comprends donc que selon toi la seule "vraie" erreur est liée soit à l'utilisateur soit au mot de passé, correct?
La partie postgresql du log est ici:
FATAL: password authentication failed for user "MY_USER"
qui est une erreur classique de login invalide ou mot de passe invalide.
=> C'est en soi quasi "impossible". Le mot de passe fonctionne bien, puisque la connexion ODBC utilise le même couple username/pasword avec succès: je peux même remonter des données dans Excel via cette connexion ODBC, comme je le disais précédemment.
Cela me donnerait l'impression alors que Oracle ne passe pas le bon mot de passe. Hors nous n'avons rien changé de notre côté / côté Oracle, et comme dit précédemment, les DBLink vers la précédente vers de PostGre DB fonctionnent.
La seule chose qui me venait à l'esprit est que le mot passe contient un caractère spécial que "Monseigneur" Oracle a décidé de ne pas traiter correctement.Le mot de passe contient effectivement un caractère spécial, un "+" ... bon, mais j'ai créé comme d'habitude mon DBLink en tenant compte de cela (en utilisant les "", comme precrit dans toutes les bonnes pharmacies Oracle). Je viens même de me refaire le DBLink, et veillant bien a ce que le user/password soit bon, rien à faire.
C'est à cause de ce caractère spécial que l'on a fait la demande à l'équipe gérant PostGre d'un nouveau username/password, sans caractères spéciaux, ceci afin de tester cette théorie.
Pour la petite histoire (vous allez me dire, on s'en fou, et vous n'auriez pas tord): cela fait une semaine qu'on a demandé cela, et on dirait qu'on leur a défrisé les poils du .. de .. enfin, bref, toujours rien. Je ne savais pas que sous PostGreSQL, cela prenait tant de temps de faire un user "read only" (avec des droit uniquement en "SELECT", sur une trentaine de tables, pas plus) sur une base même pas PROD ... rassurez-moi, ils se foutent de ma gueule, la, tout simplement?!?
J'espère, parce que du peu que j'ai vu (j'ai vraiment très peu de temps pour divaguer), ca à l'air bien sympa PostGre.
Bref, je parle, je parle, mais tout ceci ne me fait pas avancer ..
Je m'en vais chercher un ouvrage de magie noire, si aucune solution cohérente n'arrive cette semaine, j'utiliserai la manière forte !
;-)
Bonsoir ruizsebastien,
Je n'aurais pas de retour avant Lundi après midi, voire même que je devrais attendre Mardi. Et si tel est le cas, cela ne sera peut être pas encore des infos complèmentaire de la part de ceux qui gèrent PostGre, mais juste l'occasion de rappeler au "décideur" qu'on était censé avoir qqu'un avec qui collaborer.
En attendant, je ne ferme pas le sujet, et je continue a regarder aussi des solutions alternatives.
Bon week-end
V.
Bonjour,
Je vais pour le moment rester sur le fait que - comme tu le soulignes - la connexion annonce "establish" + le test avec Excel s'est fait sur la même machine qui héberge Oracle.
Maintenant ... Je reviens sur une de mes dernières questions:
"Du côté PostGreSQL, est-ce qu'il y a des choses qu'ils peuvent voir? Des logs particuliers que je pourrais leur demander de checker afin de faire avancer la chose?"
Mon idée est la suivante:
Excel remonte les données en n'utilisant que la connexion ODBC
Oracle lui a besoin en plus d'un DBLink, pour lequel il faut donner un user + password + tout un tas de petites choses pour la connexion.
Je me demandais donc si côté serveur PostGreSQL, ils pourraient voir par exemple mes essais infructueux dans Oracle, avec des messages particuliers dans un de leur logs. Ce qui me confirmerait - par exemple - que Oracle fait "de la merde" avec le mot de passe actuel (pour une raison inconnue actuellement) ou bien en fonction des messages trouvés on aurait un autre éclairage.
Savez vous si c'est possible? Si il existe un/des log(s) côté PostGre qui permettrait de voir ce qui se passe de leur côté?
Merci
V.
Bonjour,
Merci beaucoup pour vos réponses! ;-)
@Marc Cousin:
. Oui effectivement, j'ai fait les tests avec Excel sur la même machine ou est Oracle.
. Je comprends et je confirme que beaucoup de gens me renvoient "c'est donc un problème Oracle". Mais devinez quoi? Du côté Oracle, sachant que l'on a vérifié nos fichiers de config et que des DBLink tournent sur une version antérieure de PostGreSQL (PostgreSQL 9.1.24), on me renvoie "c'est donc un problème du côté PostGre" ... marrant comme situation.
Pour ce qui est des logs:
. alert.log ne me donne pas grand chose de particulier
. en revanche, j'ai bien une trace du côté "HS" (Oracle heterogeneous services), qui me donne ceci lors d'une tentative de "select":
Entered hgocont at 2018/02/23-11:14:03
HS_FDS_CONNECT_INFO = "MY_DSN"
RC=-1 from HOSGIP for "HS_FDS_CONNECT_STRING"
Entered hgogenconstr at 2018/02/23-11:14:03
dsn:MY_DSN, name:MY_USER
optn:
Entered hgocip at 2018/02/23-11:14:03
dsn:MY_DSN
Exiting hgocip, rc=0 at 2018/02/23-11:14:03
##>Connect Parameters (len=56)<##
## DSN=MY_DSN;
#! UID=MY_USER;
#! PWD=*
Exiting hgogenconstr, rc=0 at 2018/02/23-11:14:03
Entered hgopoer at 2018/02/23-11:14:04
hgopoer, line 233: got native error 101 and sqlstate 08001; message follows...
could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 4444?
FATAL: password authentication failed for user "MY_USER"
{08001,NativeErr = 101}
Exiting hgopoer, rc=0 at 2018/02/23-11:14:04
hgocont, line 2753: calling SqlDriverConnect got sqlstate 08001
Exiting hgocont, rc=28500 at 2018/02/23-11:14:04 with error ptr FILE:hgocont.c LINE:2773 ID:Something other than invalid authorization
Exiting hgolgon, rc=28500 at 2018/02/23-11:14:04 with error ptr FILE:hgolgon.c LINE:781 ID:Calling hgocont
hostmstr: 140737345662976: HOA After hoalgon
RPC Calling nscontrol(0), rc=0
hostmstr: 140737345662976: RPC Before Exit Agent
hostmstr: 140737345662976: HOA Before hoaexit
Entered hgoexit at 2018/02/23-11:14:04
Exiting hgoexit, rc=0
(j'ai du remplacer les noms donnés au dsn et au username, je peux pas faire autrement)
Ce qui m'interpelle est: LINE:2773 ID:Something other than invalid authorization
C'est ce qui me fait penser / craindre que cela ne soit pas réellement un problème d'authentification - mais je me trompe surement. D'ou mon interrogation sur un éventuel problème de "compatibilité".
Sinon, côté Oracle, l'erreur est:
ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 4444?
FATAL: password authentication failed for user "my_user"
{08001,NativeErr = 101}
ORA-02063: preceding 6 lines from LINK_MYDBLINK
Note: on passe en localhost / port 4444 car on a un tunnel géré via Stunnel. Ceci fonctionne avec les DBLink pointant sur l'ancienne version de PostGre (PostgreSQL 9.1.24)
@ruizsebastien:
Effectivement, je n'avais pas jeté un oeil au log du listener. Lorsque je tente un "select", il enregistre bien une info de connexion avec la mention "establish". J'aurais tendance a penser donc que c'est ok de ce côté (?).
Je n'ai pas la main sur la base PostGre, aucun accès direct aux serveurs ni aux configurations.
Sachant que j'ai fait un test réussi avec Excel et connexion ODBC sur la même machine que Oracle, se peut-il qu'il y ait un "truc bloquant" dans le fichier pg_hba.conf? Qu'est ce qui devrait être vérifié ici? (je ne connais pas PostGre, désolé)
Note: lorsque je tente un "select", je le fais sur une table sur laquelle j'ai bien les droits (vérifié via pgAdmin III) et je ne selectionne qu'un champs de type Integer, qui ne doit pas poser de problème particulier - ceci afin d'éviter le cas ou j'aurais pointé vers un table contenant des champs de type "inconnu" pour Oracle.
Du côté PostGreSQL, est-ce qu'il y a des choses qu'ils peuvent voir? Des logs particuliers que je pourrais leur demander de checker afin de faire avancer la chose?
Merci d'avance!
;-)
V.
Bonjour,
J'ai un problème sur un DB Link pour une connexion entre Oracle et PostgreSQL 9.4.13, via ODBC.
Pour le côté Oracle, nous sommes en 11g r2, sur Windows Server 2012 R2
Les DB sous PostGreSQL ne sont pas "chez nous", je n'ai pas la main dessus et je suis censé avoir uniquement des users en mode read-only; on passe par un "tunnel" (via Stunnel), puis connexion OBDC.
ODBC: drivers 10.01.00.00, et on part sur System DSN / PostGreSQL unicode (x64).
Nous avons déjà des connexions sur des DB qui tournent vers des bases sous PostgreSQL 9.1.24, tout fonctionne bien. Je vous passe les détails techniques sur Oracle, mais je pars du principe que nos configs côté Oracle pour cette nouvelle connexion sont bonnes.
Avec NodeJs, j'arrive a passer et a faire un "select" sur la base en PostgreSQL 9.4.13; je peux même afficher des données dans Excel via cette connexion ODBC, mais impossible depuis Oracle de faire un simple "select".
D'ou ma question sur un éventuel problème de compatibilité?
A tout hasard, il n'y a pas de la doc officielle qui traiterait des DB Link entre PostGreSQL et Oracle (en fonction des versions)?
Sinon, en cherchant sur le net, je suis tombé sur pleins d'autres sujets plus ou moins du même genre, avec un intervenant qui posait la question suivante:
". Has postgres been setup to allow remote connections?"
-> Je ne sais pas si cette question ferait sens dans mon cas, sachant que via la connection ODBC, je peux remonter des données dans Excel. J'ai l'impression que cela serait à côté de la plaque.
Pour info: pour des raisons qui me sont encore inconnues, les personnes s'occupant de la partie PostGreSQL sont quasi injoignables / difficile de discuter avec eux (pour rester poli). Donc dur pour moi de poser des questions et/ou d'obtenir des infos qui pourraient m'éclairer sur ce qui se passe, ceci afin d'écarter éventuellement un problème de config de leur côté (ce qui est déjà arrivé par le passé).
Voila, donc si jamais quelqu'un a une idée, merci d'avance !
Cordialement
V.
Pages : 1