Resend: latch-free SCN scheme (10.1.0.3)
- From: Tanel Põder <tanel.poder.003@xxxxxxx>
- To: "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 16 Feb 2005 01:02:28 -0000
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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
- » Resend: latch-free SCN scheme (10.1.0.3)
