Re: lms flush message acks

Alek,

firstly, what makes you think that 'lms flush message acks' is a problem? what is the premise based on which you decide that it is an issue?

what is the exact nature of the problem you are facing in your RAC database? or is that you are just bothered about this particular wait event?

could you send us the top 5 wait events from your AWR or Statspack report?

assuming you have not changed any of the default values for the _gc* parameters, lms related log flushes are generally caused by high no. of requests for current mode blocks from remote instances. over-commiting in the application can also contribute to the problem.

i am not visting internal oracle related causes for this wait event but only application/user created causes.

frequent log flush (hence redolog writes) could be a result of high no. of current block transfers across the interconnect (because remote instance repetitively ask for current blocks). most (if not all) current block requests by remote instances requires that the holder flush his redo before sending across the dirty block. LMS does this job.

another indirect cause is a slow LGWR (due to slow disk where redologs are placed). are they on raw devices or ASM?

what are the values for the following statistics (all instances),

"gc current block flush time"
"Avg global cache current block flush time (ms)"
"Global cache log flushes for current blocks served %"

what is the value for fast_start_mttr_target in your instances?

There is some useful information you can dig up in V$CURRENT_BLOCK_SERVER. cheers
anand

K Gopalakrishnan wrote:
> Yong,
>
> Dynamic remastering has undergone tremendous changes in recent
> versions. They are controlled by multiple _gc_affinity parameters.
> Since 10gR2 does remastering based on objects, I suspect that could be
> the issue for the original poster. However he can confirm that with a
> simple 10046 trace where the lms flush wait will show the object ids.
>
>
> -Gopal
Received on Mon Jul 03 2006 - 00:18:52 CDT