Re: EZ Connect with RAC?

Alex,

I had a heavy (almost religious) battle about a year ago at a CT site about the Thin vs. Thick JDBC client. IMHO, Thin (EZ Connect) is a nightmare for the DBA. I think the administrative scope if the DBA should include the configuration of the client as well, for the part of where and how to find the instance to connect to. Thin JDBC prevents just that. The application stores its connection data somewhere in a properties file, and when the DBA has to relocate a database to another server or has to fail/switch over a Data Guard configuration a dependency on this particular properties file arises, and he has to involve an application manager as well. With HA in mind extra dependencies are rather undesirable. The more people one needs to involve, the more time it will take to get systems available again, and the more miscommunication and errors are going to happen.

It took appr. a year before we got the Architecture Board convinced, and now they're planning to move to Thick slowly.

EZ connect is EZ setup, but difficult to manage. With OCI you can maintain one single tnsnames.ora, and distribute that. That can be a nightmare, as you probably know. You can replace it with OID, which isn't easy either. However, with EZ connect you might end up with as many types of undetectable configuration files as the number of applications you run. I think that is a very, very scary nightmare, from the viewpoint of the DBA. Therefor I very much dislike the naming 'EZ Connect'. It is a rather shortsighted way of looking to connection data administration. And nowadays, with the availability of 'Instant Client', installation of the extra client software can't be the problem anymore.

Just my $0.02

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===

On Thu, 2006-10-26 at 17:27 -0400, Alex Gorbachev wrote:

> Listers,
>
> We were discussing possible implementation of EZ Connect for one
> customer and our opinions vary.
>
> While EZ connect can definitely help clearing up the mess of badly
> controlled tnsnames this method has some disadvantages as well. One of
> them is EZ Connect with RAC - there are scenarios when using EZ
> Connect will cause loss of service. I personally don't like that idea
> very much; perhaps, because I tend to be too conservative.
>
> If you have experience with EZ connect, could you share the results?
> Any issues? If you switched from tnsnames.ora, why and whether it
> satisfied the targets?
>
> Thanks in advance,
> Alex
>
>

--
http://www.freelists.org/webpage/oracle-l