Was: Recipe for application design to run on RAC, Now: Oracle nam

Hemant,

After having rolled out ONAMES twice in two large organizationations, it was apparent that the technicalities of ONAMES in itself is simple. It is in the compilation and reconciliation of the various entries, their variations and having to deal with the different default_domain/zone names as well as rolling out of the updated SQLNET.ORA to the desktop lies the challenge. You will _have_ to get the developers and other parties to co-operate and agree on both implementing and going forward with ONAMES. I would suggest a pilot first with a few developers and then a larger rollout, so the developers can see the benefits. I used a Server partitioning project (in 10.7 Apps) to push this through. I was fortunate that we had centralized the TNS files on NT fileservers in the previous organization and had the luxury of using SMS in the latter. The key, as I said before, is getting all the entries in and getting everyone to co-operate in using the new service (and not deviating by creating local TNS entries).

I do agree with Rich about the alias/entry modification - you need to capture the _exact_ entry for deregistration/registration. I did not go OID because of instability and the need to cater to older 7.3 databases/homes. Although Oracle has been threatening to drop ONAMES, the story is similar to the RBO - it lives on, even in 10i, although in an unsupported mode. And the current ONS has an option of export to OID (not sure about import?). There are not many knowledgable people within Oracle support who can help on ONAMES btw - you are pretty much on your own in many ways.

I am still amazed by the large number of even large organizations that do not use ONAMES, let alone OID, so don't feel bad. And learn Perl - I forced myself to learn and use Perl when I was handling and merging all the different TNSNAMES.ORA files. Let me know offline if you need specifics.

John Kanagaraj
Oracle Applications DBA
DB Soft Inc
Work : (408) 970 7002

Listen to great, commercial-free christian music 24x7x365 at http://www.klove.com

• The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers **

>-----Original Message-----
>From: Jesse, Rich [mailto:Rich.Jesse_at_qtiworld.com]
>Sent: Friday, November 29, 2002 9:59 AM
>To: Multiple recipients of list ORACLE-L
>Subject: RE: Recipe for application design to run on RAC
>
>
>If you're thinking of going ONAMES, consider OID. There are
>downsides to
>each, however, that you'll need to consider.
>
>1) There is no mechanism in ONAMES to modify an alias. As per Oracle
>Support, you'll need to drop and recreate the alias instead.
>(Or you can
>modify the repository directly, but that's not encouraged)
>
>2) Replication on OID is one huge PAIN! Because of the way
>OID works, the
>two OID DBs are not fully replicated. Instead, it's an AR hack. As of
>9.0.1 at least, replication was unstable enough for us to dump OID
>completely. That and the fact that Oracle Support was of very
>little help,
>the documentation is HORRIBLE, and apparently RH 7.1 Linux
>isn't the best
>platform for OID 9.0.1.
>
>Just some things to consider...
>
>Rich
>
>
>Rich Jesse System/Database Administrator
>Rich.Jesse_at_qtiworld.com Quad/Tech International,
>Sussex, WI USA
>
>> -----Original Message-----
>> From: Hemant K Chitale [mailto:hkchital_at_singnet.com.sg]
>> Sent: Friday, November 29, 2002 9:54 AM
>> To: Multiple recipients of list ORACLE-L
>> Subject: RE: Recipe for application design to run on RAC
>>
>>
>>
>> No one here [including me !] knows Oracle Names or OID.
>> There's a profusion of TNSNAMES.ORA files for various databases
>> and applications but not Oracle Names.
>>
>> I've been thinking and thinking of Oracle Names for a year and
>> haven't got around to it . [I guess you'll think twice before hiring
>> me as a DBA <: ]
>>
>> Hemant
>>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: Jesse, Rich
> INET: Rich.Jesse_at_qtiworld.com
>
>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting services
>---------------------------------------------------------------------
>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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: John Kanagaraj
  INET: john.kanagaraj_at_hds.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).