Re: Row Migration

When you do your testing, don't forget to keep an eye on the change in dependent logical I/O and latching.

Fetching a migrated row will require an extra buffer visit to find the row data. This MAY turn into an extra disk read but at the least it IS another buffer visit, which means another hit on the cache-buffers-chains latch, and may mean further work done getting another buffered block to the correct read-consistent state.

I think you'll have to model your test very carefully - it wouldn't be too hard to produce two different models with totally contradictory results - one based on the migration going to a relatively nearby block, the other based on the update and migration taking place in a way that ensures maximum scatter of the migrated row piece.

The former may hide I/O problems, the latter may exaggerate the I/O problems and hide the latch issues; and in either case you may fail to emulate the read-consistency issue properly.

Regards

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

Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )

Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )

____England______January 21/23

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

-----Original Message-----
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> Date: 27 December 2002 12:25

>Well, yes, I would agree with that ;-)
>
>What we are trying to determine here in this particular case is how
much or
>what percentage of the slowdown in the process is due to the
migration of
>rows. We aren't ready (until we do some testing) to make a blanket
statement
>that row migration *alone* is the cause of the significant slowdown.
In
>other words, I'm not willing to make a statement to the powers that
be that
>simply increasing the pctfree is going to make things normal again
until we
>have a chance to do some more detailed monitoring and testing.
>
>Regards,
>
>Larry G. Elkins

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jonathan Lewis
  INET: jonathan_at_jlcomp.demon.co.uk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).