Re: Process and sessions overhead

  • From: coskan@xxxxxxxxx
  • To: niall.litchfield@xxxxxxxxx,"K Gopalakrishnan" <kaygopal@xxxxxxxxx>
  • Date: Tue, 8 Mar 2011 18:14:48 +0000

We had the same issue with log file sync. There are multiple hidden parameters 
adjusted with process parameter and one should be carefull with processes 
parameter. On our case we kept memory same increased process from 400 to 500 
and started to see log file syncs unfortunatelly I cannot say that's 100 
percent the cause because to fix the issue even we adjusted sga target by %25 
just to keep the percentage same but we also did 11g upgrade on the same day 
and everything sorted. 

I can't also be sure because we also see io slowness on another db sharing same 
san and could not get a decent answer from storage guys during the issue (they 
already knew we increased the parameter without necesary memory adjustment so 
they did not even bother to check)


I also could not find any 10g reference for causing log file sync


Regards 
------------------

-----Original Message-----
From: Niall Litchfield <niall.litchfield@xxxxxxxxx>
Sender: oracle-l-bounce@xxxxxxxxxxxxx
Date: Tue, 8 Mar 2011 17:56:49 
To: K Gopalakrishnan<kaygopal@xxxxxxxxx>
Reply-To: niall.litchfield@xxxxxxxxx
Cc: <JC1706@xxxxxxx>; <oracle-l@xxxxxxxxxxxxx>
Subject: Re: Process and sessions overhead

Hi
Its a surprise to me that log file sync should be affected by the size of
the process table, rather than the number of active processes (or private
redo strands presumably?)

On 8 Mar 2011 17:14, "K Gopalakrishnan" <kaygopal@xxxxxxxxx> wrote:

Jon/Niall,

Other than the usual minimal memory overheads, there is significant impact
on

1. Log File Sync Wait times
2. Calculated Value of MBRC

Starting from 10gR2, MBRC is auto tuned. The value of processes is taken in
to consideration (along with buffer cache,etc) while calculating the MBRC.
So I would exercise caution while playing with these parameters.

-Gopal




On Tue, Mar 8, 2011 at 11:07 AM, Niall Litchfield <
niall.litchfield@xxxxxxxxx> wrote:
>
> Or I c...

Other related posts: