Re: Moving to RAC`
Date: Tue, 03 Mar 2015 11:17:07 -0500
Message-ID: <54F5DE83.7020902_at_yahoo.com>
The important thing is to baseline your performance now, without RAC, and record your application performance, with detailed response times. If possible, use some web enabled automated test suite to test your application performance. Then see what is different when you switch to RAC and tune the parts that are not performing according to expectations.
On 03/02/2015 12:26 PM, Ram Raman wrote:
> Thank you all. The cache related waits can be measured after we go
> live with RAC. Is there any metric in the current single instance that
> can potentially shed light on future behavior after RAC move or any
> tool that can simulate RAC load? Or is the only way to find that out
> is to build a test cluster and simulate a prod load in that test
> cluster using a tool like RAT? Other tool recommendations are
> welcome. We do not want to do go live with RAC and then hit with
> surprises.
>
>
> On Sun, Mar 1, 2015 at 5:56 PM, Mladen Gogala
> <dmarc-noreply_at_freelists.org <mailto:dmarc-noreply_at_freelists.org>> wrote:
>
> 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.
>>
>>
> --
> You can become a doctor and then websearch for solutions; You cannot
> websearch and become a doctor
-- Mladen Gogala Oracle DBA http://mgogala.freehostia.com -- http://www.freelists.org/webpage/oracle-lReceived on Tue Mar 03 2015 - 17:17:07 CET