Re: Any APIs?

"Howard J. Rogers" <dba_at_hjrdba.com> wrote in message news:agb6hk$pha$1_at_lust.ihug.co.nz...
>
> "Karen" <abvk_at_ureach.com> wrote in message
> news:3D291B7B.88B29894_at_ureach.com...
> > > That doesn't get rid of anything, except a SID_LIST in Listener.ora.
You
> > > still need a Listener.Ora to tell the Listener what name it should
have
> and
> > > what port it should listen on -unless you are happy to accept the
> defaults,
> > > which are severely restrictive for most practical purposes.
> >
> > Defaults are restrictive, but in many cases they are sufficient. In
case
> you
> > are
> > not expecting the listener to do too much work, your host could run with
> just a
> > default listener and all databases can be autoconfigured. This in a
> perfect
> > world,
> > of course, I am not actually recommending to run the listener on 1521
and
> use
> > dynamic registration.
> >
> >
> >
> > >
> > > >
> > > > Oracle Names is a much better alternative to tnsnames,
> > >
> > > This statement just isn't true. Oracle Names is actually going to be
> > > de-supported (yup, it's *that* much better than tnsnames), and in the
> > > meantime it is only doing what tnsnames.ora does, but on a larger
scale.
> The
> > > magic point being the words 'larger scale'. When you've a couple of
> dozen
> > > clients to configure, automated distribution of tnsnames to PCs is
> probably
> > > far easier than building a Names infrastructure. Beyond that number,
> Names
> > > or similar LDAP-compliant technologies have compelling management
> advances,
> > > true. But Oracle nowehere promotes Names as a 'preferred' solution,
and
> > > tnsnames as a 'deprecated' one. They each have their niches.
> >
> > I do not like the idea of distributing tnsnames on client machines or
> > workstations even
> > if it looks simple and can be automated. Your tnsnames files will be
> getting
> > bigger as
> > the new databases are created, and you may have to replace all files on
> all
> > clients after
> > any change to any service name, or keep track of which clients need
which
> > services.
> >
> > Also, clients are allowed to make their own copies of tnsnames files,
and
> if
> > they do,
> > you cannot keep track of them.
> >
>
> I'm sorry Karen. We seem to be at cross-purposes. I know all the drawbacks
> of tnsnames. I know it isn't ideal in a constantly-changing environment. I
> agree with you on all of that. Where I take issue with you is your claim
> that Oracle is trying to get rid of tnsnames. It isn't. All its problems
> just mean that tnsnames is a horse for a certain course. But that course
> will always exist, and so (therefore) will tnsnames.
>
> > >
> > > >just like DNS is an
> > > > alternative to /etc/hosts.
> > >
> > > Precisely. I don't see /etc/hosts going anywhere soon, do you? And why
> not,
> > > indeed? For a dozen PCs, hosts is a perfectly reasonable solution, and
> > > no-one would seriously suggest that anyone was "trying to get rid of
> it".
> > > Horses for courses.
> > >
> > > HJR
> >
> > Of course not, but I would rather use DNS for clients as well, possibly
> leaving
> > /etc/hosts
> > as a backup resolution method. Same could apply to Names or other
dynamic
> > resolution
> > method in Oracle and tnsnames.
> >
>
> OK, you have a date to come and implement a full-blown DNS for my study
> (comprising 3 PCs). Do you think that might be a bit of overkill?
>
> My point is, I don't particularly care what your preferences are, or mine.
> You made a statement that Oracle were seeking to get rid of tnsnames and
> listner.ora. They aren't.

Oh well, apparently I was wrong. They are, but are keeping quiet about it until it happens in release 10i, 11i, 12 and a half eye or whatever it might be. One day these things will be gone. But not yet. I think I'll stand my ground on that last point - so meanwhile, deal with them, 'cos they ain't going nowhere quickly..

HJR
>
> HJR
>
>
>
> >
>
>
Received on Wed Jul 10 2002 - 08:07:07 CDT