Discovering correct service names on a SUN Solaris, Oracle 8.1.6

Paul,

What is present snmp_ro.ora and snmp_rw.ora files on the Sun boxes (most likely in the same location as your tnsnames.ora on the Sun boxes).

Do these files refer to "prod", "prod.world" or "prod.srvf01"? If they refer to the incorrect domain - try a clean start of the agent on the Sun box.

That is (and your directory paths may vary - I wrote these notes for NT):

stop the agent

        from \oracle\admin\tns_admin (or where ever they are) delete the snmp_rw.ora
delete the snmp_ro.ora

        from \oracle\product\815\network\agent delete services.ora

start up the agent (and recheck the contents of the snmp_ro.ora and snmp_rw.ora)

also look at

        \oracle\product\815\network\log\nmi.log

Also, using SQLPlus on your OEM box, which of the following connect strings work:

        "prod", "prod.world" or "prod.srvf01"

What version of Oracle is running on the Sun boxes?

Also check out Metalink Note:71910.1 Subject: Common console discovery errors

Hope this helps.

Regards,
Bruce Reardon

-----Original Message-----
Sent: Thursday, 28 June 2001 10:10

Hi,

I've got Oracle Management Server (2.2) running on an NT Platform, with an Oracle 8.1.6 Repository Database held on the same server. I want to use this to remotely administer several databases on a variety of platforms on the network. All the databases on NT servers have been discovered neatly by OEM, with their (global) service names all present and correct. Flushed with success, I moved on to the Sun/Solaris databases.

Now the fun starts! We have two Sun/Solaris servers with newly-upgraded 3rd-party systems installed on them (the same software in each case). Each has a single instance called (unimaginatively enough) PROD. I looked at the initialisation parameter files for these DBs and discovered they each had
"db_name = PROD", but no mention of "db_domain". Consequently, they were
both running with a service name of simply "PROD". So I added the lines
"db_domain = SRVF01" and "db_domain = SRVF02" to the two initialisation
files, respectively (SRVF01 and SRVF02 being the server names), and bounced the instances on the 2 machines. Checking their generated parameters I discovered to my satisfaction that they had "service_names = PROD.SRVF01" and "service_names = PROD.SRVF02" respectively. So far so good! So, having checked that the Intelligent Agents were running (and, indeed, having bounced listeners and agents just to make sure they picked up the current settings), I loaded up Oracle Enterprise Manager and told it to discover node SRVF01. Which it did, successfully - however the database appeared in the list as simply "PROD". So presumably if I had then tried to discover node SRVF02, an error would have occurred, since that database would be called PROD, too!

Now, when the databases were created on the NT servers, they were created using the various wizards provided, so any relevant alterations of LISTENER.ORA and TNSNAMES.ORA (for instance) will have been handled automatically and invisibly. However, the databases on the Sun boxes were created using scripts, so the 3rd-party installer people will have manually made the necessary entries in these files. Our on-site knowledge of the intricacies of these files is, er, limited, to say the least. So, could any of you give me a few pointers as to which files I need to modify (and in what way!) in order that my OEM console will discover these instances under their correct service names?

Thanks!

Paul

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Reardon, Bruce (CALBBAY)
  INET: Bruce.Reardon_at_comalco.riotinto.com.au

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).