Özet: DBA’lere, veritabanlarında  en çok “Application Waits” yapan sorguların tespiti ve incelenmesi üzerine bilgi vermek.

 

“Application Waits” Nedir?

“Application Waits”, adından da anlaşılacağı gibi, “Uygulamaların, SQL sonuçlarının dönmesini beklemesini” anlatan bir terimdir.

Veritabanında En Çok Görülen Beklemeler

Öncelikle veritabanındaki tüm beklemeleri ortaya dökelim. Diğer beklemeleri daha sonra ele alırız. Şimdilik “Application Waits” beklemelerine odaklanıyoruz.

Alttaki sorgudan son 1 hafta gün gün, sorgularınız ne beklemesi yapmış özet olarak bulabilirsiniz. “Application waits”in en fazla yapılan beklemelerden olduğunu görebiliyoruz.

select 
 trunc(end_interval_time) Wait_date,
 sum(time_waited)/100 Total_Wait_Time_second, --(time_waited is in hundredths of a second)
 wait_class Wait_Type,
 service_name
from
 dba_hist_service_wait_class 
join 
 dba_hist_snapshot USING(snap_id) where end_interval_time > sysdate -7
group by
 trunc(end_interval_time), wait_class,service_name
order by 
 Wait_date desc, Total_Wait_Time_second desc;

 

“Application Waits”i Hangi Sorgular Yapıyor?

Alttaki sorgunun sonucunda, bu beklemeye en çok neden olan sorguları bulabilirsiniz. En çok “Select…for update”, update ve insert sorgularının bu beklemeye neden olduğunu görüyoruz.

Select * from
(select
 round(application_wait_time / 1000/ 1000) "APP_WAIT_TIME_second", --(Application wait time is "in microseconds")
 sql_id,
 plan_hash_value,
 sql_fulltext
 from
 v$sqlstats
 order by application_wait_time desc )
where rownum <=30;

 

Bu sorgular “Enterprise Manager” ekranlarında kırmızı renkte bekleme(application waits) yapan sorgular oluyor. O ekranı kullanarak da istediğiniz zaman diliminde bu beklemeleri yapan sorguları ve bir kısım detayları görebilirsiniz.

 

Hangi Event’ler Bu Beklemeye Neden Oluyor?

Şimdi de yukarıdaki sorgudan bulduğumuz, en çok “Application Waits” yapan sql_id’nin hangi event’lerde beklediğini bulalım. “enq: TX – row lock contention” beklemesi yaptığını görüyoruz.

select
 sql_plan_hash_value, event, wait_class, count(*)
 from
dba_hist_active_sess_history
 where sql_id='d1234afh6cqpz' and sample_time > sysdate-7
 group by sql_plan_hash_value, event, wait_class
 order by 3 desc;

 

Bu Beklemeleri Azaltmak İçin?

En son sorgumuzda, sorgunun hangi event’lerde beklediğini bulduk.

Bizim yukardaki sorgularımızda, “application wait” olarak en  çok “enq: TX – row lock contention” event beklemesi yaptığını gördük.

Bu event, çoğunlukla uygulama mimarisinden kaynaklanan bir lock’lama beklemesidir. Sorgudaki “select…for update” yapısından dolayı bu bekleme oluyor. Dolayısı ile uygulama ekiplerine durum anlatıp iyileştirmeler talep edilmeli.

Bu event’e ayrıca aynı data block’larına yapılan DML’lerden dolayı ortaya çıkan “buffer busy wait”ler neden olabilir.

Bu sorgunun yaptığı, “application wait” tipi haricindeki diğer event’lere bakıldığında en çok “gc…”(global cache) beklemeleri görüyoruz. Ortamımız RAC (Cluster) olduğu için, ve sorgularda veritabanı diğer nod’un cache’ine gidip orayı da kontrol ettiği için bu beklemeler görünüyor. Bu beklemelerin nedenleri de veritabanı seviyesinde detaylı incelenmeli.

Her event ayrı olarak incelenip nedenleri bulunmalı ve iyileştirmeler yapılmalı. Bu event’leri ayrı yazılarda ele alacağız.