Re: Net8 Lookup Method Options - tnsnames(Local) vs. Hostname vs. Onames/LDAP

On Sat, 29 Nov 2003 12:33:49 -0600, "Burt Peltier" <burttemp1ReMoVeThIs_at_bellsouth.net> wrote:

>"Sybrand Bakker" <gooiditweg_at_sybrandb.nospam.demon.nl> wrote in message
>news:umvgsvourqne30skm5la8bmf13unj9kjum_at_4ax.com...
>> Comments embedded
>>
>> On Sat, 29 Nov 2003 00:28:55 -0600, "Burt Peltier"
>> <burttemp1ReMoVeThIs_at_bellsouth.net> wrote:
>>
>> >Just looking for some opinions (or please correct me if I am wrong) on
>this
>> >subject...
>> >
>> >Just my 1 opinion, but it seems most shops could just use the Hostname
>> >Method for most databases and then have a 2nd fallback method (multiple
>> >methods easily configured in sqlnet.ora in 1 line) of the simpler
>> >Local(tnsnames) Method.
>> >
>> >The other option of Onames/LDAP seems like overkill for something as
>simple
>> >as looking up a database, especially in an Intranet network (most
>shops?).
>> >
>>
>> IIRC, as soon as you have multiple instances on one server, you can't
>> use the hostname method. Hence I assume most shops can't use the
>> hostname method at all.
>
>Not true.
>
>I can see posting comments on Onames which you seem knowledge-able about,
>but you obviously know almost nothing about Hostname.
>
>We have as many as 5 production instances (for the last 3 years I might add)
>on 1 machine using Hostname by using a separate TCP/IP alias. The alias that
>the GLOBAL_DBNAME points to in the listener.ora for each individual database
>is the one that works for it.

Yeah sure, but you can't use failover nor standby database if you are using the global_dbname syntax. Apparently you don't have standby databases and you don't have to use failover

>
>>
>> >1) The Local Method which uses a tnsnames.ora file has problems, but is a
>> >well known method. It of course has the biggest disadvantage of
>replication
>> >at the file system level. Of course, depending on the size of the
>company,
>> >the replication could be simple or very complex and problematic.
>>
>> Usually no tnsnames.ora will be identical, because people want to have
>> their 'own' databases only. Also name resolution using tnsnames.ora is
>> definitely much slower than using onames. Basically, in many
>> orgnisations tnsnames will be a PITA
>>
>>
>
>I agree that tnsnames.ora can become a "mess" (multiple copies), if clients
>can change where Oracle picks up the tnsnames.ora from (and there are
>several ways to change this). That is why we consider it a fallback to
>Hostname. Also, in our new organization, client's W2K ("locked") desktops
>prevent them from easily changing this, although we have a process where a
>client could easily add 1 entry to the top of the tnsnames.ora file. Being
>at the top it will never override production entries below it in the
>official tnsnames.ora (which is not edit-able by clients).
>
>It seems the only people that want (or should be allowed) to have their
>'own' databases are mainly developers/DBAs or support staff. This seems
>required to do their job and they should be able to fix their own "multiple
>copies mess". In our new organization, these people are "unlocked" and can
>do anything on the desktop.
>
>> >
>> >2) The Hostname Method is by far the simplest to implement and maintain.
>>
>> Not true.
>
>Statement #2 is of course true.

Statement #2 is of course not true. There are too many limitations of using the hostname method. Apparently you have already decided the hostname method is *always* better despite the limitations being mentioned. So I don't see why you bring this into discussion if you see using the hostname method basically as your 'gospel'

>
>So, you are saying adding 1 line to the listener.ora and creating 1 TCP/IP
>alias is not simple? Absolutely ZERO client *.ora files are required ... is
>not simple?
>
>>
>> It
>> >simply uses the existing DNS IP lookup method. It has the big advantage
>of
>> >ZERO client configuration and ZERO extra infrastructure (no Onames or
>LDAP
>> >server required and no file system replication required). It also appears
>to
>> >be quicker in every case (even when Hosntame is the LAST method to check
>in
>> >the sqlnet.ora config file specification - ok just 30 or 40 milliseconds,
>> >but still quicker).
>> >
>> >Of course it has the big disadvantage of requiring use of all defaults
>for
>> >things like port number and use of a TCP network. There are a couple of
>> >other limitations like you cannot use MTS or "failover - some NT/W2K
>option
>> >I think - not sure".
>>
>> Failover has NOTHING to do at all with a specific platform. You are
>> confusing failsafe and failover.
>> I wouldn't call not being capable to use MTS a 'limitation'. That is
>> just a blatant understatement.
>
>Ok. As I said "not sure" . You are probably correct ... I am confusing those
>two... failsafe and failover.
>
>I don't think I am understating anything ... I specifically listed all the
>limitations ( I could think of and even 1 I was unsure of) and to catch
>everything else ... I said anything that is not a default in tnsnames.ora
>will not be possible with Hostname method.
>
>So, what exactly is the understatement?
>
>> >
>> >But, aren't most people NOT using these non-default Net8 options and
>> >therefore Hostname Method would work for most databases? With a simple
>and
>> >well understood fall-back method like Local(Tnsnames), would this be a
>> >problem (used for some emergency or in case a non-default option becomes
>> >necessary)?
>> >
>> >3) Onames (which will be replaced by LDAP storage) seems to have the
>> >disadvantage of requiring the most extra infrastructure. I say "seems"
>> >because I sorta remember someone saying it works best with an OID (Oracle
>> >Internet Directory) LDAP storage . And, I am guessing not that many shops
>> >have OID implemented for LDAP.
>> >
>> >Onames seemed cleaner and less problematic because at least it could be
>> >stored in an existing database (as opposed to OID which I think should be
>> >installed in a database dedicated to OID). Also, Onames could cache the
>> >information in a local file if the Onames storage database was down,
>which
>> >again seems to make it also better than the LDAP replacement.
>> >
>>
>> Onames *ALWAYS* caches the information, so Onames doesn't need to
>> access the database to resolve a request. The cache file is
>> synchronised at regular configurable intervals, and you can have
>> delegated administration in various regions. Also, you don't need to
>> maintain database links anymore.
>>
>> >
>> >
>> Seems like you don't have any working experience with Onames, and your
>> background is a small company. If you have a larger organizations
>> Onames and/or LDAP is the way to go.
>>
>
>Wrong. I work for a large corporation.

If you work for a large corporation I fail to see why you don't set up Oracle names.

 I have worked with Onames on a 2nd
>job and it has been 5 years. So, I forgot the detail about always cache'ing
>to a local file.
>
>I should "refresh" my Onames knowledge - oh wait. That's true, Oracle says
>it is going away. So, why learn it?

So you don't know anything about RBO because Oracle has deprecated it 10 years ago? Come on!

>
>As for LDAP... someone knowledge-able can please correct me on this if I am
>wrong , but doesn't LDAP work better with OID (Oracle Internet Directory)?
>
>Also, isn't the only other LDAP choice M$ 's implementation ?
>
>I feel sorry for Onames clients ...
>
>>
>> --
>> Sybrand Bakker, Senior Oracle DBA
>

--
Sybrand Bakker, Senior Oracle DBA