Resend: latch-free SCN scheme (10.1.0.3)

Hi,

>
> http://integrid.info/memory_latching.pdf
>
> This guy explains also latchless SCN in some details.

As "this guy" doesn't have access to Oracle source code and the doc is about pretty new features, then be cautious when interpreting private redo and in-memory undo parts of it, these are still pretty gray area for me as well (although I'm working on it and the doc will soon be updated with newer research results)

> Great idea, like every transaction own 255 SCN
> numbers, then no need to take the latch :)

What I meant there, was that every change under the same SCN into the same datablock will increase this block's SEQ# value (1 byte), for recovery purposes. But if you manage to do > 255 changes to this block within the same SCN then SCN has to be artificially incremented (as opposite to the usual incremente during commit ) and SEQ# will wrap around and start from zero (or was it one?) again.

>
> The similar mechanism is for zero copy latch where
> sessions have preallocated log buffer space. That
> means no need for redo copy latch at all.

In my understanding, when using private redo strands (_log_private_parallelism=true), the redo records can then be latchlessly created into private strands (which reside in shared pool), as long as the strand is allocated to a specific session. Now when we commit or our private strand gets full, we copy the contents of private strand to log buffer for lgwr to flush it to disk. (latching during this particulary copy is another story).

Now, if you're using private redolog strands, Oracle might use zero-copy mechanism for getting the contents from private strand to log buffer - using modern OS tricks such page loaning which manipulate with virtual memory mapping information - for example making the page read only and allowing it to be mapped somewhere into redolog buffer memory area, or completely switching virtual addresses of 2 physical memory ranges (pages) etc. This should reduce memory bus bandwidth usage and increase overall speed of these kind of memory "copy" operations if implemented properly.

About latchless SCN updates, there are couple of parameters which somewhat control whether latches are got for SCN updates, but this one is also more complex than I initially hoped - for example there was a "mostly latch-free SCN" latch on my 10.1.0.2 Linux box, which was still gotten despite any configuration. "redo on-disk latch SCN" latch usage however is way lower when 64-bit latchless SCN CAS updates are allowed (_disable_latch_free_SCN_writes_via_64cas=false)

So, much more work needs to be done, to get this doc closer to the truth... the next version of this doc can be seen at Hotsos Symposium among the test results this March ;)

>
>
> Very cool document.

Thanks,
Tanel.

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