Bu yazımızda Oracle Performans Troubleshooting de kullanılabilen en etkili
toolar olan awr,ash ve addm raporları hakkında
pratik kullanım bilgileri ve bu raporların hangi durumlarda daha etkili
bilgiler sunabileceği hakkında faydalı bilgiler yazmaya çalışacağız.
AWR Raporları
Awr Raporları Bir Oracle Veritabanındaki performans istatistikerinin
toplantığı data kaynağıdır. Ancak Awr raporlarından tam anlamıyla
yararlanabilmek için öncelikle istatistiklerin yorumlanabilmesi ve db ye ait
geçmişteki istatisklerin de bilinmesi ve db ye bağlanan uygulamalarında
yapısının biraz tanınmış olması gerekir. Bununla birlikte bir dba nın bu
bilgilere sahip olması uzun zaman ve uğraş isteyebilir. Biz burada awr
raporlarının pratik olarak yorumlanmasına değinecek ve veritabanındaki
performans darboğazlarının keşfedilmesinin awr raporları üzerinde nasıl
gerçekleştirileceğine dair bilgiler sunacağız.
Awr
Raporu Nasıl Elde Edilir?
Awr raporları en basit olarak Enterprise Manager Üzerinde elde edilebilir.
Aşağıdaki screen shutları sırasıyla inceleyerek aım adım awr raporlaru elde
edebilirsiniz.
Şekil 1: Enterprise Manager Database Home Ekranına ulaştıktan sonra Sarı
ile üzerini boyadığımız Server Tabına tıklanır.
Şekil2:Server tabında yine üzerini highlight ettiğimiz Automatic Workload
Repository linki ne tıklanır. Burada göreceğiniz gibi bir çok tool mevcuttur
ancak biz şu an AWR ile ilgileniyoruz.
Şekil3:Karşımıza çıkan Automatic Workload Repository ekranında Edit
Butonuna tılayarak AWR data toplama seçeneklerini değiştirebiliriz. Şekil 3 de
göründüğü üzere örnek veritabanı 30 gün süre ile awr bilgilerini tutuyor ve 60
dakikada bir sanpshot alıyor. Awr ayarlarına dair detaylı bilgiyi Oracle Database Maintenance (Database
Bakımı) yazımızdan
inceleyebilirsiniz.
Yine şekil 3 de üzeri boyanmış Run Awr Report Butonuna tıklıyoruz.
Şekil 4 de üzeri boyanan yukarıdaki kısımda tarih ve aşağıdaki kısımda da
awr raporu için başlangıç noktasını seçiyoruz ve OK butonuna basıyoruz.
Şekil5 de de Yine tarih seçip awr raporu için bitiş noktası seçiyoruz.
Şekil 6 da ki gibi bir ekran karşımız çıkacak bekliyoruz…
Şekil 7 de göreceğiniz gibi Awr raporumuz hazır dilersek yukarı sağda
buluna Save To file butonu ile raporumuzu bilgisayarımıza kaydedebiliriz.
Awr raporunu Yukarıda anlatıldığı gibi Enterprise Manager yada Grid Control
Ekranında elde etmek her ne kadar daha kolay ve daha okunabilir olsada iyi bir
dba scriptlede bu raporları elde etmeyi bilmelidir.Çünkü Grid yada Enterpise
Manager her zaman çalışacak diye bir şey yok. Yeri gelir bu ekranlarda
ulaşılamaz olabilir. Bu durumda Sorunun acil tespit edilip aksiyon alınması
için awr raporundan faydalanmak kaçınılmaz olabilir.Espirili anlatımı ile eğer
dba iseniz database ile aranıza kimseyi sokmamayı bilmelisiniz.
Aşağıda awr raporlarını script ile nasıl elde edeceğimiz bulunmaktadır.
--Awr ayarlarının değiştirilmesi için;
SELECT snap_interval, retention FROM dba_hist_wr_control;
BEGIN
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
retention => 43200, -- Dakika (43200 = 30 Days).
interval => 30); -- Dakika.
END;
/
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
retention => 43200, -- Dakika (43200 = 30 Days).
interval => 30); -- Dakika.
END;
/
--Awr Snapshot üretilmesi
BEGIN
DBMS_WORKLOAD_REPOSITORY.create_snapshot ();
END;
/
--Awr Snapshot Silinmesi
BEGIN
DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range (low_snap_id => 1981,
high_snap_id => 2004);
END;
/
--Kullanabileceğiniz Awr Snapshotların listelenmesi
SELECT snap_id,
CAST (begin_interval_time AS
DATE),
CAST (end_interval_time AS
DATE)
FROM dba_hist_snapshot
ORDER BY 3 ASC;
--Awr Baseline Üretilmesi (Baseline Belli bir aralıktaki snapsotlar için awr
raporu üretilip db de saklanmasıdır. Daha sonra performans karşılaştırmasında
bunlar kullanılabilir.)
BEGIN
DBMS_WORKLOAD_REPOSITORY.create_baseline
(
start_snap_id => 2305,
end_snap_id => 2310,
baseline_name => 'Good Nightly Batch');
END;
/
--Baseline lerin listelenmesi
SELECT baseline_id,
baseline_name,
start_snap_id,
end_snap_id
FROM dba_hist_baseline
ORDER BY 1
/
--Baselineların silinmesi
BEGIN
DBMS_WORKLOAD_REPOSITORY.drop_baseline ('Routine Jobs', TRUE);
END;
/
--Awr Raporlarının Script ile üretilmesi
$ORACLE_HOME/rdbms/admin/awrrpt.sql
$ORACLE_HOME/rdbms/admin/awrrpti.sql
--Belli bir instance için Awr raporu
$ORACLE_HOME/rdbms/admin/awrrpt.sql –Belli bir sql için awr raporu
$ORACLE_HOME/rdbms/admin/awrrpti.sql
--Belli bir instancdaki sql için Awr raporu
$ORACLE_HOME/rdbms/admin/awrddrpt.sql –Karşılaştırmalı awr raporu
$ORACLE_HOME/rdbms/admin/awrddrpti.sql
--Belli bir instance için karşılaştırmalı Awr raporu
Awr Raporları Nasıl
Yorumlanmalıdır?
Eğer Veritabanımızda bir performans problemi varsa ilk bakmamız gerekn awr
raporudur. Awr raporuna bakarken “veritabanı
neyi bekliyor” sorunu sormamız gerekir. Odaklandığımız konu burada
beklemeler olmalıdır. Çünkü en çok beklemenin oluştuğu darboğazı çözmek
veritabanı performansı için en çok faydayı sağlamak demektir. Performans kaybına
en fazla sebep olan beklemeye odaklanabilmek için ilk bakacağımız awr
raporundaki “top 5 timed event” kısmı olmalıdır.
Yukarıdaki örnekte tipik bir top 5
timed event tablosu verilmektedir.Burada herbir evente ait %total call time
kolonuna baktığımızda % cinsinden veritabanının en fazla beklediği eventi
görebiliriz. Sonrasında bu evetlere ait beklemeleri azaltmak bizim asıl
hedefimiz olmalıdır. Aşağıda daha önce anlattığımız bazı eventler ve çözüm
yöntemlerine ait yazılarımızı bulabilirsiniz. Zamanla en genel bekleme
olaylarına ait yazılar yazmaya devam edeceğiz.
Yine top 5 timed event arasında Cpu Time yüksek olması kötü yazılmış sql
lerin olmasından kaynaklanır. Cpu Time Değerinin %20 den fazla olması sql
tuning yapılması gerektiğini dair önemli bir ipucudur.Bu durumda awr
raporundaki sql istatistiklerine (aşağıdaki şekilde gösterildiği gibi) göz
atmanız gerekir.Sql istatistiklerine göz atarkende otrak noktanız “logical and physical reads”
değerleri yüksek olan sqlleri
tespit etmek olmalıdır.
I/O ile iligli eventlerin fazla
değere sahip olmasının sebei ise iki şey olabilir. Database çok fazla I/O
yapıyordur yada bireysel I/O lar yavaş çalışıyordur.Ancak I/O ile ilgili Avg.
Wait (ms) <20 genelde kabul edilebilir bir değerdir ve bu değer ne kadar
küçükse veritabanının I/O bakımından o kadar hızlı olduğunu gösterir.
Ancak Aşağıdaki örnektede incelerseniz Av Rd(ms) kolonu vardır. Bu değerin
Av Rd(ms)>20 I/O darboğaz olduğunu gösterir. Bu değerinde ortalama 7-8 civarında
olmasını bekleriz.
Genel olarak eğer database yavaşsa ve top 5 timed Events kısmında “db file
sequential reads” ve “db file scattered read” ve “Cpu Time” eventleri
görülüyorsa bu durumda sql Tuning’e
yoğunlaşmalıdır. Bu durum manuel yapılabileceği gibi “sql tuning advisor” da
kullanılabilir.
Bir diğer faydalanabileceğimiz kısımda load profile kısmıdır. Bu kısımda
database ‘ e ait yük istatistiklerini bulabilir ve kullanabiliriz. Eğer 2 gün
önce performans gayeet iyi iken bu gün performans problemi yaşıyorsanız ve
belirgin bir kök sebep bulamadıysanız load profile bölümlerin karşılaştırarak
kök neden hakkında doğru yol almış olursunuz. Nedir Değişen yük? Veya nedir
artan yük?
Diğer bir önemli ksıısmda genel database performans tuning yaparken
kullandığımız Instance Efficiency Kısmıdır.
Bu kısımda “Execute to Parse %” oranının yüksek olması cursor
kullanımının iyi derecede olduğunu belirtir. “non-Parse Cpu” değerinin yüksek
olması ise sql tuning’e yoğunlaşmamız gerektiğini gösterir.
Bu yazımızda awr raporları nasıl elde edilebilir ve performans tuning
yaparken nasıl incelenmelidir araştırmaya ve faydalı bir yazı yazmaya
çalıştık.Burada yazılanlar awr raporlarının kullanılması için asla yeterli
olmayacaktır ancak belki bilgi dağarcığınıza yeni bir şeyler eklemiş olursanız
bu yazının amacı yerine gelmiş olur.
Bir sonraki yazımız ASH Raporları’ nda görüşmek üzere.
Özcan YILDIRIM
emeğinize saglık çok güzel yazmışsınız..
YanıtlaSilelinize sağlık, teşekkürler
YanıtlaSilTesekkurler
YanıtlaSilEmeğinize sağlık
YanıtlaSil