Re: Moving to RAC`
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: Ram Raman <veeeraman@xxxxxxxxx>
- Date: Tue, 3 Mar 2015 10:42:08 -0500
Don't forget client network connection changes - this is a very
significant one. If your application uses SID instead of SERVICE_NAME
to connect, or if there are any application scripts that directly
connect to an IP then you may be in for trouble. I've seen situations
where we went over this with teams and everyone gave the rubber stamp
saying the app was good -- and we still discovered surprise bits of
code months later. Not too long ago I saw an old upgrade script fail
because it pulled the IP from the jdbc string then tried to ssh there
and run an application SQL upgrade script. The SCAN IP was running on
a node which was in a different pool than the target database and the
SQL script actually ran in the wrong DB.
On a related note - your business thinks they will get "fault
tolerance" - but make sure they understand the app might need to be
restarted if there's a RAC node failure. Many businesses don't
realize that their app might still need a restart (causing some
downtime and all users to lose work and logon again). The app can be
coded by developers to avoid this restart (utilizing TAF and
callbacks). Version 12c provides a new feature called application
continuity to avoid the coding part, but (1) this is brand new and
should have thorough in-house testing before your business relies on
it and (2) it has its own requirements (like a specific client driver)
which your app needs to meet.
There's been a bit of discussion here about impact and simulation and
such. Since your business named "resilience and fault tolerance" (not
load) as a driver, there's a very simple solution. Just get servers
and storage the same spec as your current setup (or larger). Make
sure you run exactly the same version & patchset of Oracle on this
identical hardware. Then run the app on one node. This should reduce
your risk quite significantly and you can keep your business happy by
having "RAC" (notwithstanding the app-restart caveat above).
-Jeremy
--
http://about.me/jeremy_schneider
On Sat, Feb 28, 2015 at 7:01 PM, Tim Gorman <tim@xxxxxxxxx> wrote:
> From a performance perspective, the main difference between non-RAC and RAC
> should be the introduction of the "Cluster" class of events.
>
> If it were possible to compare two OEM "Top Activity Screens" side-by-side,
> from before RAC and from after RAC, then the introduction of the gray
> "icing" of "Cluster" waits over the blue of "User I/O" events and the red of
> "Concurrency" events should be the main difference.
>
> That's the visual way of looking at it.
>
> Compared statistically, all of the time spent hour-by-hour in all
> non-"Cluster" event classes should remain relatively constant before and
> after. If there is a radical change in any particular event class, then
> that would be a clue as to the problem. Changes in "CPU used by this
> session" or "User I/O" would indicate changes in SQL execution plan.
> Changes in "Concurrency" would indicate application changes having been
> snuck onboard. The only real difference should be the introduction of
> "Cluster" class events.
>
> As for the quantity of "Cluster" class waits, Andrew indicated ways to
> optimize, below...
>
>
>
>
> On 2/28/15 14:54, Andrew Kerber wrote:
>>
>> I think the top question is whether or not the application can be
>> segregated into at least two loads hitting two different data sets. Without
>> that you can get killed with cluster waits. When you do that of course you
>> use the service names to make sure users hit the appropriate servers.
>>
>> Sent from my iPhone
>>
>>> On Feb 28, 2015, at 12:55 PM, Ram Raman <veeeraman@xxxxxxxxx> wrote:
>>>
>>> List,
>>> We are considering moving one of our systems from non rac to 2 node
>>> rac, oracle 11g. Setting the question on the need for that move aside, what
>>> factors/metrics do we have to check in the current application or db to see
>>> if the application will work well with RAC.
>>> TIA, Ram.
>>
>> --
>> //www.freelists.org/webpage/oracle-l
>>
>>
>>
>>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
