CBO and caching effect

Question

select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
show parameter opt
NAME                                 TYPE        VALUE
_optim_peek_user_binds               boolean     TRUE
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      11.2.0.2
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     FALSE
optimizer_use_invisible_indexes      boolean     FALSE
optimizer_use_pending_statistics     boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     FALSEI am asking a broad question here.But any help/insight will be greatly appreciated.
I want to understand how (and what) Dynamic buffer cache statistics are exposed to CBO to let her form optimal execution plan ? I am under impression that CBO never looks at buffer cache statistics while making execution plan as buffer cache statistics are highly dynamic and it would be a intrusive to consider buffer cache statistics to ensure plan stability. (with 11g's "feedback loop" mechanism between optimizer and execution engine, Apparently, my understanding is wrong).
I am running Workload statistics and since my underlying storage is SAN, i am explicitly setting SREAD=4 and MREAD=10 for hybrid database. DB has 65% OLTP access (between 8:00 AM to 10:00 PM) with 35% batch processing 24x7 .

Answer 1

958830 wrote:
Can you share your experience on "advantage of having Workload system statistics over NOWORKLOAD statistics" ? (SREAD < MREAD)I have written several notes on my blog about system stats ( http://jonathanlewis.wordpress.com/category/oracle/statistics/system-stats/ ). In general my preference is to leave as many parameters and related values as possible to default. I apply this guideline to system stats even though, in absolute terms, the values for sreadtim and mreadtim are about 30 years out of date when derived from the ioseektim and the other one (transfer rate, but I can't remember the proper name). For further comments about when I would ignore this to give Oracle a better model of the truth I'll leave you to read the notes.)
(Considering Oracle recommendsation on 10g/11g, i have not set DBMBRC parameter with NOWORKLOAD system stats,).As above - I approve of not setting db_file_multiblock_read_count in any circumstances (in the latest versions).
>
Let me also take an opportunity to ask you if you can highlight some light on positive results of exposing Cache statistics to CBO ?I wouldn't do it (I think I made a comment in the book about how scary it might be). In some ways it sounds like a very good idea - if the optimizer estimates that it need to visit 5,000 random table blocks (based on calculations related to the clustering_factor), but also has information that the "object-level cache hit ratio" for that table sa 98% over the last hour then it seems reasonable to cost that at 0.02 * 5000 = 100, rather than the 5,000 that would currently appear.
The problem (as I probably mentioned in the book) is that the code you activate tries to keep a smoothed rolling average over time for object-level cache hit ratios - which means that the DBA ends up with the problem of saying: "why did this query use plan A at 9:45, and plan B at 14:30?" - with the only answer being "it depends what was going on in the preceding 4 or 5 hours.
Regards
Jonathan Lewis