Re: OCIServerAttach returns ORA-12514

"Paul" <paul.flew_at_globaladdress.net> wrote in news:1155509668.191551.316760_at_74g2000cwt.googlegroups.com:

> Hi
>
> Thanks for the info so far guys.
>
> A bit more information for you:
>
> - I'm using instant client 10.2 on RedHat Enterprise Linux
> - By 'other applications' I mean things such as Aqua Data Studio, a
> Java tool I downloaded to check connectivity.
> - I'm not using a tnsnames.ora file, or if I am its a default one.
> There's one in /etc which is blank. I'm connecting to all databases
> using //<dns name>:<port>/<instance>
>
> Once again, I am able to connect to some databases using this method,
> just not the latest one I'm trying to connect to. I've been told to
> look in the sqlnet.log file, and that contains the information:
>
> **********************************************************************
*
> Fatal NI connect error 12514, connecting to:
>
> (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=*****)(CID=(PROGRAM=*****)
(HOS
> T=*****)(USER=*****)))(ADDRESS=(PROTOCOL=TCP)(HOST=*****)(PORT=1256)))
>
> VERSION INFORMATION:
> TNS for Linux: Version 10.2.0.2.0 - Production
> TCP/IP NT Protocol Adapter for Linux: Version 10.2.0.2.0 -
> Production
> Time: 13-AUG-2006 13:30:00
> Tracing not turned on.
> Tns error struct:
> ns main err code: 12564
> TNS-12564: Message 12564 not found; No message file for
> product=network, facility=TNS
> ns secondary err code: 0
> nt main err code: 0
> nt secondary err code: 0
> nt OS err code: 0
>
> Googling for TNS-12564 gives TNS:Connection refused. Does this mean
> that there's some authentication problem, or is that just a red
> herring?
>
> Thanks for the help
>
>
>
> Paul
>
>

12564, 00000, "TNS:connection refused"
// *Cause: The connect request was denied by the remote user (or TNS software).
// *Action: Not normally visible to the user. For further details, turn on
// tracing and reexecute the operation.

I may be remembering wrong, the details but here is a shot in the dark. The 10g listener behaves differently than previous versions. It "knows" what the process limit is for the DB. At times it knows how many active sessions exist. Then it start incrementing as new requests come to it. When the count hits the process limit, the LISTENER itself refuses the connection.
So if the listener is being flooded by many new, short lived connections, you could see this flavor of error. The listener.log file shows when the listener is periodically updated with the latest session count by the DB.

The work around is to increase the proces limit in initSID.ora Received on Sun Aug 13 2006 - 18:17:53 CDT