I don’t know what is causing this when you try it. You are correct that dbms_xplan reports the actual number of consistent gets in the buffers column. The only explanation I have is that somehow your arraysize gets reset back to 15.

If you omit the call to dbms_stats there will be no statistics and Oracle10g/11g will use dynamic sampling during the parse call. However the effects of dynamic sampling are not reported by dbms_xplan.
-Harald

No it has nothing to do with an anonymous transaction, I just used a regular transaction and rolled it back. While inserting the rows, the high-water mark gets pushed up. Upon transaction rollback the rows are deleted but the HWM remains at its new position.
-Harald

Not sure why but here is what I noticed.
While running the example, I was frequently doing the following to reset the HWM (so that I can start from the scratch; number of buffers as 4)

ALTER TABLE foo MOVE;
EXEC dbms_stats.gather_table_stats(user, 'FOO');


What I could not understand is why is the stats collection needed after the ALTER TABLE..MOVE? Without stats collection, the number of buffers reported (by DBMS_XPLAN.DISPLAY_CURSOR) were 8 and never went back to 4. My understanding is the outcome of DBMS_XPLAN.DISPLAY_CURSOR reports facts and not the guesses (based on statistics). In that case, how did the stats collection affect the actual work done?

Yes. I am using ASSM tablespace. Now as for your quote
I didn’t insert and rolled back the new rows in another session though. I simply did it in the same session., then the obvious
way to do it from single session is doing the INSERTs (followed by ROLLBACK) from an autonomous transaction (in same session). Am I correct?

You are correct that the increased number of consistent gets is caused by a bumped high-water mark. I didn’t insert and rolled back the new rows in another session though. I simply did it in the same session. The exact number of rows that are needed to get the extra 20 consistent gets depends on the physical table structure: block size, pctfree and column data type (and a few other attributes). In my case I increased the number of rows from 64 to 10000.
-Harald

Thanx for catching the typo (5 instead of 4). I’ve updated the original post which now read correct.

The reason why you get 4 blocks instead of 1 could be caused by the tablespace space management type. My table resides in a freelist managed tablespace and yours is probably stored in an ASSM tablespace. I did this on purpose to get consistent behaviour. Things become somewhat complex when rows get stored in an.ASSM managed table and I didn’t want it to get in the way for this discussion. Is your table indeed in an ASSM tablespace?
Just as Mark you are close to what I did to the table, but I didn’t use a second session to make it happen.
-Harald

No, I did not insert a bunch of rows in another session and rolled them back, but you are getting real close now! ;-)
-Harald

Vincent

Nice post.
When I tried running your scripts, the DBA_TABLES always reported BLOCKS as 4 whereas COUNT(DISTINCT dbms_rowid.rowid_block_number(rowid)) reported 1. Not sure what is the reason for difference. However, the DBMS_XPLAN.DISPLAY_CURSOR reported buffers as 4, with arraysize 70.
Now, bit confused with your question, why there are 24 consistent gets instead of just 5. shouldn’t it be why there are 24 consistent gets instead of just 4 since you have set the arraysize to 70.
Now, I was able to get the figure of 24 when I added 2010 rows into foo table from another session but did not commit. After this when I executed the SELECT * from foo in the first session, the subsequent DBMS_XPLAN.DISPLAY_CURSOR reported 24 buffers, instead of 4. Could that be the case?
p.s. As you mentioned in a reply, I did not “touch” existing 64 rows at all. :)

Did you insert some more rows in a different session and it had to read the blocks to determine your session wasn’t supposed to see the contents?

I’m also not sure without testing what happens if you insert rows in your own session and then roll them back. Sigh. Isn’t it a real achievement that Oracle CONSISTENTLY gets the right answer?

Both are possible techniques to force the number of consistent gets to go up, but both are not what I did. I didn’t touch the existing 64 rows at all.
-Harald

Thanx for your feedback. I’ll try to answer your questions:

The 69th consistent get is to undo the changes made to the data block header. In this header data structures resides which are known as ITL’s and their function is to link the changed rows to the undo segment holding the previous values. All rows inside one data block that are changed by the same transaction share one ITL. Because all 64 rows are stored in one data block there is one ITL in use causing one extra consistent get. If the updated rows were stored in two data blocks there would be two ITL’s involved causing two extra consistent gets. Or if the 64 rows were updated by two transactions there would also be two ITL’s involved also resulting in two extra consistent gets.

The missing 4th consistent get in the aggregate trap is caused by the way SQL*Plus fetches data. Strangely enough SQL*Plus always seems to start with a fetch for one row followed by fetches of arraysize number of rows until there is nothing more to fetch. So in the case where SQL*Plus fetches 64 rows using an arraysize of 70 it results in two consistent gets. In the case where the sum function fetches the rows from the full table scan, SQL*Plus start by fetching one row from the sum function and it gets notified that there is nothing more to fetch resulting in one consistent get less.

A consistent get is basicly accessing a data block that is first made read consistent. Consistent gets have a n-to-n relationship with a fetch operation.
-Harald