Re: Moving to RAC`
- From: Andrew Kerber <andrew.kerber@xxxxxxxxx>
- To: "veeeraman@xxxxxxxxx" <veeeraman@xxxxxxxxx>
- Date: Mon, 2 Mar 2015 11:48:00 -0600
I can't think of any way to simulate a RAC without building one. Though you
could virtualized it onto a single physical sever to get some idea.
Sent from my iPad
> On Mar 2, 2015, at 11:26 AM, Ram Raman <veeeraman@xxxxxxxxx> 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@xxxxxxxxxxxxx>
>> 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
Other related posts:
