Re: Data Buffer Cache

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:3d84e994_at_dnews.tpgi.com.au...
>
> "Michael J. Moore" <hicamel_x_the_spam_at_attbi.com> wrote in message
> news:P43h9.435668$me6.49737_at_sccrnsc01...
> > Howard,
> > Since you teach this stuff, you might be interested in my students come
to
> > you with
> > crazy ideas like mine. I know that you have flat out stated that this
> > information
> > is WRONG, but for the record, I'd like to give you the entire quote.
> >
> > On page 129 of OCP Oracle 9i Database: Fundimentals 1 Exam Guide it
says:
> >
> > "The events that occur at log switch are as follows. First, LGWR stops
> > writing
> > the redo log it filled. Second CKPT signals the DBWn to fluch the dirty
> > buffers into
> > the data files and finally CKPT updates the control files and the data
> file
> > headers
> > with the checkpoint information. With the checkpointing tasks complete,
> the
> > LGWR will be allowed to start writing into the next redo log group with
a
> > new
> > sequence number."the checkpointing tasks complete
>
>
> Fair enough: I didn't doubt the accuracy of your quotation. It's the
> accuracy of the information that was being quoted that's stuffed. If this
> was really the way that things happened, the database would grind to a
halt
> at every log switch, waiting for DBWR to do its thing, and Oracle would
have
> about 0.2% marketshare as a result.
>
> >

--- snip ---
Howard, this might not actually contradict anything you have said, but it would see that
there are at least a few components of the Oracle instance that WAIT during a log switch.
regards,
Mike

According to
http://www.ixora.com.au/notes/log_switch_steps.htm Redo generation is entirely disabled during a log switch. This is done by setting an SGA variable reflecting the cause and status of the log switch. Sessions about to allocate space in the log buffer check this variable first and if a log switch is in progress they wait on the appropriate one of several wait events associated with log switching. No log buffer space allocation is attempted until after the log switch has completed, therefore the log buffer space wait event will not be seen during a log switch. However, if a large number of processes have been waiting for a log switch to complete then there can be a burst of redo generation thereafter that does result in secondary log buffer space waits. LGWR performs the following four steps to effect a log switch.

1. It performs a controlfile transaction to select the next log file to be used and to clear its controlfile entry. Normally, the log file currently bearing the lowest log sequence number is chosen. If necessary, the log switch will be delayed at this point until DBWn has completed the log switch checkpoint following the previous use of this log file, and until ARCn has archived its contents. If so, sessions waiting for the log switch will sleep on the log file switch (checkpoint incomplete) or log file switch (archiving needed) wait events, instead of the log file switch completion event
2. It flushes any remaining redo in the log buffer to disk, and then writes the SCN of the last redo record in the log file (the high SCN) into the log file header block. Once these writes have completed, LGWR closes the log file.
3. It then advances the SCN and performs a second controlfile transaction to mark the next log file as CURRENT, and to mark the old log file as ACTIVE. The status of that log file will be changed to INACTIVE once DBWn has completed the log switch checkpoint. If the database is in ARCHIVELOG mode, then LGWR also adds the previous log file to the archive linked list through the log file entries section of the controlfile (see V$ARCHIVE) and if automatic archiving is enabled, it posts the ARCn background process to archive it. From Oracle 8.1, LGWR can spawn a new ARCn process up to the value of log_archive_max_processes, if all the existing archive processes are still busy.
4. Finally, LGWR opens all members of the new log file group and writes the new log sequence number and low SCN into the header block. It then enables redo generation again.

The writes to the log file header blocks during log file open and close operations are log file single write operations. Header block writes have to be single writes (rather than parallel writes to all the members of the group) because part of the header information is the file number, and that is different for each member. Received on Mon Sep 16 2002 - 16:49:26 CDT