Re: Does a commit cause a checkpoint?

Peter,

It is highly possible that DBWR and LGWR can be writing at the same time. Think about what happens on a log switch. This forces a checkpoint and then forces DBWR to start writing dirty blocks to the datafiles. Does LGWR then have to sit there and wait for DBWR to finish before LGWR can start writing again? If that were true, then all transactions would immediately stop since they couldn't write transactional information to the online redo logs. This would hamper performance. DBWR and LGWR are two independent processes both capable of writing at the same time (unless they are competing for the same disk head, but that's a different story). This is one way that the database can perform at an optimal level.

HTH,
Brian

Peter wrote:
>
> On Wed, 18 Jun 2003 23:10:17 -0400, "Ryan" <rgaffuri_at_cox.net> wrote:
>
> >
> >"Peter" <peter_at_nomorenewsspammin.ca> wrote in message
> >news:4b62fv4tp8p9ftk5ste75837olk0g3kr7g_at_4ax.com...
> >> On Thu, 19 Jun 2003 00:41:45 GMT, Hans Forbrich
> >> <forbrich_at_telusplanet.net> wrote:
> >>
> >> A logswitch causes a checkpoint which causes LGWR to flush the redo
> >> log buffer, but no change in SCN
> >>
> >> A checkpoint causes the DBWn to write to file, and also causes the
> >> LGWR to flush the redo buffer, but no change in SCN
> >>
> >> >
> >> >
> >> >Peter wrote:
> >> >
> >> >> Does a commit cause a checkpoint?
> >> >>
> >> >> A checkpoint causes the SCN to increment. A logswitch causes a
> >> >> checkpoint and threrefore a SCN incremental change.
> >> >> What I am confused about is whether a commit causes a checkpoint and
> >> >> therefoe a SCN increment.
> >> >>
> >> >
> >> >From the "Oracle9i Database Administrator's Guide, Release 2 (9.2), Part
> >> >Number A96521-01" at
> >>
> >>http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/onliner
> >edo.htm#ADMIN007
> >> >in Chapter 7, "Managing the Online Redo Log", in section titled "Online
> >> >Redo Log Contents",
> >> >
> >> >the second paragraph reads:
> >> >
> >> >>>>>>>>
> >> >Redo records are buffered in a circular fashion in the redo log buffer
> >> >of the SGA (see "How Oracle Writes to the Online Redo Log") and are
> >> >written to one of the online redo log files by the Oracle background
> >> >process Log Writer (LGWR). Whenever a transaction is committed, LGWR
> >> >writes the transaction's redo records from the redo log buffer of the
> >> >SGA to an online redo log file, and a system change number (SCN) is
> >> >assigned to identify the redo records for each committed transaction.
> >> >Only when all redo records associated with a given transaction are
> >> >safely on disk in the online logs is the user process notified that the
> >> >transaction has been committed.
> >> ><<<<<<<
> >> >
> >> >Please note the sentance starting with "Whenever a transaction is
> >> >committed,"
> >> >
> >> >(I'm still wondering what is your documentation source - whatever it is
> >> >seems to be leaving huge gaps in your understanding)
> >> >
> >> >/Hans
> >> >
> >> >>
> >> >> Thanks
> >>
> >
> >what happens if there is a checkpoint. DBWR and LGWR start writing to disk
> >at the same time. Or is commit is issud.
> >
> >while both DBWR and LGWR are writing the same SCN to disk we have an
> >instance failure.
> >
>
> How could this happen inthe first place? The Oracle architectural
> design will always force the LGWR to write the redo generated by the
> transactions to the log files first. Then DBWn will be allowed to
> flush the related dirty buffer to files. You really cannot have both
> LGWR and the DBWn writing at the same time. Please refer the online
> manual.
>
> >now since all of LGWR is not safely in the redo log, the data is not
> >considered committed.
>
> How could this happen? LGWR writes committed and uncommitted redo
> reecords to the file. Please refer the online manual.
>
> Thanks
>
> >HOWEVER,. DBWR has already started writing to the
> >datafile thereby CHANGING what is in the datafile.
> >
> >how does oracle recover this? Does it use rollback? it cant roll forward
> >since all the data is not in the redo logs.
> >

-- 
===================================================================

Brian Peasland
oracle_dba_at_remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"