Discussion :

[bfe95]

Bonjour,

J'ai un serveur Windows en 64bits (2003 R2).
J'ai installé la base Oracle 10gR2 en 64 bits.
J'ai donc en même temps le client en 64bits...

Mais j'ai mon application interne qui ne peut se connecter qu'avec un client Oracle 32bits.
J'ai donc installé un client Oracle 32bits mais je n'arrive pas à me connecter via ce client :
ORA-12560: TNS:protocol adapter error

J'ai testé différents PATH, sans succès.

Merci pour votre aide.

[dariyoosh]

Bonjour,


Est-ce que le Listener est bien démarré et en écoute?

En outre il faut vérifier que les variables d'environnements ORACLE_HOME,
TNS_ADMIN et ORACLE_SID sont toutes bien définies.


Cordialement,
Dariyoosh

[bfe95]

Le listener est bien demarrée.

J'ai créé les variables d'environnement utilisateur Windows mais c'est pareil :

ORACLE_HOME=C:\oracle\product\10.2.0\client_32bits
TNS_ADMIN=C:\oracle\product\10.2.0\client_32bits\NETWORK\ADMIN
ORACLE_SID=gedtes

C:\>cd C:\oracle\product\10.2.0\client_32bits\bin

C:\oracle\product\10.2.0\client_32bits\BIN>sqlplus

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Sep 27 16:38:00 2012

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

Enter user-name: ged
Enter password:
ERROR:
ORA-12560: TNS:protocol adapter error


Enter user-name:
C:\oracle\product\10.2.0\client_32bits\BIN>

Merci.
Cordialement.

[ducho]

Bonjour,

Dans votre connexion , vous n'utilsez pas le listener ni le tnsnames.ora .
Soit vous êtes sur le serveur qui héberge la base et donc vous pouvez précisez

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
set oracle_sid=orcl

sur un poste client :
sqlplus system/manager@orcl

orcl correspondant à une entrée du fichier tnsnames.ora

Cdlt

[dariyoosh]

Bonjour,


Pensez à ajouter %ORACLE_HOME%\bin à la variable d'environnement %PATH%


Déjà, est-ce qu'au niveau de l'OS vous pouvez d'ouvrir une session SQL*Plus?
C'est à dire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
C:\Windows\system32>sqlplus /nolog
 
SQL*Plus: Release 11.1.0.6.0 - Production on Ven. Sept. 28 11:49:38 2012
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
SQL> CONNECT / AS SYSDBA
Connecté.
SQL>

Si c'est le cas fermez la session de SQL*Plus et ensuite, veuillez saisir ici le rapport de lsnrctl pour le listener

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
C:\Windows\system32>lsnrctl

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
LSNRCTL> help
Les opérations suivantes sont disponibles
Un astérisque(*) représente un modificateur ou une commande étendue :
 
start               stop                status
services            version             reload
save_config         trace               change_password
quit                exit                set*
show*
 
LSNRCTL>

Et dans l'invite de commande vous tappez status pour voir qu'est-ce que ça donne.


Cordialement,
Dariyoosh

[dariyoosh]

Aussi, merci d'écrire le contenu des fichiers

%TNS_ADMIN%\tnsnames.ora

et

%TNS_ADMIN%\listener.ora

[Pomalaix]

...En outre il faut vérifier que les variables d'environnements ORACLE_HOME,
TNS_ADMIN et ORACLE_SID sont toutes bien définies.

TNS_ADMIN n'est en aucune façon obligatoire, il serait même plutôt déconseillé.
Mais s'il est utilisé, il faut effectivement contrôler qu'il a bien une valeur cohérente.

[dariyoosh]

TNS_ADMIN n'est en aucune façon obligatoire

Dans le cas de cet exemple, oui effectivement ce n'est pas obligatoire mais sont utilisation peut devenir intéressant selon le type et architecture d'installation

http://dba-oracle.com/t_tns_admin.htm

The TNS_ADMIN parm tells Oracle clients where to find the tnsnames.ora file.
...
The tns_admin parameter is super useful on servers with many databases on different release levels (hence different $ORACLE_HOME directories) because all databases tns_admin values can be set to a single location, allowing a single set of SQL*Net files for all databases on the server.
...

il serait même plutôt déconseillé.

Vous auriez idéalement un lien vers la documentation oracle sur ce sujet qui confirme votre assertion?

Merci d'avance,

[Pomalaix]

Vous auriez idéalement un lien vers la documentation oracle sur ce sujet qui confirme votre assertion?

Nan, juste de l'expérience et des arguments.

Dans le principe, TNS_ADMIN est séduisant, puisqu'il permet :
- côté client, d'avoir un TNSNAMES.ORA centralisé, utilisable par tous les clients, ce qui facilite la vie du DBA
- côté serveur, d'avoir une configuration SQLNET centralisée, qui sera utilisable par toutes les installations Oracle de la machine

Maintenant, c'est à manier avec précaution, comme pas mal de choses, et nécessite de bien verrouiller sa configuration.

1) Un client peut définir TNS_ADMIN à la valeur de son choix pour pointer sur une tout autre configuration s'il le souhaite, à l'insu de l'administrateur. Donc il ne faut pas croire que l'usage (ou le non usage) de cette variable garantit quoi que ce soit.

2) Si les fichiers du TNS_ADMIN ne sont pas protégés en écriture, n'importe qui peut les modifier, y compris involontairement (j'ai déjà donné).

3) Il ne faut pas oublier que TNS_ADMIN est pris en compte aussi lors de la recherche du LISTENER.ORA. S'il n'y en a pas, la recherche se poursuit en local dans ?/network/admin.
Mais si vous avez le malheur d'avoir effectivement un LISTENER.ORA dans cet emplacement centralisé, alors tous les serveurs ayant un TNS_ADMIN pointant vers cet emplacement vont tenter de l'utiliser pour démarrer leur listener respectif, mais cela échouera à cause du paramètre HOST du LISTENER.ORA, qui ne sera correct que pour l'une des machines.
J'ai vécu ça aussi, 15 serveurs en rade un lundi matin suite au redémarrage du week end.

Par conséquent, je déconseille d'utiliser TNS_ADMIN sans nécessité réelle.