Re: Urgent rac wait problem
- From: Dion Cho <ukja.dion@xxxxxxxxx>
- To: adar666@xxxxxxxxxxxx
- Date: Tue, 17 Mar 2009 11:01:35 +0900
There should be other reasons for your problem like bind peeking or
different optimizer configurations.
http://www.pythian.com/news/867/stabilize-oracle-10gs-bind-peeking-behaviour-by-cutting-histograms
Oracle has only one source of statistics. Statistics is per database, not
per instance.
Optimizer puts the system performance into consideration only by means of
system statistics. But system statistics is per database, not per instance,
which means that hardware configuration like CPU count, CPU performance,
memory size and I/O performance has same effect on the multiple instances.
================================
Dion Cho - Oracle Performance Storyteller
http://dioncho.wordpress.com (english)
http://ukja.tistory.com (korean)
================================
On Mon, Mar 16, 2009 at 6:50 PM, Yechiel Adar <adar666@xxxxxxxxxxxx> wrote:
> Since this is the only difference between the servers,
> I think that the number of cpus and the memory size may be a factor in the
> optimizer calculations.
> In the server with fewer resources oracle choose another path that needed a
> lot more blocks,
> but used less online memory, and caused a lot more gc 2-way wait.
> I never delved deep into the optimizer.
>
> Adar Yechiel
> Rechovot, Israel
>
>
>
> Dion Cho wrote:
>
>> You solved your problem by updating the statistics.
>>
>> Why on the earth do you think that CPU count and physical memory size were
>> the reasons?
>>
>> ================================
>> Dion Cho - Oracle Performance Storyteller
>>
>> http://dioncho.wordpress.com (english)
>> http://ukja.tistory.com (korean)
>> ================================
>>
>>
>> --
>
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
