Re: Documentation for reasons to NOT use RAC?
- From: Martin Bach <development@xxxxxxxxxxxxxxxxx>
- To: katpopins21@xxxxxxxxx
- Date: Wed, 19 May 2010 20:22:33 +0100
Hi Kathy!
I would like to comment on this as well...
On 19/05/10 17:40, kathy duret wrote:
> Sorry this was sent out too fast...
>
> If you have small non critical applications I am not sure why you would
> bother with RAC
Agree completely-an active/passive cluster might suit you just fine.
>
> RAC costs alot of money in terms of software and licenses.
This is true and not, from two different points of view. If you have say
1 application only for which each minute of downtime is worth thousands
then RAC license costs are negligible.
Also, if you are consolidating many databases previously located on
their individual box then RAC costs can be marginalised too.
And if you can live without Data Guard (i.e. have an Oracle 7.3.4 style
standby database) then SE RAC is _very_ competitive. Add the extended
distance option for 11.1 and newer SE RAC and you won't find a similar
HA solution for that money in the market.
>
> Rac costs more to implement and maintain as you need people qualified to
> be able to implement , maintain it, patch it.
Some time ago I was working for a small managed services provider and
supported a number of mission critical RAC systems for which no in-house
administration team existed. The current company I am working for was in
a very similar situation having outsourced the database administration
within London (and now sourced it back in)
>
> You now have added clustered software, VIPS, ASM, Services, Srvctl,
> complex datasources, load balancing and all the glory that goes with
> patching and maintaining all of it?
>
> And in my opinion, I think RAC still has more downtime than a regular db
> with a standby.
> There are many patches that still require the whole RAC to be down then
> patched. With a normal db you don't have cluster and ASM patches. More
> complexity, more bugs, more patches.
I think the situation is partly getting better with online ("hot")
patching and most 11g patches are rolling anyway. ASM 11.1 can also be
patched in a rolling fashion (not 11.1.0.6 though, there is a bug
preventing you from doing so). I just applied PSU 11.2.0.1.1 on my 4
node cluster without application downtime-UCP and FAN/FCF made the
patching exercise transparent.
>
> You have to have developers would DO understand how to connect to RAC
> else why bother. If node 1 goes down and the datasources are all
> pointing to one, guess what... apps not failing over. No load
> balancing. So why did you even bother with all that expense of the
> duplicate hardware, software in the first place?
FAN and FCF again to the rescue! I mentioned those earlier in a post,
have a look at those, it's a great combination.
>
> Don't get me wrong, I have RAC and I am not afraid to use it.
>
> But RAC isn't the whole story. You may still need a standby for off
> site recovery,
And one for QA or staging or whatever your pre-prod environment is where
the final testing takes place. The DBAs also should have one to try new
things, although that could be virtualised.
>
> Rac is getting easier to set up and maintain and more rolling patches
> are coming out.
>
> Lots of thought and testing needs to go into RAC. For me RAC is
> mission critical, large and you can separate apps into services on the
> nodes PLUS you need people who can implement and maintain it from the
> network, sys admins, dba, developers and managers.
>
> Is it worth it? Depends on your application and how much you can afford
> to be down and the company can afford to invest.
>
> My 3 cents worth (it is rac so I threw in an extra penny)
>
> K
[...]
>
> Yong Huang
>
>
Martin
--
Martin Bach
OCM 10g
http://martincarstenbach.wordpress.com
http://www.linkedin.com/in/martincarstenbach
--
//www.freelists.org/webpage/oracle-l
Other related posts:
