Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Application migration from non RAC databases to RAC databases

Re: Application migration from non RAC databases to RAC databases

From: hpuxrac <johnbhurley_at_sbcglobal.net>
Date: Thu, 20 Sep 2007 11:39:30 -0700
Message-ID: <1190313570.708750.141270@y42g2000hsy.googlegroups.com>


On Sep 20, 1:14 pm, Vin <vinay.th..._at_gmail.com> wrote:
> Hello All,
>
> Do we have any material available on "migrating applications from
> non-RAC databases to RAC databases" ?
>
> I am asked to study the readiness of "application migration from
> non-RAC to RAC databses" and create analysis report. I am asked
> to analyse the changes required for making the migration APART
> FROM TECHNICAL DATABASE MIGRATION ? We know how to migrate
> database from non-RAC to RAC, what we need to know is "What
> needs to be done to avoid performance / configuration issues
> later after changing to RAC" etc.
>
> I would greatly appreciate any advice on this.
>
> Thanks,
> Vin

Here's the honest answer. The only true way to test how an application is impacted by moving it into RAC is to move it into RAC and then test it with serious workload representative of what the system does in a non RAC environment.

Just doing limited testing is not enough ...

Here's a couple of url's that may be interesting ...

http://kevinclosson.wordpress.com/2006/12/17/partition-or-real-application-clusters-will-not-work/

http://www.pythian.com/blogs/282/oracle-rac-cache-fusion-efficiency-a-buffer-cache-analysis-for-rac#more-282/

One of the point Kevin Closson makes is this ... RAC works best when applications accessing the instances are partitioned in such a way as to not require cross-instance data shipping. Christo might say the fewer blocks you share in cache between your nodes, the better RAC will run. ( Check out the script

Here's my point ... the better designed and more scalable your current applications are the more likely they might play nicely in a RAC environment. Might play nicely not will play nicely ... you can test and diagnose after putting the application into RAC ... when it is running under a suitably large and representative workload.

The corollary: the more problems that your current application have the more likely it is you may run into moderate to severe problems in a RAC environment.

What are some of the things that can cause application problems in a RAC environment? Well it's the same things that can characterize most bad oracle applications.

Doing work you don't need to do? Bad database design? Too many logical IO's ( aka bad SQL ? ) ... all the usual stuff Received on Thu Sep 20 2007 - 13:39:30 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US