Re: RAC and table partitioning
- From: Vasu <vasudevanr@xxxxxxxxx>
- To: K Gopalakrishnan <kaygopal@xxxxxxxxx>
- Date: Tue, 10 Jul 2012 21:40:50 -0500
Thanks to all for you reply, it made it very clear that
1. A careful partitioning strategy is essential (for non-trivial workload),
and
2. shedding some light on the "thought process" required to estimate where
time would be spent , and
3. Hinting Latest/ 11g remastering enhancements
you guys are awesome.
-Vasu
On Tue, Jul 10, 2012 at 1:00 AM, K Gopalakrishnan <kaygopal@xxxxxxxxx>wrote:
> Vasu. The benefits are higher than the cluster waits issue. With the new
> resource mastering algorithms each partitions can be mastered locally and
> you will have reduced inter instance messages. Resource mastering and
> remastering happens at segment level and partitions have big impact on
> this. Have a look at chapter 11 of my rac book if you have it handy. If not
> search for "rac resource mastering" in google you might find some
> interesting hits.
>
>
> On Monday, July 9, 2012, Vasu wrote:
>
>> Common sense says "data usage on RAC nodes- aligned to table partitions
>> " should do better.
>> Say, a table list partitioned on state column, thus dividing Txn activity
>> of major states such as NY and CA into 2 different partitions.
>> App is serviced by 2 node RAC, and all NY customers are served thru
>> node-1
>> , and CA customers thru node-2
>> Simple data load comparison shows that cluster-waits are more in the mixed
>> workload scheme.
>>
>> My question is : Has anyone seen significant/dramatic performance gains
>> by
>> aligning application usage to table partitioning ?
>> If so, what was the gain % (though it would largely depend on the workload
>> , h/w etc )
>>
>> Thanks in advance.
>> -Vasu
>>
>>
>> --
>> //www.freelists.org/webpage/oracle-l
>>
>>
>>
>
> --
> Sent from Gmail Mobile
>
--
-Vasu
--
//www.freelists.org/webpage/oracle-l
Other related posts:
