ORA-12154 « TNS:could not resolve the connect identifier specified » signifie que le client Oracle n’arrive même pas à trouver la base à contacter : l’alias de connexion que vous utilisez n’est pas résolu. C’est une erreur de configuration côté client — voici la méthode pas à pas pour la corriger définitivement.
🧪 Envie de pratiquer ? Exécutez les exemples de cet article dans notre SQL Playground gratuit — aucun logiciel à installer.
Comprendre l’erreur en 10 secondes
Quand vous écrivez sqlplus user@MABASE, le client doit traduire MABASE en « hôte + port + service ». Cette traduction passe (en général) par le fichier tnsnames.ora. ORA-12154 = « je ne sais pas ce qu’est MABASE ». La base elle-même n’est peut-être même pas en cause.
Étape 1 — Vérifier l’alias dans tnsnames.ora
# Où est mon tnsnames.ora ?
# $ORACLE_HOME/network/admin/tnsnames.ora
# ou le dossier pointé par la variable TNS_ADMIN
MABASE =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = srv-oracle01)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = orclpdb1))
)Vérifiez : l’alias existe-t-il ? exactement avec ce nom ? sans faute de frappe ? Testez ensuite la résolution :
tnsping MABASEtnsping OK = l’alias se résout (si la connexion échoue ensuite, c’est un autre problème, par ex. ORA-01017). tnsping KO avec TNS-03505 = même cause qu’ORA-12154.
Étape 2 — Vérifier QUEL tnsnames.ora est lu (le piège classique)
Plusieurs clients Oracle installés = plusieurs tnsnames.ora possibles. Le client utilise celui de son ORACLE_HOME, sauf si TNS_ADMIN est défini :
# Windows
echo %TNS_ADMIN%
echo %ORACLE_HOME%
# Linux/macOS
echo $TNS_ADMIN
echo $ORACLE_HOMEConseil : définissez TNS_ADMIN vers un dossier unique partagé par tous vos outils — fini les surprises « ça marche dans SQL Developer mais pas dans mon appli ».
Étape 3 — Les pièges de syntaxe du fichier
- Parenthèse manquante ou en trop — une seule suffit à casser la lecture du fichier à partir de cette entrée.
- Espace/indentation en début de première ligne d’une entrée : l’alias doit commencer en colonne 1.
- Caractères invisibles après un copier-coller (guillemets typographiques, BOM).
- Fichier édité mais non sauvegardé au bon endroit (droits insuffisants → sauvegardé ailleurs par l’éditeur).
Étape 4 — Contourner pour diagnostiquer : la syntaxe EZConnect
Sans toucher au fichier, testez en direct « hôte:port/service » :
sqlplus user@"srv-oracle01:1521/orclpdb1"✅ Ça marche → le problème est bien votre alias/tnsnames.ora.
❌ Ça échoue avec ORA-12541 (no listener) → le souci est côté serveur/réseau, pas la résolution.
Cas particuliers fréquents
- Application .NET/JDBC : la chaîne de connexion de l’appli n’utilise pas le même mécanisme que votre poste — préférez-y la forme complète
host:port/service. - Windows + chemin avec parenthèses : un client 32 bits installé dans
C:\Program Files (x86)peut provoquer ORA-12154 avec certains drivers — installez le client hors de ce chemin. - LDAP/Active Directory : si votre entreprise résout les alias via LDAP (
ldap.ora), vérifiezNAMES.DIRECTORY_PATHdanssqlnet.ora(ex.(LDAP, TNSNAMES, EZCONNECT)).
Checklist de résolution
tnsping MONALIAS→ se résout-il ?TNS_ADMIN/ORACLE_HOME→ le bon fichier est-il lu ?- Syntaxe du tnsnames.ora (parenthèses, colonne 1) ?
- Test EZConnect
host:port/servicepour isoler. - App ≠ poste : vérifier la chaîne de connexion de l’application elle-même.
FAQ
Quelle différence entre ORA-12154 et ORA-12541 ?
ORA-12154 : l’alias ne se résout pas (problème client/config). ORA-12541 : l’alias se résout mais aucun listener ne répond sur l’hôte:port (problème serveur/réseau).
SERVICE_NAME ou SID ?
Préférez SERVICE_NAME (standard moderne, obligatoire avec les PDB multitenant). SID ne fonctionne que sur les configurations historiques.
Ça marche dans SQL Developer mais pas dans mon script ?
SQL Developer peut utiliser son propre mécanisme (connexion enregistrée) sans passer par tnsnames.ora. Votre script, lui, dépend de TNS_ADMIN — alignez les deux.