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 13:44:35 -0800 (PST)
Mladen,
I think that this mean only there is no need for the
special latch used earlier in <= 9i.
I suppose that is the new Oracle feature :)
Lets change something.
Even in the 10g RAC alert log you have:
Picked latch free SCN scheme 3
......
Picked Lamport scheme to generate SCNs
or
Picked broadcast on commit scheme to generate SCNs
They are all latch free.
It could be just generic text :)
These are all SCN schemes I know, Lampart and
broadcasting. Not sure that you want to play with
_scn_scheme parameter :)
There are situations where you cannot read the
commited data from the second instance in RAC, because
the SCN is not still propagated to the node. Your
transactions are very fast and Lampart algorithm is
not :). I had that situation. Check the note 260304.1.
Imagine duplication of SCNs across RAC :)
But again it was happening in 9i and not sure why then
was not latch free :)
In 10g who knows what they did and why is called latch
free.
Of course, my comments can be stupid.
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!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
