Hi List, once again I'm coming up with a behaviour of Oracle rdbms which I can not explain to myselve. So I'm asking here for help. If you are not interrested in theoretical discussions about how oracle heuristics might work, please excuse this email and stop here. All others are warmly welcome to read and reply ;-) My monitoring: ============= the same statement (select rowid from test.t_keep) is executed different only because memory_target, sga_target and shared_pool_size are different. (In addition, db_cache_size and db_keep_cache_size might be of any interrest). With automatic memory management the DB uses 'db file sequential read' and fills up the (keep) buffer cache, with manual memory parameters it uses 'direct path read' (only 4 'db file sequential read' at the beginning). Some facts around: ================= * I bonced the instance between all the test-cases. Version 11.1.0.7 on a virtual test-machine (RedHat - 32 bit) table definition and rows: ------------------------- CREATE TABLE test.t_keep ( id NUMBER, n1 NUMBER, n2 NUMBER, pad VARCHAR2(4000) ) STORAGE (BUFFER_POOL KEEP); execute dbms_random.seed(0) INSERT INTO test.t_keep SELECT rownum AS id, 1+mod(rownum,251) AS n1, 1+mod(rownum,251) AS n2, dbms_random.string('p',255) AS pad FROM dual CONNECT BY level <= 100000 ORDER BY dbms_random.value; commit; * all statements run as sys (I'm lazy, alone on the node, etc). the statements I run: -------------------- -- to check the blocks of the table select blocks from dba_tables where table_name='T_KEEP'; BLOCKS ---------- 496 -- get obj_id: select object_id, data_object_id from dba_objects where object_name ='T_KEEP'; OBJECT_ID DATA_OBJECT_ID ---------- -------------- 64143 64143 what I run at every testcase: ============================ -- to make sure nothing is cached yet: select obj, count(*) from x$bh where obj in (64142, 64143) group by obj; -- test itselve select rowid from test.t_keep; -- check cache afterwards: select obj, count(*) from x$bh where obj in (64142, 64143) group by obj; With the 'manual' setup I get: OBJ COUNT(*) ---------- ---------- 64143 4 With the 'auto' setup I get: OBJ COUNT(*) ---------- ---------- 64143 452 Additional Infos/thoughts: ========================= I checked traces: In 10046 I see the difference of WAITS, but no reason why. In 10053 I see some smaller changes in derived parameters (as they are not implicite set in spfile), But I checked them and nothing changed: * difference in _smm_min_size and _smm_max_size and set it (in manual mode): select a.ksppinm name, b.ksppstvl value from sys.x$ksppi a,sys.x$ksppcv b where a.indx = b.indx and a.ksppinm in ('_smm_max_size','_smm_min_size'); NAME VALUE -------------- ------- _smm_min_size 184 _smm_max_size 36864 => but with the same result. * db_file_multiblock_read_count = 128 (17 in manual mode) => same result. I have put some files on a web-server not to bloat this mail too much: ===================================================================== 'manual': (memory_target, sga_target and shared_pool_size set) strings spfile => http://berx.at/traces/manual event 10046 => http://berx.at/traces/BERX2_ora_5081.trc event 10053 => http://berx.at/traces/BERX2_ora_6938.trc 'auto': strings spfile => http://berx.at/traces/auto event 10046 => http://berx.at/traces/BERX2_ora_6262.trc event 10053 => http://berx.at/traces/BERX2_ora_6632.trc Can anybody hint me why the acces changes from 'db file sequential read' to 'direct path read' when I change memory/SGA (and buffer) settings? thanks in advance Martin -- //www.freelists.org/archive/oracle-l/