Re: Oracle RAC
From: Mark D Powell <Mark.Powell_at_eds.com>
Date: Wed, 2 Sep 2009 12:43:58 -0700 (PDT)
Message-ID: <979f876d-360b-41b6-ad11-44647f690ca0_at_s39g2000yqj.googlegroups.com>
On Sep 2, 9:45 am, John Hurley <johnbhur..._at_sbcglobal.net> wrote:
> On Sep 2, 9:24 am, wa..._at_kutztown.edu (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.
>
> http://www.my-idconcept.de/downloads/You_Probably_Dont_Need_RAC.pdf
>
> 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.
Date: Wed, 2 Sep 2009 12:43:58 -0700 (PDT)
Message-ID: <979f876d-360b-41b6-ad11-44647f690ca0_at_s39g2000yqj.googlegroups.com>
On Sep 2, 9:45 am, John Hurley <johnbhur..._at_sbcglobal.net> wrote:
> On Sep 2, 9:24 am, wa..._at_kutztown.edu (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.
>
> http://www.my-idconcept.de/downloads/You_Probably_Dont_Need_RAC.pdf
>
> 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 -- Received on Wed Sep 02 2009 - 14:43:58 CDT