Merhaba Arkadaşlar,
Bu yazımda sizlere Oracle AWR ( Automatic Workload Repository ) raporunun neler içerdiğini ve bu içeriklerin nasıl yorumlanması gerektiğini anlatacağım. Bu yazıyı okumadan önce AWR raporunun ne olduğunu ve nasıl oluştuğunu anlatan şu yazımı okumanızı tavsiye ederim.
Oracle AWR ( Automatic Workload Repository ) raporu veritabanı hakkında en detaylı istatistik ve durum raporu veren bir rapordur. Bu rapor çok çok fazla bilgi içerdiği için ben sadece sorun anlarında en çok baktığımız kısımları anlatacağım. Şimdi önceki yazımda aldığım AWR raporunun içeriğini başlıklar halinde inceleyelim.
Report Summary
AWR Header Bölümü
AWR Raporunu açtığınız zaman ilk olarak AWR raporunun başlığı gibi görünen aşağıdaki header kısmı çıkacaktır.
Bu kısmı detaylı bir şekilde incelediğiniz zaman Veritabanına, Veritabanı Sunucusuna ve AWR raporuna ait temel bilgiler yer almaktadır. Bu bilgiler genel olarak yukarda görüldüğü gibi Veritabanının Adı, Veritabanı Son olarak kapatıp Açtığınız Tarih, Sürüm bilgisi, Cluster olup olmadığı, Veritabanı Sunucusunun Adı, Sunucunun Platform bilgisi,CPU sayısı ve Memory alanı gibi bilgiler yer almaktadır. Veritabanı ve Sunucu bilgilerinin verildiği kısmın altında AWR raporunun oluşturulduğu Snapshotların ID bilgisi Başlangıç, Bitiş zamanları ve Aktif session ların sayısı ve 2 Snapshot arasındaki DB Time ve Elapsed değerleri verilmiştir.
Cache Sizes Bölümü
Bu bölümün AWR raporuna ait içeriği aşağıdaki gibidir.
Cache Sizes kısmının içeriğine baktığımız zaman Veritabanına ait Buffer Cache, Shared Pool ve Log Buffer alanlarının boyut bilgisi ve Veritabanı için seçilen Standart Blok Size bilgisi yer almaktadır. Bu değerlerde eğer sıkıntı varsa değiştirebilirsiniz.
Load Profile Bölümü
Bu bölümün AWR raporuna ait içeriği aşağıdaki gibidir.
Load Profile bölümü adından da anlaşılacağı üzere Veritabanının 2 snapshot aralığındaki Yük istatistiğini verir bize. Bu bölümde yukarda görüldüğü gibi Veritabanında 2 snapshot aralığında Saniye Başına düşen ve Transaction başına düşen DB Time, Redo Size, Logical Reads,Physical Reads, Executes ve Transactions bilgileri gibi önemli bilgiler yer alır.
AWR raporunun performans problemi olup olmadığını anlayabilmek için bakacağımız önemli bir kısmıdır ancak yinede bu bölüm bize tamamen bir problem olup olmadığını göstermez. Çünkü bu kısımda veritabanında çok yük olduğunu anlasak bile belki de veritabanı bu yükü kaldıracak bir seviyede olduğu için sıkıntı vermiyordur. Ancak bu bölüme bakarak Veritabanının bu zaman aralığındaki transactionların türünü ve istatistiğini öğrenebiliriz. Mesela yukardaki grafiğe baktığımız zaman Redo Size değeri çok büyük çıkmış bunun sebebi olarak hemen şunu söyleyebiliriz bu veritabanının ilgili AWR aralığında DML işlemleri çok fazla yapılmıştır. Ayrıca Logical Read değeri ve Transaction değeri ilgili sisteme göre biraz yüksek çıkmış bu durumda veritabanının bu aralıkta yoğun çalıştığını söyleyebiliriz. Bu bölüme ait parametreler önemli olduğu için bu parametrelerin ne olduğunu aşağıda açıklayacağım. Bu parametrelerin değeri Saniye başına ve Transaction başına düşen miktar olmak üzere yukardaki gibi ayrı ayrı verilmiştir.
DB Time(s): 2 snapshot aralığında Veritabanındaki sessionların toplam çalışma süreleridir. Bu değer için Sessionların CPU da geçirdikleri zaman ile Beklemeler diyebiliriz yani formülize edersek eğer DB Time(s)=CPU Time + Waits şeklindedir.
DB CPU(s): 2 Snapshot aralığında sessionların CPU da geçirdikleri toplam süreyi verir.
Redo Size: 2 snapshot aralığında veritabanı tarafından üretilen Redo Miktarıdır.
Logical Reads: 2 snapshot aralığında Databasede okunan ( Physical reads ve Block Changes ) blokların sayısıdır. Bu değer için şu formül geçerlidir. Logical Reads= Consistent Gets + DB Block Gets
Block Changes: 2 snapshot aralığında değişen blok sayısını verir.
Physical Reads: 2 snapshot aralığında bellekte bulunmayıp fiziksel diskteki Datafile lardan okunan blokların sayısıdır.
Physical Writes: 2 snapshot aralığında fiziksel diskteki Datafile lara yazılan blokların sayısıdır.
User Calls: 2 snapshot aralığında Veritabanı kullanıcıları tarafından veritabanına gönderilen Sorguların Sayısıdır.
Parses: 2 snapshot aralığında veritabanında meydana gelen Hard Parse ve Soft parse larının toplamıdır.
Hard Parses: 2 snapshot aralığında veritabanında meydana gelen Hard Parse ların sayısıdır. ( Veritabanına gelen sorgu daha önce çalıştırılmamışsa oracle çalıştırılan SQL i parse edip library cache de bulunan Shared SQL Area ya kaydeder bu işleme hard parse denir. Veritabanına gelen sorgu daha önce çalıştırılmışsa Oracle bu SQL i tekrardan parse etmeden önceki execution planı kullanır bu işleme de soft parse denir. )
W/A MB Processed: 2 snapshot aralığındaki Hash Join gibi Sort gibi operasyonları gösterir.
Logons: 2 snapshot aralığındaki veritabanındaki logon ların sayısıdır.
Executes: 2 snapshot aralığındaki Çalıştırılan SQL lerin sayısıdır.
Rollbacks: 2 snapshot aralığındaki Rollback lerin sayısıdır.
Transactions: 2 snapshot aralığındaki Transactionların sayısıdır.
Top 5 Timed Foreground Events
Bu bölümün AWR raporuna ait içerik bilgisi aşağıdaki gibidir.
Bu bölüm AWR raporu içerisindeki en önemli bölümlerden birisidir. Genellikle problem anında alınan AWR de bakılan ilk kısımdır. Adındanda anlaşıldığı üzere veritabanında oluşan en yoğun 5 bekleme olayını ve veritabanında performans problemlerine neden olan bottleneck ( Darboğaz ) leri gösterir.
Yukardaki örnek bölüme baktığımız zaman 1.sıradaki değer olarak Log File Switch görünmektedir. Bu sorun genelde Log File lerin küçük olmasından ve bu yüzden çok sık switch etmesinden kaynaklanır. Yukardaki bölüm her zaman değişebilir örneğin farklı aralıktaki snapshotlardan bir AWR raporu oluşturduğumuzda yukardaki problemler aşağıdaki gibi değiştiğini görüyoruz. Örneğin; Yukardaki raporun Son kısmında görünen DB CPU Eventi aşağıdaki raporun ilk sırasına gelmiş durumda. Bu bölümdeki Wait Events leri ayrıntılı bir şekilde yazmayacağım başka bir yazımda tek tek inceleyeceğim.
Main Report
Bu bölümün içerdiği raporlar listesi aşağıdaki gibidir.
Bu bölümün ilk maddesindeki Report Summary kısmını yukarda anlattım bundan sonra gelen Wait Events Statistics ve özellikle SQL Statistics kısmı çok çok önemlidir.
Wait Events Statistics
Time Model Statistics
Bu bölümün içerdiği istatistikler aşağıdaki gibidir.
Time Model Statistics bölümünde Veritabanının en çok nerede zaman tükettiğini bulabiliriz. Yukardaki rapora baktığımız zaman Oracle Instance sı en çok SQL lerin execute edilmesinde zaman harcamış ardından 2.sırada ise Transactionların CPU da zaman harcanması çıkmış.
SQL Statistics
AWR Raporlarına ait en önemli bölümlerden birisi çeşitli kriterlere göre sunulan Sistem kaynaklarını en çok yoran SQL lerin verildiği bu bölümdür. Bu bölümde aşağıdaki kriterlere göre SQL ler sıralanmıştır. Bunları aşağıda tek tek ele alacaz.
SQL Ordered By Elapsed Time
Bu bölüme ait AWR raporundaki ilgili içerik aşağıdaki gibidir. SQL lerin Tablo isimleri ve Şema adları özel olduğu için etik kurallar gereği kararttım.
Bu bölümde Veritabanında uzun süren sorgular en yüksekten en alçağa doğru olmak üzere sıralanmıştır. Örneğin; İlk sırada 9344 saniye (15-18 dk) süren bir sorgu 67.608 defa çalışmış ve her bir Execution 0.14 saniye sürmüş. Toplam Veritabanı süresine oranlarsak %28.17 li bir oran almış Toplam CPU da ise %4.82 ve I/O olarak ise %0.06 bir değer almış. Bu SQL in SQL_ID si ise abb9zgftqumnn şeklindedir. Bu SQL ID sine tıkladığımız zaman ilgili SQL in Açık hali verilecektir.
SQL Ordered By CPU Time
Bu bölüme ait AWR raporundaki içerik aşağıdaki gibidir.
Bu bölüm Veritabanında En çok CPU harcayan sorguların listelendiği bölümdür. En çok CPU zamanı harcayan sorgular SQL Tuning için aday sorgulardır bunlar problem anında hemen incelenir ve ihtiyaç duyulursa SQL Tuning yapılır.
SQL Ordered By Gets
Bu bölüme ait AWR raporundaki içerik aşağıdaki gibidir.
Bu bölümde Veritabanında Buffer Gets den en çok mantıksal okuma yapan sorgular verilmiştir.
SQL Ordered By Reads
Bu bölüme ait AWR raporundaki içerik aşağıdaki gibidir.
Bu bölümde Veritabanındaki sorgulardan en yüksek Physical I/O yapan sorgular verilmiştir. Bu bölümde çok fazla Physical I/O yapan sorgular ın kullandığı tablolar genelde Index i olmayan yada Index i bozuk tablolar olmaya adaydır. Eğer bundan dolayıysa ilgili tablolarda index oluşturulur.
SQL Ordered By Parse Calls
Bu bölüme ait AWR raporundaki içerik aşağıdaki gibidir.
Bu bölümde Hard Parse ve Soft Parse sayısı çok fazla olan sorgular verilmiştir.
Böylece bu yazınında sonuna gelmiş bulunmaktayım bir sonraki yazıda görüşmek dileğiyle Esen kalın..
Oracle Exadata SQL Server Goldengate Weblogic EBS ve Linux konusunda aşağıdaki konularda 7×24 Uzman Danışmanlara yada Eğitimlere mi İhtiyacınız var mehmet.deveci@gridgroup.com.tr adresine mail atarak Bizimle iletişime geçebilirsiniz.
– Oracle Veritabanı Danışmanlığı
– Oracle Veritabanı Bakım ve Destek
– Exadata Danışmanlığı
– Exadata Bakım ve Destek
– SQL Server Veritabanı Danışmanlığı
– SQL Server Veritabanı Bakım ve Destek
– Goldengate Danışmanlığı
– Goldengate Bakım ve Destek
– Linux Danışmanlığı
– Linux Bakım ve Destek
– Oracle EBS Danışmanlığı
– Oracle EBS Bakım ve Destek
– Weblogic Danışmanlığı
– Weblogic Bakım ve Destek
– Oracle Veritabanı Eğitimleri
– Oracle VM Server Danışmanlığı
– Oracle VM Server Bakım ve Destek
– Oracle EPPM Danışmanlığı
– Oracle EPPM Bakım ve Destek
– Oracle Primavera Danışmanlığı
– Oracle Primavera Bakım ve Destek
– Oracle Eğitimleri
– SQL Server Eğitimleri
– Goldengate Eğitimleri
– Exadata Eğitimleri
– Linux Eğitimleri
– Oracle EBS Eğitimleri
– Oracle VM Server Eğitimleri
– Weblogic Eğitimleri
– Oracle EPPM Eğitimleri
– Oracle Primavera Eğitimleri