Re: Background Processes and I/O

If pmon is recovering a process, it has to do a rollback on behalf of that process. Consequently it has to read the rollback blocks in reverse order, and the datablocks as required.

For a long-running transaction, many undo blocks and some data blocks are likely to be on disc, so pmon will have to re-read them in the normal fashion.

During testing, I've never seen the database crash on a normal sql_trace=true in the init.ora, and the resulting traces from pmon et. al. have been quite interesting.

-- 
Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

  The educated person is not the person
  who can answer the questions, but the
  person who can question the answers -- T. Schick Jr


One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html


Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___November


The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html


"Paul Drake" <drak0nian_at_yahoo.com> wrote in message
news:1ac7c7b3.0312210901.700b593f_at_posting.google.com...
> "Michael J. Moore" <NOhicamelSPAM_at_comcast.net> wrote in message
news:<ez9Fb.446468$275.1320599_at_attbi_s53>...


> > --- snip---

> >

> >

> > > >

> > > > SMON performs instance recovery, so it must read from redo logs. The

> >  manuals

> > > > I have read are not clear on how SMON does this, but if it does

read,


> >  then

> > > > that counts as I/O, right? SMON also cleans up temporary segments

anc


> > > > coalesces free extents. Can it do this without performing I/O?

> > >

> > > SMON might to I/O at instance startup; also to the rollback segments

for


> > > uncommitted "transactions" (which I'll stipulate is an oxymoron).

> > >

> > > I agree that the OCP test questions leave a lot to be desired.

> > >

> >

> > Well you did straighten me out about CKPT ... thanks. It is interesting

that


> > even in the Oracle manuals, their diagrams never show SMON pointing to

any


> > of the files, only pointing to the SGA. This leaves me wondering if SMON

> > actually performs it's own I/O or invokes some other process to do it's

> > dirty work. I wish they would give a little more detail.

>
> normally, for a user process, a logon trigger could be used to trace
> it (event 10046). I've seen text indicating that an instance crash is
> likely if you trace PMON, but I don't know if that is true for SMON.
> So lets just leave that at the usual "don't run it against a database
> that you can't destroy/corrupt". Then again, the trace file might be
> so cryptic that only an x$_% wizard (fluent in elvish) could read it.
>
> I believe that LGWR can also write to the controlfiles. I've seen a
> trace file where a controlfile was locked by a backup process
> (infidels!) and LGWR crashed before CKPT did. Hmmm, does PMON perform
> any IO when it takes down the instance?
>
> Pd