Re: Moving to RAC`

   Rational for conversion to RAC is always useful to know. However, you could do some level of statistics based analysis, using the following questions (I am not looking for answers to these questions, but, just trying to help with your thinking process for possible issues). These questions are formulated trying to capture the common problems seen in real world (and not a complete list either).

1. What is your single block read time? multi block read time?
2. What is the I/O workload breakup between db_file_sequential_read, db_file_multiblock_read, db file parallel read and direct path read events? Meaning, is the application mostly a OLTP workload or DW workload?
3. What is your average log file sync time? log file parallel write time? what is your maximum redo rate? Is LGWR able to keep up with the current redo rate?
4. What will be your future private network latency? Do you expect the application to generate excessive amount of GC traffic exceeding the throughput? Meaning, is the application access centered around a very few hot segments?
5. Do you have any primary key , unique, date/timestamp column indexes that are heavily inserted? Do you have partitioning license? can you modify application code, somewhat, easily?
6. What would be the size of buffer_cache increase after migrating to RAC? If DW workload, do you have enough memory to increase PGA?
7. Do you expect to see CPU starvation in any node on a consistent basis?
8. Do you have any sequence that has nocache, Order attribute set? Can you increase cache value of sequence?
9. Does your application issue excessive amount of DDL statements?
10. Does your application use connection pool? If so, can you introduce a delay in initial logins so that scan listeners distribute the connections uniformly? If not, can you partition the application workload to a node? Do you use services? or can your application convert to use services?

Cheers

Riyaj Shamsudeen
Principal DBA,
Ora!nternals - http://www.orainternals.com - Specialists in Performance, RAC and EBS
Blog: http://orainternals.wordpress.com/ Oracle ACE Director and OakTable member <http://www.oaktable.com/>

Co-author of the books: Expert Oracle Practices <http://tinyurl.com/book-expert-oracle-practices/>, Pro Oracle SQL, <http://tinyurl.com/ahpvms8> <http://tinyurl.com/ahpvms8>Expert RAC Practices 12c. <http://tinyurl.com/expert-rac-12c> Expert PL/SQL practices <http://tinyurl.com/book-expert-plsql-practices>

<http://tinyurl.com/book-expert-plsql-practices>

On Mon, Mar 2, 2015 at 9:48 AM, Andrew Kerber <andrew.kerber_at_gmail.com> wrote:

> 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_at_gmail.com> 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
> > 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-l