I've been trying to avoid the whole buffer cache
argument, but had to comment below.
--
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
"Noons" <wizofoz2k_at_yahoo.com.au.nospam> wrote in message
news:3ff18924$1$18748$afc38c87_at_news.optusnet.com.au...
> Yet, Oracle insists on getting everyone to use its own.
Only with regard to cache that is in the same box
as the SGA - not for cache lurking at the end of
bits of wet string.
> That's where the logical versus physical I/O speed and timing
> conundrum comes in: exactly what constitutes a logical or a
> physical I/O nowadays? Does it even make sense to STILL use
> those terms?
>
> I don't think so. To me, there are two types of I/O in a system:
> cached and un-cached. Who caches it is for performance evaluation
> purposes essentially irrelevant. All else I'm afraid is just nuances,
> "versionitis" and "feature-itis".
I disagree - if Oracle needs to read a block in the
file-system cache then the session has to set up
a callback, block a buffer header, go into its waitstate,
and go off the run queue; on being awoken, it has to
clear the wait state and change the state of the
buffer header before continuing. In the meantime
other processes could have been queueing on
the exclusive lock on the buffer header - also
going into waitstates and setting callbacks
If the block had been in the Oracle cache, all
the processes could have acquired shared pins
on it without waiting - reducing task switches,
extra CPU costs and so on.
Received on Tue Dec 30 2003 - 10:51:51 CST
