J'exécute une instance d'Oracle 11g localement sur ma machine de développement et je peux me connecter à l'instance locale directement via SqlPlus:
c:\>sqlplus ace
SQL*Plus: Release 11.2.0.2.0 Production on Mon Mar 11 11:50:20 2013
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Beta
SQL> select count(*) from my_table ;
COUNT(*)
----------
5297
Mais je ne peux pas me connecter via l'auditeur:
c:\>sqlplus -L "user/pw@(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = localhost)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = XE)))"
SQL*Plus: Release 11.2.0.2.0 Production on Mon Mar 11 11:52:40 2013
Copyright (c) 1982, 2010, Oracle. All rights reserved.
ERROR:
ORA-12514: TNS:listener does not currently know of service requested in connect
descriptor
SP2-0751: Unable to connect to Oracle. Exiting SQL*Plus
De même, si je me connecte via SqlDeveloper, j'obtiens une erreur (bien que ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
).
Cette instance est stable et fonctionne bien depuis un an ou plus jusqu'à aujourd'hui, un lundi matin. Nos services informatiques d'entreprise poussent parfois de nouvelles politiques et mises à jour au cours du week-end, donc je suppose que quelque chose a changé, mais je n'ai pas pu déterminer quoi.
J'ai redémarré le service et l'auditeur plusieurs fois, le journal de l'auditeur ne donne aucun indice.
L'auditeur semble bien:
c:\>lsnrctl status
LSNRCTL for 32-bit Windows: Version 11.2.0.2.0 - Beta on 11-MAR-2013 11:55:33
Copyright (c) 1991, 2010, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for 32-bit Windows: Version 11.2.0.2.0 - Beta
Start Date 11-MAR-2013 11:17:30
Uptime 0 days 0 hr. 38 min. 3 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Default Service XE
Listener Parameter File C:\oraclexe\app\Oracle\product\11.2.0\server\network\admin\listener.ora
Listener Log File C:\oraclexe\app\Oracle\diag\tnslsnr\FBC305BB46560\listener\alert\log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC1ipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(Host=machine.domain.com)(PORT=1521)))
Services Summary...
Service "CLRExtProc" has 1 instance(s).
Instance "CLRExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
Le port 1521 semble correct:
c:\>netstat -an -O | find /i "1521"
TCP 0.0.0.0:1521 0.0.0.0:0 LISTENING 4368
TCP 169.243.90.109:55307 159.185.207.100:1521 ESTABLISHED 12416
TCP [::]:1521 [::]:0 LISTENING 4368
(Le PID 4368 est un processus TNSLSNR.exe.)
Je peux également tnsping
au service XE:
c:\>tnsping xe
TNS Ping Utility for 32-bit Windows: Version 11.2.0.2.0 - Beta on 11-MAR-2013 12:27:47
Copyright (c) 1997, 2010, Oracle. All rights reserved.
Used parameter files:
C:\oraclexe\app\Oracle\product\11.2.0\server\network\admin\sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = machine.domain.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = XE)))
OK (210 msec)
Le listenerr.ora
fichier:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(Oracle_HOME = C:\oraclexe\app\Oracle\product\11.2.0\server)
(PROGRAM = extproc)
)
(SID_DESC =
(SID_NAME = CLRExtProc)
(Oracle_HOME = C:\oraclexe\app\Oracle\product\11.2.0\server)
(PROGRAM = extproc)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
(ADDRESS = (PROTOCOL = TCP)(Host = machine.domain.com)(PORT = 1521))
)
)
DEFAULT_SERVICE_LISTENER = (XE)
De plus, et je n'ai aucune idée si c'est lié, je n'arrive pas à accéder à apex sur https://127.0.0.1:8080/apex
(même si les autorisations pour cela semblent correctes).
Alors, où dois-je chercher?
Mise à jour avec les informations demandées:
SQL> show parameter service_names
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
service_names string XE
SQL> show parameter local_listener
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
local_listener string
pdate2: comme le souligne @ miracle173 correctement, l'auditeur n'était pas très bien. Avec le paramètre "local_listener" mis à jour, des informations supplémentaires s'affichent désormais:
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC1ipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(Host=machine.domain.com)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(Host=127.0.0.1)(PORT=1521)))
Services Summary...
Service "CLRExtProc" has 1 instance(s).
Instance "CLRExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "XEXDB" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...
Service "xe" has 1 instance(s).
Instance "xe", status READY, has 1 handler(s) for this service...
The command completed successfully
Donc, grâce à @YasirArsanukaev pour le temps qu'il a consacré, j'ai trouvé une solution qui fonctionne, mais que je ne peux pas vraiment expliquer.
Riffing sur le LOCAL_LISTENER
pensais, je lisais cette autre réponse où il disait:
La base de données utilise le paramètre LOCAL_LISTENER pour identifier l'écouteur auprès duquel elle doit s'inscrire. Par défaut, cette valeur est nulle, ce qui, selon la documentation, est équivalent au nom d'hôte: 1521.
J'ai donc essayé d'envoyer une requête ping à mon propre nom d'hôte et je n'ai pas pu - cela ressemble à un problème IPv6, recevant un message d'échec général.
J'ai donc pris les conseils de cette réponse
SQL> alter system set LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(Host=localhost)(PORT=1521))' scope=both;
SQL> alter system register;
et cela fonctionne maintenant, probablement parce qu'il peut résoudre la référence localhost, où il échouait à résoudre le nom d'hôte réel.