There appears to be two enhancements.. In 9i, they introduced "log_parallelism" which is more than a single redo allocation latch. In 10g, this parameter becomes hidden because the amount of parallelism is auto-decided/tuned by Oracle. So there's 3 parameters: _log_parallelism _log_parallelism_dynamic _log_parallelism_max Also in 10g, there a new thing called private redo. All pretty much conjecture on my part here but it looks like some of the log buffer gets created in such a way that sessions can directly copy into it without requiring latches. At a guess, "10 private strands" means up to 10 sessions can get benefit from this mechanism at any given instance...from x$ksppi _log_private_mul - Private strand multiplier for log space preallocation _log_private_parallelism - Number of private log buffer strands for zero-copy redo _log_private_parallelism_mul - Active sessions multiplier to deduce number of private strands I'm sure Tanel or Steve may have greater insight. Cheers Connor --- 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 > ===== Connor McDonald Co-author: "Mastering Oracle PL/SQL - Practical Solutions" ISBN: 1590592174 web: http://www.oracledba.co.uk web: http://www.oaktable.net email: connor_mcdonald@xxxxxxxxx Coming Soon! "Oracle Insight - Tales of the OakTable" "GIVE a man a fish and he will eat for a day. But TEACH him how to fish, and...he will sit in a boat and drink beer all day" ------------------------------------------------------------ __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com -- //www.freelists.org/webpage/oracle-l