Oracle 10gR2 64bits avec client Oracle 32bits

Version imprimable

25/09/2012, 11h48
bfe95

Oracle 10gR2 64bits avec client Oracle 32bits

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.
26/09/2012, 20h21
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

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.

28/09/2012, 11h52
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:

1 2 set oracle_sid=orcl
sur un poste client :
sqlplus system/manager@orcl

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

Cdlt

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:

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:

1 2 C:\Windows\system32>lsnrctl
Code:

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

28/09/2012, 12h00
dariyoosh

Aussi, merci d'écrire le contenu des fichiers

%TNS_ADMIN%\tnsnames.ora

et

%TNS_ADMIN%\listener.ora
28/09/2012, 12h17
Pomalaix

Citation:

Envoyé par dariyoosh

...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.
28/09/2012, 12h40
dariyoosh

Citation:

Envoyé par Pomalaix

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

Citation:

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.
...

Citation:

Envoyé par Pomalaix

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,
28/09/2012, 13h55
Pomalaix

Citation:

Envoyé par dariyoosh

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.