|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | |||
|
Invité de passage
![]() Inscription : décembre 2004 Messages : 55 ![]() |
Bonjour,
J'ai installé InstantClient 10.2.0.4 sur une Debian Lenny en suivant les indications trouvées sur : http://throka.org/linux_debian_client_oracle.php Tout c'est (apparemment) bien passé si ce n'est qu'au moment de tester avec SQL plus : SQLPLUS monuser@ORASRV2 Saisie du mot de passe j'ai le message suivant : Citation:
Code :
Merci d'avance. |
|||
|
|
00
|
|
|
#2 |
![]() Inscription : décembre 2002 Messages : 2 385 ![]() |
Alors ce qu'il faudrait nous montrer, c'est :
__________________
Consultant / formateur Oracle indépendant Certifié OCP 10g et 11g, sécurité 11g |
|
|
00
|
|
|
#3 | ||
|
Invité de passage
![]() Inscription : décembre 2004 Messages : 55 ![]() |
Bonjour,
Merci pour votre réponse, mais j'aurais du préciser que la Debian est le client alors que le serveur se trouve sur une W2K3R2. Ce serveur est parfaitement accessible par des clients Windows dont le TNSNAME est strictement identique à celui que j'ai donné. A mon humble avis le serveur n'est pas en cause car il est parfaitement accessible depuis les autres clients . Cependant voici le Listener.ora : Citation:
Citation:
Qu'en pensez-vous ? Merci pour votre réponse |
||
|
|
00
|
|
|
#4 |
![]() Inscription : décembre 2002 Messages : 2 385 ![]() |
Et si vous tentez une connexion à la mode EZconnect depuis le poste Linux, ça donne quoi ?
Si jamais ça passe, c'est qu'il y a un souci soit dans votre SQLNET.ORA, soit dans le TNSNAMES.ORA.
__________________
Consultant / formateur Oracle indépendant Certifié OCP 10g et 11g, sécurité 11g |
|
|
00
|
|
|
#5 |
|
Invité de passage
![]() Inscription : décembre 2004 Messages : 55 ![]() |
Je ne peux pas tester maintenant, mais un doute m'étreins ! Si j'ai bien un tnsname.ora, je n'ai pas de sqlnet.ora !
Est-ce grave docteur ? Naïvement, il me semblait que ce n'était utile que sous windows ! Quel devrait être le contenu de sqlnet.ora ? Merci, |
|
|
00
|
|
|
#6 |
![]() Inscription : décembre 2002 Messages : 2 385 ![]() |
Si vous ne pouvez pas tester alors...
Quant au SQLNET.ORA, il n'est pas obligatoire, des valeurs par défaut s'appliquent.
__________________
Consultant / formateur Oracle indépendant Certifié OCP 10g et 11g, sécurité 11g |
|
|
00
|
|
|
#7 |
|
Invité de passage
![]() Inscription : décembre 2004 Messages : 55 ![]() |
Bonjour,
Je viens de tester et cela a bien fonctionné, du coup j'ai eu un doute sur le tnsname.ora, il était correct, mais c'était le nom qui ne l'était pas ! C'est tnsnameS.ora ! ô rage ô désespoir ... Merci pour votre aide |
|
|
00
|
|
|
#8 | |
![]() Inscription : décembre 2002 Messages : 2 385 ![]() |
Citation:
Votre cas mérite un commentaire, car vous êtes tombé sur quelques subtilités. Le SQLNET.ORA étant absent, le paramètre suivant a pris sa valeur par défaut, selon la doc : Code :
NAMES.DIRECTORY_PATH=(tnsnames, onames, hostname) - d'abord à l'aide du TNSNAMES.ORA --> échec car inexistant (n'a pas le bon nom) - ensuite par Oracle Names --> échec car paramétrage inexistant - enfin par résolution de nom d'hôte, que je détaille ci-dessous 1) Il a donc utilisé la configuration réseau du client (fichier HOSTS, DNS) pour voir s'il existait une machine s'appelant ORASRV2. Il se trouve que oui. 2) Il a supposé, avec succès, que sur cette machine se trouvait un Listener écoutant sur le port standard 1521. 3) Et il a demandé à accéder à une base supportant le nom de service ORASRV2. (C'est ainsi que fonctionne la méthode HOSTNAME : le nom de service de la base doit être identique au nom du serveur). Il n'y en avait pas, d'où l'erreur ORA-12514. Bref, c'était un concours de circonstances qui a failli marcher jusqu'au bout !
__________________
Consultant / formateur Oracle indépendant Certifié OCP 10g et 11g, sécurité 11g |
|
|
|
10
|
Copyright © 2000-2012 - www.developpez.com