Message-ID: <54F5DE83.7020902@yahoo.com>
Date: Tue, 03 Mar 2015 11:17:07 -0500
From: "Mladen Gogala" <dmarc-noreply@freelists.org> (Redacted sender "mgogala@yahoo.com" for DMARC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: oracle-l@freelists.org
Subject: Re: Moving to RAC`
References: <CAHSa0M3hZwfZMU+ef64sSLm9Hn0qFuVO5PYz=txMZJH1gYJj9g@mail.gmail.com>	<54F2A8DD.6010703@yahoo.com>	<97994FB2-50CD-463F-B745-BDB484A89240@gmail.com>	<54F34DFA.6050508@yahoo.com>	<CAHSa0M0JQ8a3WmhjxPvSWmTLD5490widJBSCGkiRx=6QLGokmQ@mail.gmail.com>	<54F3A712.5050100@yahoo.com> <CAHSa0M2cwaZs867NnqV8_w7FQfoW4FB9xa-+6uTxfjH2xLWR7Q@mail.gmail.com>
In-Reply-To: <CAHSa0M2cwaZs867NnqV8_w7FQfoW4FB9xa-+6uTxfjH2xLWR7Q@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------020909070704010504010901"
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: dmarc-noreply@freelists.org
--------------020909070704010504010901
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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@freelists.org <mailto:dmarc-noreply@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


--------------020909070704010504010901
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">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.<br>
      <br>
      <br>
      On 03/02/2015 12:26 PM, Ram Raman wrote:<br>
    </div>
    <blockquote
cite="mid:CAHSa0M2cwaZs867NnqV8_w7FQfoW4FB9xa-+6uTxfjH2xLWR7Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>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. </div>
        <div>  </div>
        <br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Sun, Mar 1, 2015 at 5:56 PM,
            Mladen Gogala <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:dmarc-noreply@freelists.org"
                target="_blank">dmarc-noreply@freelists.org</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div>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.<br>
                  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.
                  <br>
                  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.
                  <div>
                    <div><br>
                      <br>
                      On 03/01/2015 04:25 PM, Ram Raman wrote:<br>
                    </div>
                  </div>
                </div>
                <div>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div> "wants to achieve more resilience and fault
                        tolerance" - That seems to be the goal. </div>
                      <div><br>
                      </div>
                      <div>It is not a DW; they are not even thinking
                        about running reports or backup in the other
                        node.<br>
                      </div>
                      <div><br>
                      </div>
                      <div>
                        <div class="gmail_quote">
                          <div>
                            <div><br>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </div>
              </div>
            </blockquote>
          </div>
          -- <br>
          <div>
            <div dir="ltr">
              <div>
                <div dir="ltr">
                  <div>
                    <div dir="ltr">
                      <div> </div>
                      <div>You can become a doctor and then websearch
                        for solutions; You cannot websearch and become a
                        doctor<br>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Mladen Gogala
Oracle DBA
<a class="moz-txt-link-freetext" href="http://mgogala.freehostia.com">http://mgogala.freehostia.com</a>
</pre>
  </body>
</html>

--------------020909070704010504010901--
--
http://www.freelists.org/webpage/oracle-l