Re: latch-free SCN scheme (10.1.0.3)
- From: Martic Zoran <zoran_martic@xxxxxxxxx>
- To: gogala@xxxxxxxxxxxxx, oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 15 Feb 2005 15:01:59 -0800 (PST)
Mladen,
I finally found the doc I was searching for (my
knowledge base is very messy):
http://integrid.info/memory_latching.pdf
This guy explains also latchless SCN in some details.
Great idea, like every transaction own 255 SCN
numbers, then no need to take the latch :)
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.
Very cool document.
Regards,
Zoran
--- Mladen Gogala <gogala@xxxxxxxxxxxxx> wrote:
> In my alert.log I have the following text:
>
> Mon Feb 14 20:29:29 2005
> Starting ORACLE instance (normal)
> LICENSE_MAX_SESSION =3D 0
> LICENSE_SESSIONS_WARNING =3D 0
> Picked latch-free SCN scheme 2
> KCCDEBUG_LEVEL =3D 0
> Using LOG_ARCHIVE_DEST_10 parameter default value as
> USE_DB_RECOVERY_FILE_D=
> EST
> Autotune of undo retention is turned on.
> Dynamic strands is set to TRUE
> Running with 1 shared and 10 private strand(s).
> Zero-copy redo is FALSE
>
>
>
> What is "latch-free SCN scheme"? As far as I am
> aware, any transaction that=
> needed
> to increase SCN, needed to acquire latch that was
> protecting SCN. Is it sti=
> ll the=20
> case? V$LATCHNAME, of course, tells a different
> story:
>
> 1 select name,latch# from v$latchname
> 2 where name like '%SCN%'
> 3* order by 1
> SQL> /
>
> NAME LATCH#
> ------------------------- ----------
> batching SCNs 110
> change tracking consisten 155
> t SCN
>
> change tracking optimizat 154
> ion SCN
>
> flashback SCN barrier 159
> flashback hint SCN barrie 161
> r
>
>
> NAME LATCH#
> ------------------------- ----------
> lgwr LWN SCN 106
> mostly latch-free SCN 105
> ping redo on-disk SCN 108
> redo on-disk SCN 107
>
> 9 rows selected.
>
>
> What's the deal? If SCN acquisition is really latch
> free, ie does not requi=
> re=20
> previous latch acquisition, that would be a great
> performance enhancement.=20
> If that is so, is that true for RAC as well? What
> about local and global SC=
> N?
> My world is falling apart! Moreover, what is
> "zero-copy redo"?
> Once upon a time, there was a parameter which was
> determining the maximum
> size of redo entry that was written directly to log
> buffer. Everything
> greater then that was first formatted in the process
> buffer, space was
> then allocated in the redo buffer (by acquiring redo
> allocation latch, of
> course), and when redo copy latch was acquired, the
> user buffer was copied
> into the log buffer. Am I correct in my
> understanding that all processes=20
> need to acquire only allocation latch and that they
> will write directly
> into the log buffer? No copy latch necessary?
> Jonathan, please help!
> --=20
> Mladen Gogala
> Oracle DBA
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
--
//www.freelists.org/webpage/oracle-l
Other related posts:
