Many thanks.. Pak Tomi.:) Berdasarkan Statspack level 5 the most wait time karena : 1. db file scattered read = 73.09% 2. db file sequential read = 17.27% 3.
Setelah breakdown db_file_scaterred_read ternyata karena top SQL statements : SELECT HubMessage.* FROM HubMessage WHERE ((((HubMessage.SubscriberID IS NOT NULL AND HubMessage.GivenUp = :P1) AND HubMessage.Invalid = :P2) AND HubMessage.Delivered = :P3) AND HubMessage.Cancelled = :P4) Execute 262 kali. Tabel tersebut ada kolom yg NCLOB type nya. apakah saya harus ganti db_file_multiblock_read_count parameter ? Saat ini db_file_multiblock_read_count= 16 DB_BLOCK_Size = 8kb Many thanks Amang N --- In [email protected], Tomi Wijanto <[EMAIL PROTECTED]> wrote: > > Saya format ulang hasil tkprofnya: > > call count cpu elapsed disk query current rows > Parse 1 0.00 0.00 0 0 0 0 > Execute 1 0.00 0.00 0 0 0 0 > Fetch 1 0.60 13.82 8770 8831 0 1 > ------- ---- ---- ------ ----- ------ ------- ---- > total 3 0.60 13.82 8770 8831 0 1 > > Perhatikan bahwa CPU hanya 0.6 detik, sedangkan > elapsed timenya 13.82 detik. Berarti ada sekitar 13.22 > detik waktu tunggu (elapsed time = cpu time + wait > time). > > Dari sini kita mesti mencoba mencari tahu sebenarnya > bottleneck-nya dimana (nunggu apa sih...). > > SQL Trace biasa tidak melaporkan wait event. > > Jadi Anda mesti mengaktifkan tracing dengan cara > berikut (sebelum execute query, dari session yg sama): > alter session set events '10046 trace name context > forever, level 8'; > maka Anda akan mendapatkan informasi tambahan berupa > 'wait event'. > > Walaupun begitu, dari trace Anda terlihat bahwa utk > memproses 8831 blocks, Oracle harus mengambil 8770 > blocks dari disk. Kita bisa suspect bahwa waktu tunggu > berasal dari proses I/O ini. > > Library Miss tidak relevan utk kasus ini. Pertama > karena waktu utk parsing sangat tdk signifikan > dibanding waktu fetching. Kedua karena data yg Anda > berikan cuma melibatkan satu kali eksekusi query. > > Tuning yg berhub dgn I/O bisa dilakukan dgn bbrp cara: > - perbaiki sql utk memproses block sesedikit mungkin > - usahakan agar block yg diperlukan sdh ada di memori > - percepat I/O kalau bottleneck utama di disk > > regards, > tomi > > --- praneko <[EMAIL PROTECTED]> wrote: > > > > > Mungkin memang benar Mas, > > Throughput ke external disk -nya sekitar rata-rata > > 12MBps . > > > > Tapi bagaimana ya kita ambil data kalau memang > > bottleneck ada di > > external disk saja ? > > > > Kalau saya pakai SQL trace dan Tkprof sich ada > > beberapa query yg > > miss library, contoh : > > > > call count cpu elapsed disk query current > > rows > > Parse 1 0.00 0.00 0 0 0 > > 0 > > Execute 1 0.00 0.00 0 > > 0 > > 0 0 > > Fetch 1 0.60 13.82 8770 > > 8831 > > 0 1 > > ------- ------ -------- ---------- ---------- > > ---------- ---------- > > ---------- > > total 3 0.60 13.82 8770 > > 8831 > > 0 1 > > > > Misses in library cache during parse: 1 > > Optimizer goal: CHOOSE > > Parsing user id: 35 > > > > --- In [email protected], Tomi Wijanto > > <restomi_w@> > > wrote: > > > > > > Kemungkinan besar bottleneck terletak pada > > disk-nya. > > > Anda cuma memakai 1 disk eksternal yg sama utk > > kedua > > > database, sudah pasti i/o-nya akan terbatas > > sekali. > > > Apalagi kalau dipakai banyak user. > > > > > > Utk tipe OLAP, query biasanya membaca data dlm > > jumlah > > > besar. Kalau Anda memiliki bbrp disk dengan > > controller > > > terpisah, dan datafile dialokasikan ke disk2 yg > > beda, > > > maka pada waktu query Oracle bisa membaca data dr > > bbrp > > > disk sekaligus. > > > > > > Data dan index dlm satu tablespace bukan sumber > > > masalah. Throughput I/O yg penting utk ditambah. > > > > > > regards, > > > tomi > > > > > > --- praneko <amang_n@> wrote: > > > > > > > Dear DBA-er, > > > > > > > > Saya ada 2 machine Power5-550 untuk 2 database > > > > Oracle9i (9.2.0.1) > > > > dengan 1 external storage (IBM Storage DS4300). > > > > Nah, 2 database tersebut database file nya (data > > > > files, undo, log, > > > > control file, etc) semua sama-sama di stored di > > > > external hdisk tsb > > > > (hdisk2 - cuma beda volume group). > > > > Satu hal lagi, data dan index dalam satu > > tablespace > > > > (tablespace USERS). > > > > Applikasi yg running adlah jenis OLAP- untuk > > > > reporting. > > > > > > > > Permasalahannya : > > > > 1. wait IO di hdisk2 always/selalu 90 - 100% > > > > waiting. > > > > 2. applikasi report-nya luambat banget 1 klik > > butuh > > > > > 80seconds. > > > > 3. Sudah di lakukan analyze (reorganising) all > > > > tables tapi tetap saja > > > > lambat. > > > > > > > > Minta tolong dunk pencerahannya.:) > > > > > > > > Terima kasih banyak sebelumnya, > > > > Amang N > > > __________________________________________________ > 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.blogspot.com Mirror: http://indooracle.wordpress.com ----------------------------------------------- Bergabung dengan Indonesia Thin Client User Groups, Terminal Server, Citrix, New Moon Caneveral, di: http://indo-thin.blogspot.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/
