DB Performans terimleri

[sezai can kiren]

Selamlar Erman bey,

https://ermanarslan.blogspot.com/search?q=awr+report postunuzdaki açıklamalara istinaden bir kaç sorum olacaktı.

1. Bu eventlerde nasıl bir iyileştirme yapabiliriz.
2. Read I/O for sorts / Read I/O for sorts kısmındaki  I/O for sorts un anlamı nedir. ?

db file sequential read – Random I/O , single row , mostly index IO
db file scattered Read – Sequential I/O , Full table scan, index fast full scan
direct path read – Sequential I/O , Full table scan , directly to the PGA
direct path read temp – Read I/O for sorts
direct path write temp – Write I/O for sorts
read by other session – sessions waiting  while another session is reading the same from the disk.

Selamlar,
Sezai.

[ErmanArslansOracleBlog]

Selam,

Tabii bunlar çok uzun konular. Ama hızlıca toparlamaya çalışayım.

sequential ve scattered readlerde, I/O hızı ve daha az I/O (gereksiz I/O nun elimine edilmesi - SQL tuning vb işler) ile iyileştirme sağlanabilir. Özellikle Index yani sequential access te I/O nun latencysi önemli. Büyük ve bulk okumada ise throughput..

I/O for sorts dediği, aslında direk PGA okumalarında da (join ve sort gibi işlemler için) bu direct path read temp görünür. write kısmı da PGA den direk yazmalarda..

Bunu düşürmek için yüksek sortlardan kaçınmak lazım.
PGA de doğru size edilmeli. Tabii yine I/O subsystem (temp I/O) ve ilgili SQL ler tune edilmeli (belki de sqller çok sort ettirecek execution planlarla çalışıyorlar...) Daha az sort veya daha az veriyle direct path işlemleri sağlamak için..  Bu temp I/O genelde problem değildir ama semptopmdur.. Muhtemelen kötü planlı queryler var ortamda.. (eğer I/O subsystemde anormal bir yavaşlık vs yoksa, PGA size da okayse, tabii ki)

Read by other session zaten adı üstünde, bir sessionın istediği verinin o sırada başka bir session tarafından zaten buffer cache e getiriliyor olmasıyla ilgili.
Aynı anda access edilen Hot objelerden kaynaklı aslında. Aynı indexin aynı bölümü yada aynı tablo eşzamanlı olarak farklı sessionlarda access edildiğinde mesela...
Bunda da tuning aslında bu contentionı elimine etmekten geçiyor. Blockları belki dağıtıp, aynı anda aynı blockların farklı sessionlar tarafında talep edilmesi engellenebilir.
Tabii yine sql tunning. Özellikle hot objelere ve blocklara giden queryler...
Block size belki düşürülebilir. (duruma göre) Ama tabii bu tip aksiyonları almadan önce detaylı analizler gerekli..
Performans tuning işi zaten böyle bir iş Oracle da..
Böyle durumlarda özellikle yabancı bir waitin çok ön plana çıktığı durumlarda, Oracle Support a da mutlaka bakın.. Release specific bug vs de olabiliyor ama bu waitlerde değil tabii ki. Bunlar çünkü temel waitler, bunlardaki beklemeler instance ve sql tuning ile ilgili.

[sezai can kiren]

Tek kelime ile mükemmel açıklama, yönlendirme

Teşekkürler Erman Bey.