Vous n'êtes pas identifié(e).
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.
Hors ligne
Bonjour,
Pas beaucoup d'idées, mais voila ce que ça m'inspire:
- Pas de raison que le driver odbc marche avec excel et pas avec oracle… vous utilisez une version récente du driver, qui devrait être compatible avec PG 9.4 (qui a déjà quelques années)
- Est-ce que votre connexion à partir d'excel est faite sur la machine oracle ? sinon, ça pourrait tout simplement être que le serveur Postgres distant n'autorise pas la connexion venant de l'IP du serveur Oracle
- Il n'y a pas à ma connaissance d'information sur monter un DB Link Oracle vers PostgreSQL du côté de la doc Postgres… ça serait plutôt, en toute logique, dans la doc d'Oracle, qu'on devrait trouver ça
- "Has postgres been setup to allow remote connections": manifestement oui, puisque vous vous connectez avec Excel. Mais PostgreSQL peut limiter les autorisations à se connecter à des plages d'IP par exemple
Par contre, vous avez peut-être des traces du dblink quelque part… dans le fichier alert ? dans network/trace ? ça fait longtemps que je ne fais plus d'Oracle malheureusement, mais il est à peu près sûr que soit vous avez déjà une trace quelque part, soit vous pouvez l'activer. Ça sera bien plus simple de débugguer si on a un message d'erreur.
Marc.
Hors ligne
bonjour,
Du côté Oracle vous pouvez checker le fichier listener.log.
Du côté PostgreSQL vous pouvez tenter de faire une connexion simple depuis le serveur Oracle pour voir si Postgres bloque l'IP du serveur Oracle au niveau du pg_hba.conf.
Cordialement,
Sébastien.
Hors ligne
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.
Dernière modification par Sunchaser (23/02/2018 13:03:50)
Hors ligne
encore quelques questions :
est-ce que la connexion excel se fait depuis le même serveur que la connexion Oracle ?
dans les 2 cas êtes-vous sûr que la chaine de connexion est identique ?
L'instance PostgreSQL écoute bien t'elle sur le port 4444 ?
Mais si dans le listener.log, la connexion est marquée comme "establish" c'est donc que la chaine de connexion est bonne.
reste donc à vérifier le user/password envoyé (avec la bonne casse éventuellement).
Et le pg_hba.conf (mais comme vous n'avez pas la main sur la conf PostgreSQL, ça va pas être simple...).
L'idéal serait de vous faire envoyer le pg_hba.conf.
Cordialement,
Sébastien.
Hors ligne
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.
Hors ligne
oui on peut voir les logs PostgreSQL si toute fois elles sont bien paramétrées (log_connections par exemple. voir : https://docs.postgresql.fr/9.6/runtime- … ging.html)
si on pouvait avoir le pg_hba.conf...
Mais si en plus vous n'êtes pas aidé par les gens qui gère le Postgresql... c'est pas gagné...
Cordialement,
Sébastien.
Hors ligne
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.
Hors ligne
La partie postgresql du log est ici:
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"
J'ai ajouté des sauts de lignes car ce sont deux erreurs bien distinctes.
La première erreur "Connection refused" vient de la couche réseau. Vraisemblablement le tunnel est en IPv4 seulement mais localhost se résoud en plusieurs adresses: IPv6 (::1) et IPv4 (127.0.0.1) et il commence par essayer l'IPv6 (=>échec) puis l'IPv4 (=>succès au niveau réseau en tout cas).
Une fois que la connexion est établie au niveau réseau vers 127.0.0.1:4444 il parle effectivement à un serveur PostgreSQL en face, qui produit la 2eme erreur:
FATAL: password authentication failed for user "MY_USER"
qui est une erreur classique de login invalide ou mot de passe invalide.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
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 !
;-)
Hors ligne
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 !
@+
Hors ligne
