Re: EZ Connect with RAC?

Thanks for your response.
You follow exactly my track of thoughts. The way moving services to another location and re-pointing would be done is with DNS. So in the simple way we should theoretically be covered. However, I foresee that for whatever reason we need a more complex change and than we (or the client) are doomed trying to change it in every place in zillion places of zillion applications. Plus so far it seems that proper RAC configuration will still require more advanced technique be it tnsnames.ora/LDAP/Names leading to double standards.

On 10/26/06, Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl> wrote:
>
> 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 onecustomer and our opinions vary.
> While EZ connect can definitely help clearing up the mess of badlycontrolled tnsnames this method has some disadvantages as well. One ofthem is EZ Connect with RAC - there are scenarios when using EZConnect will cause loss of service. I personally don't like that ideavery 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 itsatisfied the targets?
> Thanks in advance,Alex
>
>
>
>

-- 
Best regards,
Alex Gorbachev

The Pythian Group
Sr. Oracle DBA

http://www.pythian.com/blogs/author/alex/
http://blog.oracloid.com

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