utk monitoring skema, tdk perlu di set ke FALSE.
Karena kalau begitu, otomatis semua tabel berada dalam
kondisi NOMONITORING, yg artinya justru tdk ada
perubahan yg akan di-track utk perhitungan statistik
berikutnya.
Misalkan kamu baru create tabel xxx, terus
alter table xxx monitoring;
terus di query
select * from user_tab_modifications where
table_name = 'XXX';
INSERTS UPDATES DELETES
-----------------------------
0 0 0
coba insert 5 kali ke table xxx, lalu query lagi
select * from user_tab_modifications where
table_name = 'XXX';
INSERTS UPDATES DELETES
-----------------------------
5 0 0
Lihat bahwa oracle akan meng-track perubahan tersebut.
kalau kita disable monitoring, otomatis semua info
tersebut hilang:
alter table xxx nomonitoring;
select * from user_tab_modifications where
table_name = 'XXX';
no rows selected
Jadi supaya efektif, bagian yg men-disable monitoring
tdk perlu dipanggil. Jadi prosedurnya gitu aja:
dbms_stats.ALTER_SCHEMA_TAB_MONITORING(<schema_name>,TRUE);
dbms_stats.gather_schema_stats(............);
--
Statistik memang sangat diperlukan utk CBO. Semakin
akurat semakin bagus.
Idealnya, statistik cuma perlu dihitung ulang kalau
kondisi tabel berubah drastis (dalam hal ini Oracle
memodelkannya dengan melihat kalau 10% data telah
berubah, ini hanya model tidak berarti benar).
Terlalu sering menghitung statistik sudah pasti makan
resource. Apakah hal tersebut bisa ditolerir oleh
sistem Anda? Kalau bisa, go ahead..
Perhatikan utk tabel2 yg dihitung statistiknya,
otomatis semua sql di shared_pool yg mengakses tabel
tsb akan di-invalidate. Jadi akan ada proses PARSING
ulang.
Satu hal lagi yg menjadi dilema: walaupun statistik
sudah sangat akurat, belum tentu CBO menghasilkan exec
plan yg terbaik. Jadi apakah perlu hitung statistik
tiap hari?
Anda akan bisa menemukan orang2 yg selalu menghitung
statistik setiap hari/minggu/bulan, atau bahkan
jarang2 melakukannya, tetapi tetap bisa me-maintain
database dalam performance yg terjaga.
Sorry kalau terlihat kontradiksi, tapi topik ini
mungkin adalah hal yg paling banyak diperdebatkan di
wilayah performance tuning.
Ada yg berpendapat kalau menghitung ULANG statistik
memakan banyak resource, kemudian tidak ada perbedaan
sebelum dan sesudah perhitungan, berarti tidak ada
gunanya dilakukan toh?
regards,
tomi
--- Ujang Jaenudin <[EMAIL PROTECTED]>
wrote:
> pak tomi,
>
> dengan kata lain proc tsb saya ganti jadi begini :
>
>
dbms_stats.ALTER_SCHEMA_TAB_MONITORING(<schema_name>,TRUE);
> dbms_stats.gather_schema_stats(............);
>
dbms_stats.ALTER_SCHEMA_TAB_MONITORING(<schema_name>,FALSE);
>
> kalo saya scheduling tiap malam, apa keuntungan dan
> kerugiannya ya....
> tadinya sih maksudnya biar si CBO bisa menghasilkan
> execution plan yang
> tepat...
>
> pls advice....
>
>
> regards
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
-----------I.N.D.O - O.R.A.C.L.E---------------
Keluar: [EMAIL PROTECTED]
Website: http://indo-oracle.lizt.org (NEW)
-----------------------------------------------
Bergabung dengan Indonesia Thin Client User Groups,
Terminal Server, Citrix, New Moon Caneveral, di:
http://indo-thin.vze.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/indo-oracle/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
