A 12535 + 12606 error might be an attempt to get a shared server connection when a server process is busy doing something else or somehow not available for a new session, check your $ lsnrctl services output in the stanza under the "Dxxx", check the connection count details, if the counts is low, or even 0, and the "Refused" count is 0, its not a shared server connect issue.ns main err code: 12535 ... TNS-12535: ... ns secondary err code: 12606
No, that's not a 'tnsping OK' output at all. MOS note Troubleshooting Guide TNS-12535 or ORA-12535 or ORA-12170 Errors 119706.1 might be helpful there.tnsping xe ... TNS-12537
FQDN should be your fully qualified hostgame, i.e. electrosun.yourcompany.com or something similar. And a tracert <FQDN> might be a good check as well.
$ ipconfig /all ... ? perhaps more than one adapter ? ... IP address: n.n.n.n $ hostname ==> electrosun (?) $ nslookup electrosun ... IP address: <n.n.n.n> $ nslookup n.n.n.n ... hostname: electrosun ... (?) $ tracert electrosun ... # should only be one line here ending in <FQDN> [n.n.n.n]
Connect attempts don't seem to be coming in via a Shared connection. Peek the oracle doc to see the explanation of for ora-12535, although it may not help much, something isn't getting through to the listener. http://docs.oracle.com/cd/E11882_01/server.112/e17766/net12500.htm#sthref3565"D000" established:0 refused:0 current:0 max:1002 state:ready
Isn't quite correct, I think, maybe a variation of an instant client (?) connect specifier, for a listener connection you want to specify <user>@<tnsalias> and for the XE install, a tnsalias "xe" should already be present in your %ORACLE_HOME%/network/admin/tnsnames.ora file.sqlplus user/pw@'localhost/electrosun:1521'
Don't quote me on those instant client connect identifiers, I don't use those much at all. My loss, maybe. Also not exactly positive what the sqlnet protocols that are in play for a default out-of-the-box setup.
sqlplus user@xe ... password ... -- or *maybe* sqlplus user@localhost/xe -- or sqlplus user@electrosun/xe
Can suggest a couple easy things to try, stop the listener, move (rename) your listener.ora file, and start the listener. Use a sys or system connection, and register the instance:
SQLNET.AUTHENTICATION_SERVICES = (NTS)
Also, the status/services line with
$ lsnrctl stop $ cd %ORACLE_HOME% # that *should work, verify the location $ move listener.ora listener.ora.bk0 $ lsnrctl start $ sqlplus system ... passord ... Connected. alter system register; exit $ lsnrctl status ... $ lsnrctl services
should show the TCP protocol, not IPC. Maybe. Using a non-existent listener.ora file ought to cause a change in that line of the status and services output. Also, try this content for a listener.ora file and see what happens:Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
Be sure to stop the listener before changing the file. Also, setting host=<hostname> and host=0.0.0.0 all may be worth trying as well, it only takes a listener stop, edit, listener start, and sqlplus system ... alter system register; to see if there's a change. I believe orafad gets the kudos for the non-existent listener.ora trick.
LISTENER = (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=n.n.n.n)(PORT=1521)) )
Right, a connection to the database from the db host, as long as the client environment is set properly, uses a bequeath, not a listener, connection.if I just type "sqlplus" i get prompted for usr/pwd and I can log in