Re: latch-free SCN scheme (10.1.0.3)
- From: Martic Zoran <zoran_martic@xxxxxxxxx>
- To: tanel.poder.003@xxxxxxx, oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 16 Feb 2005 00:26:57 -0800 (PST)
Hi Tanel,
Thanks a lot.
Sorry for not calling you with the real name.
I do not like when somebody else do this to me.
It is probably that I was happy that I find out your
nice document.
I believe you when you said no Oracle help.
At first I was thinking you people from Hotsos,
Miracles, ... have insiders in Oracle feeding you
useful info. Also having internal knowledge sharing
together and not allowing others to know, but this was
stupid thinking from my side.
But then thinking just about how big Oracle is, and
how small number of people there know Oracle
throughout. It will be almost impossible to know these
key people who knows these little things. A lots of
people there are just (un)lucky developers doing some
small piece of art.
I have tested solid state disks and had a crazy
problems with these latches, it will be interesting
test to do it again with these private strands when
opportunity arises, or at least in the situation when
these latches are the problems.
Regards,
Zoran
--- Tanel Põder <tanel.poder.003@xxxxxxx> wrote:
> 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
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
--
//www.freelists.org/webpage/oracle-l
Other related posts:
