RE: Documentation for reasons to NOT use RAC?
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.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Martin Bach Sent: Monday, February 22, 2010 2:32 PM
Subject: Re: Documentation for reasons to NOT use RAC?
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 Bach OCM 10g http://martincarstenbach.wordpress.com http://www.linkedin.com/in/martincarstenbach -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Tue Feb 23 2010 - 10:15:07 CST