TNS:protocol adapter error (32bit client/64 bit 11g server on same machine)

Question

I have Oracle 11g Server (x64) installed on my Windows 7 system and it was working fine. I could connect through SQL*Plus and perform all my database needs. I have since installed software that requires a 32 bit client and have installed both 11g and 10g clients into their own home directories. (Long story short, I found out that one software suite was not compatible with the 11g client and so had to install 10g.) I find that if I force the use of the SQL*Plus in the server directory (opening a CMD prompt directly at the BIN directory) that I can connect fine without the need of a TNS alias. However, if I use the default (10g due to its placement in the PATH environment variable) it requires me to use the TNS alias to connect to my local database. This is also true if I force the use of the 11G client.
I have checked my tnsnames.ora and my sqlnet.ora files and they match up to what is being used in the server home. I'm missing something though. Anyone have a suggestion for me?
Rod
Edited by: rsherer on Nov 28, 2012 11:43 AM

Answer 1

rsherer wrote:
I should be able to connect using...
sqlplus user/password
Not entirely correct.
If TWO_TASK is not set, this connection is an IPC (direct client process to server process) connection.
The client needs a dedicated server process to service it. As it does not connect via a Listener, there is no Listener that can create that server process to service the client.
So for an IPC connection, the client needs to start its own dedicated server process for servicing it. It uses ORACLE_HOME in order to find +./bin/oracle+ to start as a dedicated server process. On Linux/Windows, a kernel call (like <i>execv</i>) is used by the client driver to start a dedicated server process. I think in Windows the CreateRemoteThread() call is used by the Windows OCI driver to start a dedicated server process to service it.
This dedicated server process uses ORACLE_SID to determine the SGA to attach to and database instance to join.
This cannot happen across 32bit and 64bit boundaries in Linux/Unix. And I would be very surprised if this is possible in Windows as kernel IPC is not possible to my knowledge between 32bit process VMs and 64bit process VMs in the NT kernel.
To make a "local" connection work from a 32bit client to a 64bit instance on the same platform, set TWO_TASK to a TNS alias that defines a localhost/local IP TCP connection, in the 32bit environment. A sqlplus user/password (IPC) will now in fact be a sqlplus user/password@<TWO_TASK> (TCP) connection.
A shared server connection by the way has the client being serviced by a dispatcher process. A dispatcher process is only able to service (communicate with) clients via TCP. Thus shared server connections are only possible via the Listener. A local (IPC) connection is always a dedicated server connection.