RE: Documentation for reasons to NOT use RAC?
- From: Don Granaman <DonGranaman@xxxxxxxxxxxxxxx>
- To: "development@xxxxxxxxxxxxxxxxx" <development@xxxxxxxxxxxxxxxxx>, "ganstadba@xxxxxxxxxxx" <ganstadba@xxxxxxxxxxx>
- Date: Tue, 23 Feb 2010 10:15:07 -0600
"In that respect I really liked Forms and Report"
Hmmm. Maybe you had different versions than we had, but one of the few things
I've found that absolutely refused to work with "a decent TAF tnsnames.ora
entry" was Oracle Forms. I couldn't tell you the version or exact symptoms as
it is was half a lifetime ago, but I did find:
Note ID: 248583.1
"Developer applications do not support TAF as there is no great advantage in
using it"
[...]
"As per now there are no current plans to support TAF in Developer."
Note only did Forms not support TAF, but if they connected using a TAF-enabled
alias, they bombed out - even in "non-failure" normal operations After filing
a TAR, we had to create tnsnames.ora entries with no failover at all for Forms
to even work.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Martin Bach
Sent: Monday, February 22, 2010 2:32 PM
To: ganstadba@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Documentation for reasons to NOT use RAC?
Hi Michael,
On 22/02/10 18:34, Michael McMullen wrote:
>
> Not mentioned is I think RAC requires a commitment from developers to
> program apps with RAC in mind. I find more and more that people think
> of the db as a block box and that thinking will kill the rac. So
> increased development costs should also be taken into consideration.
It's actually worse than that-I don't actually know anyone at work who is a
developer and understands RAC (there are lots of very talented people out there
but I didn't have the pleasure working with them). And that's not only current
work, that's past jobs as well. Hopefully you can use dedicated server
connections and a decent TAF tnsnames.ora entry to make _some_ use of RAC
without code changes. In that respect I really liked Forms and Report :)
Nowadays the dogma RDBMS = legacy is hammered into peoples' heads and hardly
anyone (leaving university) knows about Codd's or Date's books.
Too many hibernate implementations out there where developers don't even know
which part of their code produces a bit of SQL that is hammering the
interconnect, locking/latching madly etc. So yes, single instance with physical
standby(s!) is definitely better suited for such applications.
However, that said there are cases where RAC is absolutely essential and I love
working with it. There is no other database product out there I know with that
level of sophistication (if you exclude things like Streams/Advanced
Replication etc which cloud the overall picture a little). Don't make the
mistake however of buying 2 single core pizza boxes with 64G of RAM and
infiniband just to save on the RAC EE license cost-use Standard Edition instead
with your homegrown standby database maintenance scripts-I used to do this a
lot while working for a managed services provider in Brighton.
Off my soapbox now, and apologies to all good developers out there!
Martin
--
Martin Bach
OCM 10g
http://martincarstenbach.wordpress.com
http://www.linkedin.com/in/martincarstenbach
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
