Re: Oracle RAC

From: Shakespeare <>
Date: Wed, 02 Sep 2009 21:56:12 +0200
Message-ID: <4a9ecdc0$0$83235$>

Mark D Powell schreef:
> On Sep 2, 9:45 am, John Hurley <> wrote:
>> On Sep 2, 9:24 am, (Jim Watts) wrote:
>>> We are going to be implementing a new Student Information System which will be
>>> using Oracle 11G for the database.  We are looking at RAC and are
>>> interested what some of the gotachs.  What are some of the things that can not
>>> be done if using RAC versus not RAC (as in software updates and such).  I have
>>> read through some of the documentation but over the years have learned to it
>>> does not always tell you everything.  I have gone through a few forums and
>>> news groups but it is all running together at this point.
>>> Any information and insight is greatly appreciated.
>>> Regards,
>>> Jim Watts
>>> Kutztown University
>> Take a look at this ( if you don't want to download it from a site
>> ending in .de ... find it somewhere else ).
>> Why you probably don't need RAC ... written by a real expert and
>> former Oracle employee.
>> Unless you have some really strong experienced RAC DBA's ... you
>> probably will end up with more downtime not less attempting something
>> like this.
>> The regular uptime of most servers ( especially unix/linux ) ones does
>> not have much downtime.  Probably more than reliable enough for many/
>> most organizations.
>> RAC does do a good job of selling Oracle software licenses and can be
>> helpful in certain cases.  It is good experience on a resume for a DBA
>> to have.
>> There's a ton of similar discussions here on cdos from the past.  If
>> you use the google groups interface you can search and find them
>> pretty easily.

> The author of the why you Probably do not need RAC has moderated his
> views over the years as RAC has improved which is not to claim he
> wholeheartly endorces it either.
> RAC does have its advantages and many sites are very happy with it.
> I am pretty sure there are issues with trying to use dbms_pipe feature
> in a RAC environment. We have had issues with using dbms_alert and
> dbms_lock in a RAC environment though we do use dbms_lock fairly
> successfully to single thread tasks that should not run concurrently.
> It is very expensive from a License point of view.
> HTH -- Mark D Powell --

Does not have to be expensive. Standard Edition comes with RAC at no extra license fee. With limitations of course (max 4 sockets per server, have to use Oracle Clusterware).
But since the OP wants advanced security as well. SE may not be an option.

Shakespeare Received on Wed Sep 02 2009 - 14:56:12 CDT

Original text of this message