Re: Get list of databases

From: Bert Bear <bertbear_at_NOSPAMbertbear.net>
Date: Thu, 21 Nov 2002 20:58:11 GMT
Message-ID: <DNbD9.3628$J93.1487145183_at_newssvr12.news.prodigy.com>


"Karsten Farrell" <kfarrell_at_belgariad.com> wrote in message news:9T8D9.2092$_G7.44331322_at_newssvr14.news.prodigy.com...
> Bert Bear wrote:
> > Karsten,
> >
> > As for LDAP .vs. ONAMES, he needs a solution today (not someday over the
> > rainbow).
> >
> LDAP is available right now ... today ... this instant ... he doesn't
> have to wait for that pot o' gold.
>

Karsten,

OID (LDAP) isn't the end all to be all, for those with legacy issues! A couple of points:

  1. A client can't use it concurrently with many of the previous Oracle versions (7.3.4, 8.0.5, 8.1.6, 8.1.7, etc.) I point you to:

http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_datab ase_id=FOR&p_id=83157.996

where it says, in part:

>5. Can OID be used concurrently with 7.3.4, 8.1.6 and 8.1.7 databases?

> According to the certification matrix, which you can access on MetaLink
> under Product Lifecycle, OID does not work concurrently with different
> database versions on the platforms you specified. On Sun SPARC
> Solaris 2.6, OID 2.1.1 is certified with 8.1.7, and OID 2.0.6 is certified
> with 8.1.6. On IBM Dynix 4.4.6, OID 2.0.6 is certified with 8.1.6. Older
> pre-LDAP clients will continue to rely on some pre-LDAP name-lookup
> (onames, tnsnames, etc).

[Quoted] The original posting did NOT specify which Oracle versions the person was [Quoted] using. I have clients still using Oracle 7.3.4 in production! My suggestion of ONAMES would support 7.3.4 through 9i database services, as the original poster might be using these database versions.

The above document (83157.996) also goes on to state:

> Depending on the scale of your Oracle Names implementation (how far
> along you are) and other timing factors, you may want to begin with
> ONames and migrate to LDAP." While I'm not trying to get off the
> hook of missing the ONAMES desupport notice, clearly for those
> using Oracle 9i and below ONAMES has value (especially for those
> starting out and can later migrate to LDAP).

Please notice the key sentences: "you may want to begin with ONames and migrate to LDAP." and "clearly for those using Oracle 9i and below ONAMES has value (especially for those starting out and can later migrate to LDAP)." Clearly, the original poster would be in this situation as his company is using Oracle 9i and below and can later migrate to LDAP.

> Along with the LDAP system, Oracle Names will provide compatibility
> features which will enable it to synchronize with the data in the OiD, and
> provide that data to pre-LDAP clients in the network. Deploying OID
> for NET8 is free of charge.

Please notice the key sentence: "Oracle Names will provide compatibility features which will enable it to synchronize with the data in the OiD, and provide that data to pre-LDAP clients in the network" As I read it, ONAMES still has a place (remembering the original posting didn't specify which Oracle database level and it might be 7.X).

To be honest, I missed the desupport notice for ONAMES, but I would still have recommended ONAMES to the original poster. While the mesage would have been different, my recommendation (unless all the databases are 9i, as one version of OID still doesn't cover all of 8X versions let along 7.X) would still be the same. I'm not a bleeding edge type of guy, unless the client desires bleeding edge!! I believe in inclusive solutions (not inclusive rates :-) ).

On the other hand, I didn't miss the desupport notice for Oracle 9i (http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_data base_id=NOT&p_id=190435.1). It is NOT going to stop me from using Oracle 9i, 8i, or even 7.3.4 on my OS/2 Warp server system. Hell, I have one client still using Oracle 7.3.4 (Windows/NT not OS/2 Warp Server)! The past is always around us.

Bertram Moshier
Oracle Certified Professional 8i and 9i DBA

http://www.bmoshier.net/bertram Received on Thu Nov 21 2002 - 21:58:11 CET

Original text of this message