Re: Moving to RAC`
Date: Mon, 2 Mar 2015 11:26:44 -0600
Message-ID: <CAHSa0M2cwaZs867NnqV8_w7FQfoW4FB9xa-+6uTxfjH2xLWR7Q_at_mail.gmail.com>
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> 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
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Mar 02 2015 - 18:26:44 CET