Connexion avec Instantclient sur Debian

Version imprimable

15/04/2011, 11h43
clem_alain

Connexion avec Instantclient sur Debian
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:

ora-12514 tns listener does not currently know of service requested in connect descriptor

La machine cible est correctement configurée :
Code:

1 2 3 4 5 6 7 8 9 ORASRV2 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = ORASRV2 PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = ORA10) ) )
Quelqu'un a-t-il une idée ?
Merci d'avance.
15/04/2011, 12h04
Pomalaix
Alors ce qu'il faudrait nous montrer, c'est :
- l'entrée ORASRV2 du TNSNAMES.ORA de votre client (celui du serveur n'a aucune incidence dans le cas présent)
- le contenu du LISTENER.ORA
- le résultat de
  
  Code:
  
  lsnrctl services
  
  (à exécuter sur le serveur, au niveau du shell)
- le résultat de
  
  Code:
  
  show parameter service_names
  
  (dans SQL*Plus sur le serveur)
15/04/2011, 13h19
clem_alain

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:

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = C:\oracle\product\10.2.0\db_1)
(PROGRAM = extproc)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
(ADDRESS = (PROTOCOL = TCP)(HOST = ORASRV2.classic.local)(PORT = 1521))
)
)

Le résultat de lsnrctl services :

Citation:

LSNRCTL for 32-bit Windows: Version 10.2.0.1.0 - Production on 15-AVR. -2011 13:
15:18

Copyright (c) 1991, 2005, Oracle. All rights reserved.

Connexion Ó (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
RÚcapitulatif services...
Le service "PLSExtProc" comporte 1 instance(s).
L'instance "PLSExtProc", statut UNKNOWN, comporte 1 gestionnaire(s) pour ce se
rvice...
Gestionnaire(s) :
"DEDICATED" Útabli : 0 refusÚ : 0
LOCAL SERVER
Le service "ora10" comporte 1 instance(s).
L'instance "ora10", statut READY, comporte 1 gestionnaire(s) pour ce service..
.
Gestionnaire(s) :
"DEDICATED" Útabli : 219 refusÚ : 0 statut : ready
LOCAL SERVER
Le service "ora10XDB" comporte 1 instance(s).
L'instance "ora10", statut READY, comporte 1 gestionnaire(s) pour ce service..
.
Gestionnaire(s) :
"D000" Útabli : 0 refusÚ : 0 en cours : 0 max. : 1002 statut : ready
DISPATCHER <machine: ORASRV2, pid: 2340>
(ADDRESS=(PROTOCOL=tcp)(HOST=ORASRV2.classic.local)(PORT=1040))
Le service "ora10_XPT" comporte 1 instance(s).
L'instance "ora10", statut READY, comporte 1 gestionnaire(s) pour ce service..
.
Gestionnaire(s) :
"DEDICATED" Útabli : 219 refusÚ : 0 statut : ready
LOCAL SERVER
La commande a rÚussi

Pour moi tout semble OK, d'autant que sur mes clients windows je n'ai aucun problème.

Qu'en pensez-vous ?
Merci pour votre réponse
15/04/2011, 14h47
Pomalaix

Et si vous tentez une connexion à la mode EZconnect depuis le poste Linux, ça donne quoi ?

Code:

sqlplus toto/titi@orasrv2:1521/ora10

Si jamais ça passe, c'est qu'il y a un souci soit dans votre SQLNET.ORA, soit dans le TNSNAMES.ORA.
15/04/2011, 17h36
clem_alain

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,
15/04/2011, 17h38
Pomalaix

Si vous ne pouvez pas tester alors...

Quant au SQLNET.ORA, il n'est pas obligatoire, des valeurs par défaut s'appliquent.
17/04/2011, 12h19
clem_alain

Résolu

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
17/04/2011, 18h45
Pomalaix

Citation:

Envoyé par clem_alain

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 !

Bonne nouvelle !

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)

C'est à dire que le client Oracle a cherché à interpréter @ORASRV2
- 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 !