|
Did you change table TBF_USER between the two tests? I don't understand why the second row count is 25M on line 2 (TABLE ACCESS FULL)? It should still be 43M.
A simpler case to test our theory is:
create table testlong (x int, y long);
--my db_block_size is 4, so 5000 bytes is enough to cause a row to chain
insert into testlong values (1, rpad('x', 5000));
insert into testlong values (2, rpad('x', 5000));
insert into testlong values (3, rpad('x', 5000));
commit;
--confirm chained_rows
analyze table testlong list chained rows;
select * from chained_rows;
--In my 10gR2, 'table fetch continued row' statistic# is 252
--Get base value
select value from v$mystat where statistic# = 252;
select * from testlong where rownum < 2;
--Should increase by 1
select value from v$mystat where statistic# = 252;
--Run the two above queries a few times
--Add rownum stop key
select count(*) from select * from testlong where rownum < 2);
--stat value should not increase because of this rownum optimization; you can change 2 to 3 and it won't change either
select value from v$mystat where statistic# = 252;
If you check v$mystat, there's no need to join with v$sesstat.
Yong Huang
[ 本帖最后由 Yong Huang 于 2010-3-17 15:45 编辑 ] |
|