Re: Documentation for reasons to NOT use RAC?

  • From: Subodh Deshpande <deshpande.subodh@xxxxxxxxx>
  • To: TESTAJ3@xxxxxxxxxxxxxx
  • Date: Wed, 19 May 2010 15:59:20 +0530

my suggesiton will be do not talk about any technical things at this moment
ask about followings whcih everybiody can understand
what is the archicture of your applciation, purpose, business importance.
how many users want to use the application at a time, how many users will be
increase in next five years
how many concurrent sessions are there will be there
what is length (duration) of a transaction in these applications.
how much is the business cost of each transaction (means what if the
database is down for some considerable time, will the despatch, fund
transfer and other commercial transactions will be stopped ?) and how much
will be this loss.

if above questions are answered are satisfactorly then talk about platform,
servers, network security etc..

RAC is robust RAC+ standby/dataguard is excellent and RAC + RAC standby is
full proof..cost of resources who are working on these type of techology is
some what more than others and is management keen on thinking about these
expenses..

you will find a lot of technical white papers on how to built RAC, maintain
etc..

thanks..subodh

On 22 February 2010 18:22, <TESTAJ3@xxxxxxxxxxxxxx> wrote:

>
> I'm being pulled into a meeting later this morning to answer why we
> shouldn't put every db in RAC?  Any white papers etc, stating why its a bad
> idea?
>
> thanks, joe
>
> _______________________________________
> Joe Testa, Oracle Certified Professional
> Senior Engineering & Administration Lead
> (Work) 614-677-1668
> (Cell) 614-312-6715
>
> Interested in helping out your marriage?
> Ask me about "Weekend to Remember"
>



-- 
==============================
DO NOT FORGET TO SMILE TODAY
==============================

Other related posts: