Beim Nachvollziehen eines Beispiels auf
Jonathan Lewis' Blog habe ich einmal mehr über die Rolle von
system statistics und
io costing nachdenken müssen. Erinnerungswürdig scheinen mir diesmal folgende Punkte:
- um io costing zu aktivieren, kann man auf Statementebene den folgenden Hint verwenden: /*+ opt_param('_optimizer_cost_model','io') */. Erwähnt wird der Hint in einem deutlich älteren Blog-Eintrag beim Herrn Lewis - möglicherweise ist der Hint inzwischen nicht mehr das Mittel der Wahl, aber er funktioniert.
- Workload-Statistiken kann man über folgendes Kommando löschen: exec dbms_stats.delete_system_stats(). Nach der Löschung der Statistiken erfolgt das costing weiterhin als cpu costing, aber mit NOWORKLOAD-Statistiken. Weitere Details zum Thema findet man in Randolf Geists Blog.
- Wenn der MBRC nicht explizit gesetzt wird, sucht sich Oracle dafür offenbar einen zum OS passenden Wert (auf meinem Windows7-Rechner 128). Für costing und data access werden aber die hidden paramters _db_file_exec_read_count und _db_file_optimizer_read_count verwendet, die durchaus voneinander abweichen können. Die Werte dieser Parameter liefert folgende Query (vgl. dazu auch Kerry Osbornes Blog):
-- auszuführen als sys bzw. jemand, der die x$-Tabellen sieht:
select i.ksppinm name
, sv.ksppstvl value
from x$ksppi i
, x$ksppsv sv
where i.indx = sv.indx and upper(i.ksppinm) like upper('%read_count%')
NAME VALUE
---------------------------------------- ------
db_file_multiblock_read_count 128
_db_file_exec_read_count 128
_db_file_optimizer_read_count 8
_db_file_noncontig_mblock_read_count 11
_sort_multiblock_read_count 2
Keine Kommentare:
Kommentar veröffentlichen