full scan的时候，其实也是会被放到data buffer cache的RLU 一端的。_small_table_threshold参数决定了当表的超过多少Block时,表就不是小表了。这个参数默认是db_block_buffers * 2%. 就是说，它的大小间接的是由db_block_buffer控制的。 9i 里面，就是db_cache_size或者db_block_size间接决定了。

table scans (long tables) 0 0.0 0.0
table scans (short tables) 405,966 9.4 0.3

Tables which are full table scanned and are larger than _small_table_threshold have their blocks added to the LRU end of the LRU list. This is to prevent thrashing the buffer cache in the event that a "large" table is scanned. The _small_table_threshold defaults to 2% of the buffers in the cache. If the table is larger than that, it's not a small table, and the blocks go on the LRU end of the list, where they age out quickly. So, repeated full table scans will cause repeated physical reads.
If the FTS is unavoidable, or desirable, there is another option available to you. In earlier versions, you may have been advised to adjust _small_table_threshold or to set the "CACHE" attribute on the table involved. However, since 8i, Oracle introduced multiple buffer pools. So, you can create a KEEP and/or RECYCLE pool, in addition to the DEFAULT pool. So, depending on the size of the table it will likely belong in either KEEP or RECYCLE. If it's small enough to be cached in it's entirety, KEEP is the way to go. It's up to you to decide how much memory is available, and how large the table is.) If it's quite large, and you're not able to cache it all, then, you may wish to assign it to RECYCLE, where, when blocks age out, at least they won't thrash the rest of the cache. Note that adding very large tables to the RECYCLE pool will not avoid physical I/O. It will only help mitigate the effect of that I/O on other cached objects. Effect _small_table_threshold on optimizer In Oracle 8, _small_table_threshold is set to 2% of db_block_buffer. If db_block_buffer is set big, _small_table_threshold will be big. If I change _small_table_threshold to a smaller value, will it have any impact on the optimizer?