Apakah sudah dibandingkan persentase antara wait event
ini dengan total pemakaian CPU?
Kalau di statspack versi 9i, pada bagian TOP 5 WAIT
EVENT ada informasi 'CPU time'.
Kalau di statspack versi 8i, info 'CPU Time' bisa
diambil di bagian 'Instance Activity Stats' pada
statistik bernama 'CPU used when call started'.
Walaupun Anda mengatakan wait event ini signifikan
(70%), tapi saya tetap tidak bisa menyimpulkan apakah
hal tsb problem/bukan.
Coba berikan angka yg lebih exact dari pemakaian CPU
dan wait event. Angka berupa 'berapa kali wait
terjadi', 'total waktu wait', 'total waktu cpu' akan
sangat membantu.
(Saya pernah melihat database yg tdk ada wait event yg
signifikan, 95% adalah cpu time. Jadi walaupun salah
satu wait event ternyata adalah 70% dari total wait
event, hal tsb bisa di-ignore krn tdk signifikan).
regards,
tomi
--- nadas <[EMAIL PROTECTED]> wrote:
> Terima Kasih
> DB fiel sequential read sangat dominan
> kira kira 70% wait event karena masalah tersebut
>
> saya sudah coba naikan db_block_buffer
> sebanyak 300.000 block
> tetap ajah masih sekitar 70 %
>
> apakah database saya sehat ??
> apa yang harus saya lakukan
>
>
> On Sun, 21 May 2006 22:31:02 -0700 (PDT)
> Tomi Wijanto <[EMAIL PROTECTED]> wrote:
> > Itu adalah wait event yang berhubungan dengan
> akses
> > single block data dari disk.
> >
> > Misalkan ketika melakukan query yg memakai index,
> > kalau block index tsb tidak ada di buffer, maka
> Oracle
> > akan mengambil dari disk. Waktu yg diperlukan utk
> > mengambil block tersebut dari disk hingga ke
> buffer
> > akan dicatat sebagai db file sequential read
> (DFSR).
> >
> > Wait event ini bisa dibilang pasti ada, karena tdk
> > mungkin semua block ada di buffer. Yg penting
> adalah
> > mengidentifikasi SQL yg mempunyai DFSR yg besar,
> > karena bisa jadi indexnya kurang selektif.
> >
> > Efeknya ke aplikasi adalah response time bertambah
> > lama. Karena response time adalah waktu system
> > ditambah waktu tunggu, maka semakin besar wait
> event
> > DFSR otomatis menambah besar komponen response
> time.
> >
> > Kalau memang event ini signifikan, maka yg penting
> > adalah mengidentifikasi SQL2 yg menyebabkannya
> (pake
> > statspack tinggal dilihat 'SQL ordered by READ').
> > Kemungkinan lain adalah disk-nya yg terlalu
> lambat,
> > sehingga waktu utk mengambil dari disk juga lama.
> >
> > regards,
> > tomi
> >
> > --- nadas <[EMAIL PROTECTED]> wrote:
> >
> >> Hi oracle mania
> >>
> >> saya mo tanya
> >> kalo db file sequential read itu
> >> terjadi karena apa yach ??
> >>
> >> teruas efeknya ke aplikasi apa
> >> dan cara ngindarinnya gimana??
> >>
> >> salam
> >> NDS
__________________________________________________
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
SPONSORED LINKS
| Membership database software | Database mortgage software | Pda database software |
| Database management software | Oracle database administration | Oracle database management |
YAHOO! GROUPS LINKS
- Visit your group "indo-oracle" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
