Re: latch-free SCN scheme (10.1.0.3)
- From: Martic Zoran <zoran_martic@xxxxxxxxx>
- To: oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 16 Feb 2005 13:24:42 -0800 (PST)
Hi Tanel,
--- Tanel Põder <tanel.poder.003@xxxxxxx> wrote:
> If logwriter is able to write redo to disk directly
> from private strands,
> then some kind of latching or synchronization
> mechanism has to be used
> again, to protect private strands from changing
> while lgwr is writing data
> to disk....
I was thinking on commit the process needs to post
lgwr anyway than wait lgwr to finish and come back.
That means maybe no need to protect but more to
synchronize if it is private strand (I suppose
semaphore is in the game or I am wrong ???).
> Shared strands are in old log buffer area, since
> they can accommodate
> changes from different processes at the same time.
> Before 9i, there was only
> one redo log strand, protected by one redo
> allocation latch, but from 9i the
> log buffer can be logically split into multiple
> strands, each protected by
> its own redo allocation latch (it's controlled by
> log_parallelism parameter
> as Connor mentioned yesterday).
You are right about private strands be in the shared
pool. Then the log buffer space can consist of old
fashion log buffer space with shared strands + private
strands shared pool.
Then everything we knew about old log buffer space,
log_parallelism (improved with the dynamic child
allocation latches) is there.
Just not sure, who is and how allocating private
strands to transactions?
Interesting trade off on Oracle side.
> If you look at v$sgastat, there is private strands
> memory area under shared
> pool, which is quite large. So I guess they're kept
> there, testing and some
> heap dumping would reveal it...
That is true as I said earlier.
For me it is only 1.2M. What is 1.2M when you have
much more memory :)
> Where no DBA has gone before? ;)
Keeping us alive or maybe just funny because of wasted
time.
The strange thing is that you have private and shared
strands with either zero-copy redo or without.
These are combinations I have got:
Dynamic strands is set to TRUE
Running with 1 shared and 18 private strand(s).
Zero-copy redo is FALSE
or the other with true
Dynamic strands is set to TRUE
Running with 1 shared and 18 private strand(s).
Zero-copy redo is FALSE
or even without both
Dynamic strands is set to FALSE
Running with 1 shared and 10 private strand(s).
Zero-copy redo is FALSE
But you always have private strands.
Even with/without zero-copy.
I cuold not turned strands down except from 18 to 10
:)
Probably some crazy mix of parameters.
As you said redo latches are now aquired in immediate
mode, that means some round-robin algorithm to try to
aquire them, then you are using private/shared strand.
Then if zero-copy then it is going some new algorithm
way, while no zero-copy you need to get redo copy
latch to write it to the old fashion log buffer space
from where lgwr will do the standard thing.
I hope you will find out soon and publish it :)
Thanks,
Zoran
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
--
//www.freelists.org/webpage/oracle-l
Other related posts: