HELP: SQL*NET Problems - Long (But please help anyway!)

From: James A. Mumper <jamumper_at_ptes.com>
Date: 1996/06/11
Message-ID: <31BDAC4F.5167_at_ptes.com>#1/1


I am running out of things to try and need some help. I am getting an error from SQL*NET on one server that I should not be getting, and I can't seem to make it go away. Also, connections are happening that should not be and I am at a loss to explain how.

First, an explanation of the environment. I have 4 servers with databases on them, all HP Unix boxes. Servers 1 and 4 are HP-UX 9.04, Oracle 7.1.6 and SQL*NET V1 and V2.1. Servers 2 and 3 are HP-UX 10.01, Oracle 7.2.2 and SQL*NET V1 and V2.2. Servers 1 and 2 have 4 instances, Servers 3 and 4 have one each. I have installed Oracle Names servers on 2 and 3 with the network definition stored in a database on server 3. The network is TCP/IP only. I also installed Oracle SNMP on server 3. Server 3 is sort of a test bed for us - the database I built is Loney's command center database.

I have installed Enterprise Manager V1.1 on my desktop NT Server and on the NT system I am using SQL*NET V2.3. I am using the database on server 3 as the repository.

Problem number 1:

NAMESCTL causes a GPF on Windows NT V3.51, Service Pack 4 with the Hot Fix. I have told Oracle about this but haven't heard anything back yet. I wanted to run a Nmaes server on the NT box, but can't.

Problem Number 2:

On server 3, I can connect to the local database. I can connect to 3 out of 4 instances on server 1 from server 3. I cannot connect to any instances running on server 2 from server 3. The error message is the same every time, "ERROR: ORA-12211: TNS:needs PREFERRED_CMANAGERS entry in TNSNAV.ORA". PREFERRED_CMANAGERS is only necessary in a multi-protocol setup and points to the primary connection manager of a multi-protocol interchange. I don't have one. I don't need one.

I thought that it may have something to do with the fact that I also installed SNMP on server 3, even though I wasn't using it yet. So, I looked through the MultiProtocol manual and it says that the Connection manager is responsible for managing requests from a Master Agent. I thought maybe I would need one to support using SNMP. So I tried to create one in Network Manager and it failed due to the fact that I was only using one network protocol, which is what I thought would happen.

Then I thought that, since my default client configuration files point to the Names server on server 2 first that I was having a problem with that. I created a special client for server 3 that would use it's own Names Server first, but this did not make any difference. But it caused me to start poking around in my system files to make sure that everything was set up properly on the server, which leads me to

Problem Number 3: In the /etc/services file on server 3 there are no entries for Oracle at all. I do not understand why, because I watched my Sys Admin run root.sh after I installed the software and that file usually updates /etc/services. Anyway, I thought that that might be what was causing my problem. And then it dawned on me that I was able to connect to the database on server 3 from clients even though my protocol is TCP/IP! This also helped me understand why the listener would sort of freeze up during startup. I mean, it would go so far and then stop. If I broke out of the process and then did a lsnrctl status it would show up as running with the database having 1 service handler.

Perhaps I do not understand TCP/IP the way I thought I did, but it's my understanding that SQL*NET will listen on the port I assign it in the
/etc/services file and when it receives a package at the port it forwards
it accordingly. That is why the client must know which port to send data to. But with no access to the port, as evidenced by it's absence from the
/etc/services file, remote clients are connecting to the database. How
can that be?!?

Well, that's it. I have tried just about everything I can think of but the error message won't go away. If anyone has any ideas or can correct my thinking, I sure would appreciate it.

-- 
James A. Mumper
Senior Oracle DBA
Pacific Bell Video Services
Received on Tue Jun 11 1996 - 00:00:00 CEST

Original text of this message