Re: Moving to RAC`
Date: Sun, 01 Mar 2015 18:56:02 -0500
Message-ID: <54F3A712.5050100_at_yahoo.com>
OK, great. It seems to be OLTP database strewn into RAC configuration to attain fault tolerance. You should be monitoring for any process spending significant time on any event starting with "gc", especially "gc current block busy" and "gc current block". Any events like that mean that you are updating the same data from at least two different nodes. The "2 way" events aren't possible if you don't have 3 or more nodes. However, adhering to the principle of functional partitioning, which says that all DML operations on the same set of tables should be performed from the same node, is crucial. When you have a single instance installation, locks are essentially memory structures and locking a row means reading and modifying a memory location. Memory access times are measured in nanoseconds. If you have RAC, locks include network. And network communication is measured in milliseconds. Of course, if you want to run reports, then you have to monitor cache fusion, which is characterized by "gc cr" events, where "cr" stands for "consistent read". That, however, doesn't seem to be of too great concern in your situation. Cache fusion is a marketing name for the ability of Oracle to construct a consistent image of the block, consistent up to a SCN, and ship it to the requesting node. Yes, you guessed it, it also includes network communication, however caching can offset that.
On 03/01/2015 04:25 PM, Ram Raman wrote:
> "wants to achieve more resilience and fault tolerance" - That seems
> to be the goal.
>
> It is not a DW; they are not even thinking about running reports or
> backup in the other node.
>
>
>
> he said the need for RAC wasn't part of this discussion. So
> let's not worry about it and just advise him on his question.
>
> So one other thing to keep in mind. Companies may certify their
> application in RAC and only mean there is nothing in RAC that will
> break their App. Eg, the sequence issue mentioned before. That
> does not mean their app is suitable for RAC and will scale well in
> a RAC environment.
>
> But the answer to the question is crucial. If he wants to achieve more
> resilience and fault tolerance, he needs to set the system up one way
> and if he needs to run reports, it's another setup, and if the system
> is a DW system, it's yet another set of settings. To tell him how to
> scale, I must know what does he want to do and why. That's the
> philosophical catch 22.5.
>
>
>
-- Mladen Gogala Oracle DBA http://mgogala.freehostia.com -- http://www.freelists.org/webpage/oracle-lReceived on Mon Mar 02 2015 - 00:56:02 CET