Re: latch-free SCN scheme (10.1.0.3)

Hi,

> My way of thinking is also that there is no need to
> copy anything to log buffer if the strands are created
> in the unique static way. LGWR should know about them
> and their location and who did commit. Maybe in some
> new x$ table.

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....

>
> But then what are shared strands? Who is sharing them
> in the single instance? Are they for distributed

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).

> Then maybe the new log buffer structure is just
> consists of private and share strands, no copy, then
> LGWR will know which strand(s) to write to the disk.

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...

> Gone too far ....

Where no DBA has gone before? ;)

Tanel.

--
http://www.freelists.org/webpage/oracle-l