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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
