Problème: tnsnames.ora reconnu dans Enterprise Manager, mais pas dans SQLPlus

Version imprimable

10/03/2010, 18h04
Médinoc

Problème: tnsnames.ora reconnu dans Enterprise Manager, mais pas dans SQLPlus

Bonjour,
J'ai un problème étrange: Nous avons deux machines se connectant à une base Oracle et possédant deux fichiers tnsnames.ora identiques. Or, sur l'une d'elles, le nom de base n'est pas reconnu dans SQLPlus ou nos logiciels (qui font une erreur ORA-12154). Pourtant, Orable Enterprise Manager voit les bases configurées...

Vous avez peut-être plusieurs ORACLE_HOME sur une machine.

Vérifiez la localisation et le contenu du fichier tnsnames.ora. Par défaut tnsnames.ora est dans <ORACLE_HOME>/network/admin. Il peut aussi être dans le répertoire désigné par la variable d'environnement TNS_ADMIN:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
$ oerr ora 12154
12154, 00000, "TNS:could not resolve the connect identifier specified"
// *Cause:  A connection to a database or other service was requested using
// a connect identifier, and the connect identifier specified could not
// be resolved into a connect descriptor using one of the naming methods
// configured. For example, if the type of connect identifier used was a
// net service name then the net service name could not be found in a
// naming method repository, or the repository could not be
// located or reached.
// *Action:
//   - If you are using local naming (TNSNAMES.ORA file):
//      - Make sure that "TNSNAMES" is listed as one of the values of the
//        NAMES.DIRECTORY_PATH parameter in the Oracle Net profile
//        (SQLNET.ORA)
//      - Verify that a TNSNAMES.ORA file exists and is in the proper
//        directory and is accessible.
//      - Check that the net service name used as the connect identifier
//        exists in the TNSNAMES.ORA file.
//      - Make sure there are no syntax errors anywhere in the TNSNAMES.ORA
//        file.  Look for unmatched parentheses or stray characters. Errors
//        in a TNSNAMES.ORA file may make it unusable.
//   - If you are using directory naming:
//      - Verify that "LDAP" is listed as one of the values of the
//        NAMES.DIRETORY_PATH parameter in the Oracle Net profile
//        (SQLNET.ORA).
//      - Verify that the LDAP directory server is up and that it is
//        accessible.
//      - Verify that the net service name or database name used as the
//        connect identifier is configured in the directory.
//      - Verify that the default context being used is correct by
//        specifying a fully qualified net service name or a full LDAP DN
//        as the connect identifier
//   - If you are using easy connect naming:
//      - Verify that "EZCONNECT" is listed as one of the values of the
//        NAMES.DIRETORY_PATH parameter in the Oracle Net profile
//        (SQLNET.ORA).
//      - Make sure the host, port and service name specified
//        are correct.
//      - Try enclosing the connect identifier in quote marks.
//
//   See the Oracle Net Services Administrators Guide or the Oracle
//   operating system specific guide for more information on naming.

10/03/2010, 22h34
Vincent Rogier

Tiens donc, Médinoc, toi ici ? ;)

tes sqlnet.ora sont il les mêmes ?
n'as tu pas plusieurs client oracle sur une des machines ?
etc..
10/03/2010, 23h46
Médinoc

Citation:

Envoyé par Vincent Rogier

Tiens donc, Médinoc, toi ici ? ;)

Bah, que veux-tu, je n'utilise jamais l'horrible Orable (je préfère la magnifique interface graphique de SQL Server, comme tout le monde à mon boulot), donc des qu'on a un problème, on est un peu perdu vu qu'on n'a pas de Redneck au boulot...
10/03/2010, 23h53
Vincent Rogier

et sinon, toujours le même soucis ?
11/03/2010, 07h06
Médinoc

Ben y'a pas trop de risques que ça change entre 19h et 9h...
11/03/2010, 10h07
Médinoc

Tiens, encore plus bizarre: La version qui marche n'a pas de SQLNET.ORA dans <ORACLE_HOME>/network/admin (il n'y a que la version dans SAMPLE)...
Et encore plus bizarre, elle n'a pas de SQLPlus.
11/03/2010, 10h17
Vincent Rogier

donc as tu un sqlnet.ora et quel est son contenu ?
As tu une variable d'environnement TNS_ADMIN
sous quel plateforme es tu et quelle version d'oracle ?
11/03/2010, 10h33
Médinoc

Grosse update: En fait, SQLPlus marche, seuls les programmes foirent.

Mon manque d'habitude de SQLPlus et le fait que ce soit une version Norvégienne ont entraîné une mauvaise utilisation de SQLPlus (je confondais serveur, user et password).

Mais ça n'explique pas pourquoi les programmes ne marchent pas.

La version d'Oracle est 9.2.0.6.0 sur la machine qui foire (je ne sais pas comment l'obtenir sur celle qui marche, vu qu'elle n'a pas SQLPlus).

Les deux machines ont apparemment oracle dans le path, pas de variable d'environnement TNS_ADMIN ou ORACLE_HOME sur aucune des deux.
11/03/2010, 10h38
Vincent Rogier

quel OS client ?
quel est le contenu du sqlnet.ora
quel est le contenu du sqnlet.log situé le répertoire du binaire qui ne se connecte pas ?
11/03/2010, 10h56
Médinoc

Problème résolu en supprimant les fichiers .ORA et .CFG supplémentaires sur la machine qui foirait: Maintenant elle a juste le TNSNAMES.ORA, et elle marche à nouveau.

PS: SQLNET.LOG? Kézako?
11/03/2010, 11h15
Vincent Rogier

lorsqu'une des erreurs SQL*NET surviennent, elles sont stockées dans un fichier sqlnet.log qui est crée dans le répertoire courant du binaire qui a rencontré l'erreur SQL*NET
11/03/2010, 11h24
Médinoc

Eh bien dans ce cas, il y a fort à supposer que System.Data.OracleClient ne repose pas sur ce "SQL*NET" dont tu parles... (oui, j'ai oublié de le préciser, ce sont des programmes pour .Net)
11/03/2010, 11h29
Vincent Rogier

en si ...

- ton provider est basé sur OCI
- OCI utilise SQL*NET
- SSQL*NEt est le protocole réseau Oracle

Mais en fonction de l'install ou des options du client sql*net, les logs ne sont pas toujours générés ou générés dans des répertoires qui peuvent varier