Awr raporlarını daha çok bir performans sorunu yaşadığımızda çıkarırız. Awr raporları ile veritabanındaki aktiviteleri rahatça görebiliriz. Bu raporlarda performansla ilgili bilgiler güzelce ayarlanmışlardır. Awr raporlarını çıkarırken 1 saatten daha uzun aralıkları kontrol etmemiz genel sorunları fark etmemiz için daha yararlı olur.
AWR Raporları Nasıl Yaratılmaktadır?
Her 60 dakikada bir veritabanında bir snapshot alınır. Snapshot da veritabanın durumu ile ilgili o andaki bilgiler toplanır. Sonrasında bu bilgiler data dictionary de depolanır. Bu snapshot'lar bir id ile işaretlenir.
AWR Raporu:
Veritabanında asıl olarak aradığımız sorun performans olduğu için sistemin ne için beklediğini görmek yani wait event'lerini araştırmak daha önemlidir. Process'ler beklediğinde genelde başka process'ler tarafından bekletildikleri için beklerler.
Raporun başlangıcında sistem ile ilgili genel bilgiler verilir. Sistemin kullandığı hafıza, bu hafızanın nerelere ayrıldığı, sistemdeki CPU kullanımı gibi bilgiler yer almaktadır.
Raporun içerisinde Wait Event'leriyle ilgili, Memory kullanımı ile ilgili ve diğer veritabanı içerisindeki ana modüllerdeki kullanım istatistikleri gösterilir.
Bazı incelediğimiz başlıklar aşağıdaki gibidir:
Load Profile:
Bu bölümde SQL'lerle ilgili profil bilgileri yer alınır. Üretilen redo log'lar fiziksel okuma ve yazmalar, transaction'lar, Parse edilen SQL sayıları ve bunların istatistikleri yer alır. Sisteme göre bunların sayılarının fazla mı az mı olduğunu tahmin edebiliriz. Aşağıdaki örneğimize bakaraktan sisteme girişilerin(logons) az olduğunu, transaction'ların fazla olmadığını, hard parse'ların minimum değerlerde olduklarını görebiliriz. Buradan da sistemin üzerindeki yükün çok fazla olmadığını anlayabiliriz.
DB Time: Kullanıcının veritabanında harcadığı zamandır. Bu değer kullanıcının background process'leriyle beklediği süreyi vermez. Kendi session'ımız için olan bekleme süresini görmek için aşağıdaki gibi bir sorgu yazabiliriz.
select * from v$sess_time_model where stat_name='DB time' and SID=2;
Diğer bir sorgu ise bütün veritabanı için geçerlidir.bütün session'ların db_time'ının toplanmasıyla bulunur.
select * from v$sys_time_model where stat_name='DB time';
DB CPU: Kullanıcının CPU'da geçirdiği zamandır. Değerler mikrosaniye cinsindendir.
Sequence Load Elapsed Time: Sequence'larda gelecek numaranın elde edilmesi için geçirilen zamandır. Eğer sequence'lar cache'lenirse bu miktar sıfırlanır.
Redo Size: Üretilen redo verileridir.
Logical Reads:
Physical Reads: I/O isteklerine neden olan okumalar. Veritabanı bloklarından direk okumalar
Block Changes: O aralıkta değiştirilen blok sayısı
Physical Writes: Bloklara yazma işlemleri
User Calls: Kullanıcılar tarafından gönderilen sorgular
Parses: Hard ve Soft parse'ların toplamı
Hard Parse: Cache'de olmayan ve tamamen yeni bir SQL parse'ı gerektiren sorgular. Bu sorgular analiz edilerek planları çıkartılır.
Soft Parse: Geçmiş Hard Parse edilmiş sorgulardan çıkartılırlar. Hard Parse'lara göre daha az kaynak tüketirler. Örneğin çalışanlar tablosu Cache'de yokken sorgulandıysa Hard Parse edilir. Sonrasında bu tabloyla ilgili başka bir bilgi istendiğinde bu sorgu artık Hard Parse edilmez. Daha önceki kullanımdan kalan bilgilerle Soft Parse edilir.
Failed Parse Elapsed Time: Parse hatasıyla sonunda fail eden sorgulardır.
Logons: Uygulamaya yapılan girişler
Executes: Çalıştırılan SQL'ler. Select ifadeleri için bu istatistiğin içine sonuçların getirilmesi de eklenir.
Background CPU Time: Veritabanının background process'leri tarafından harcanan zaman
Transactions: Yapılan Transaction'lar.
Not: Transaction Nedir?
Transaction olarak belirttiğimiz sorgular ya DML ifadeleridir ya da DDL ifadeleridir. DDL ifadeleri gönderildiğinde otomatik olarak commit edilirken, DML ifadeleri gönderildiğinde ertesinde commit veya rollback sorgularıda gönderilmelidirler ki transaction bitsin.
Bütün istatistikleri görmek için v$statname sorgusu kullanılmalıdır.
select * from v$statname;
Time Model Örneği:
Buradaki örneğimize göre SQL'lerin çalışma zamanı en fazla zaman alan işlem. Awr raporunun alındığı aralıkta PL/SQL prosedürünün çalıştırılması en fazla zaman alan 3. işlemdir.
Session'ımızdaki Toplanmış İstatistikler:
Buradan da session'ımızla ilgili istatistikleri awr raporu çıkarmadan görebiliriz.
select * from v$mystat a inner join v$statname b on a.statistic#=b.statistic#;
Session'ımızı başka session'larla karşılaştırmak istersek aşağıdakinin benzeri bir sorgu yazabiliriz. Bu sorgu kısaca session pga memory'si 30mb'dan büyük olan session'ları bulmak üzerinedir.
select t.sid,username,name,value from
v$statname n,v$session s, v$sesstat t
where s.sid=t.sid
and n.statistic#=t.statistic#
and s.type='USER'
and s.username is not null
and n.name='session pga memory'
and t.value> 30000;
Instance Efficency Percentages:
Bu bölümde memory'nin hangi bölümlerine ne kadar gidildiği belirlenir. Bu oranlar bir data parçasının hangi bölümde ne kadar çok bulunduğunu gösterir. Hepsinin değerleri %100'e yakın olmalıdır. Aşağıdaki örnek te Execute Parse % ve Parse CPU to Parse Elapsed % yüzdeleri aşağıdaki örnekte düşük olmalarının nedeni parse etmeyle ilgili bir problem olabilir. Bind değişkenlerinin kullanılmaması veya Shared Pool'un yetersiz olması nedeniyle bu kadar düşük olabilir.
Buffer Hit: Bu oran aranan blokun diskten okuması yerine, buffer cachede kaç kere bulunduğunu gösterir.
Buffer Nowait: Data'nın yüzde kaç oranında hiç beklemeden bulunduğunu gösterir.
Library Hit: SQL ve PL/SQL'in shared pool içerisinde yüzde kaç oranında bulunduğunu gösterir.
In-Memory Sort: Sort(Düzenleme) işlerinin disk yerine hafıza kısmında okumasının yapılmasının oranının kaç olduğunu gösterir.
Soft Parse: Shared Pool içerisine depolanmış SQL'in ne kadar çok kullanıldığını gösterir.
Latch Hit: Latch işlemlerinin hiç bekletilmeden ne kadar oranda erişildiğini gösterir.
Shared Pool Statistics:
Buradaki istatistikler hafızanın ne kadarının kullanıldığını göstermektedir. Hafızanın yüzde 90'ından fazlası kullanılıyorsa burada Shared Pool için ayrılan hafıza konusunda eksiklikler olduğu öngörülebilir.
Advisory Statistics:
Advisory İstatistiklerinde veritabanında kullanılan hafıza parçaları ile ilgili çeşitli tavsiye edilen hafıza miktarları ve hangi hafıza oranında artışların sisteme ne kadar etki edeceğini gösteren tablolar bulunur.
IO Stats:
IO Stats'da dosya okuma yazma işlemleriyle ilgili bilgiler bulunur. Hangi dosyalarını ne kadar okunduğu, hangi tablespace'lerde ne kadar okuma yapıldığı ve bunların oranlarr, hangi fonksiyonların okuma yazma işlemlerini nasıl ve ne kadar yaptığını gösterir. Bu şekilde hangi dosya veya tablespace'lerde okuma yazma yoğunluğu olduğunu keşfedebiliriz.
Top 5 Timed Events:
Bu bölümde bütün session'lar için bekleme istatistikleri ve ne için beklenildiği ölçülür. En çok karşılaşılan Wait Event'leri sıralanmıştır. En önemli bölümdür. Wait Class bölümünde sorunun neyle ilgili olduğunu görebiliriz. Waits sütünu kaç kere bekleme gerçekleştiğini göstermektedir. Time sütunu ise veritabanında toplam ne kada CPU zamanı geçirildiğini gösterir.
Buradaki wait olaylarına göre nerelerde sıkışıklık olduğu görülebilinir. Veritabanında çok fazla okumamı var, yoksa okumalar mı yavaş gerçekleşiyor bunları görebiliriz. Wait Class'larına bakarak hangi konularla ilgili sorunlar olduğu bulunabilinir.
İlk 5 problem arasında Latch Wait'leri varsa bu araştırılması gereken sorundur. Veritabanı genel olarak yavaş ise ve "CPU", "Db file sequential read", "Db file scattered read" bilgilerini içeriyorsa SQL'lerle ilgili bir sorun olma ihtimali vardır.
Db file scattered read: Bu wait event'i full table scans ve index fast full scan'leri gösterir. Bunu engellemek için index'lerin düzgün yaratılması ve tabloları sorgularken index scan'i tercih edecek şekilde düzenlenmiş sql'ler kullanılması gerekir. Full Table Scan'in gerçekleştiği tabloları görmek istersek Segment Statistics altında Segment By Physical Reads tablosuna bakabiliriz.
Db file sequential read: Sequential read yapıldığında, scattered read'in tersi olarak index'lerle okuma yapıldığını gösterir. Bu işlemin çok olması uygulamanın yüksek bir istek sayısına sahip olduğunu gösterebilir.
Buffer busy wait: Belli bir blok'a olan erişimin fazla olması veya birden çok kaynak tarafından kullanılması "buffer busy wait" olayına neden olur.
Enq:TX - row lock contention: Herhangi bir SQL'in bir blok'u etkilemesi, modifiye etmesi durumunda bu blok üzerinde bir kilit konur. Bu kilit olarak belirttiğimiz lock'lar, başka bir SQL'den gelen istek sonrasında o SQL'in bekletilmesine neden olurlar. Diğer SQL'in işini bitirene kadar o blok üzerinde kilit yerleştirmesi, bu wait event'i tetikler.
SQL İstatistikleri:
Awr raporları SQL'lerle ilgili bir sürü rapor sunmaktadır.
Bu raporlarda çeşitli kriterlere göre elde edilmiş istatistikli SQL'ler konulara ayrılmıştır. En fazla CPU tüketenler, en fazla okuma yapanlar, en fazla parse edilmiş olanlar gibi konular vardır. Hangi konuyu düzeltmek istiyorsak o konudaki SQL'lere gitmeliyiz. O konularda değişiklikler yaptıktan sonra tekrar istatistik toplayarak sorunla ilgili gözlemler yapabiliriz. Örneğin sorunumuz Parse edilmiş sql'ler ise bunların parse edilmesini engellemek için tek bir kere sorgulayıp memory'e yerleştirebilir ve hep aynı şekilde sorgulanmasını sağlayabiliriz. Başka bir örnek verirsek eğer SQL ordered by Elapsed Time konusuna göre ayrılmış SQL'leri inceleyip bu SQL'lerle ilgili gözlemler yapıp bunların niye çok sürdüğünü, bir lock yüzünden mi bu kadar uzun sürdüğünü veya çok fazla mı fiziksel okuma yaptığını inceleyebiliriz.
Buradaki başlıklardan SQL ordered by CPU Time başlığı da çok kullanılan başlıklardandır. Burada en fazla kaynak tüketen SQL ve PL\SQL'ler gösterilmektedir. Buradaki SQL ve PL\SQL'leri veritabanına etkilerini azaltmak içindüzenleyebiliriz.
Referans:
http://mallinenisrihari.blogspot.com.tr/2012/02/awr-report-analysing.html
http://www.bash-dba.com/2011/09/how-to-read-awr-reports-1.html
