Blog ' da Ara

Loading

10 Nisan 2012

Rac Database Wait Events

                                                                
Bu yazımızda RAC veritabanını tüne ederken kullanabileceğimiz tool lardan, Rac instance Tuning nasıl yapılır, Rac veritabanında sıkça görülen wait eventlerden , AWr ve ADDM Rac veritabanı için yorumlama konularında paylaşımda bulunacağız.

Sekil 1: Cpu ve Wait time arasındaki ilişki
       
Cpu Time ve Wait Time arasındaki İlişki
Öncelikle genel mantık olarak belirtelimki : Cpu Time ve Wait time değerlerini oranladığımızda eğer CPU Time baskın çıkıyorsa Cpu maliyeti yüksek sql lerin olduğunuz ve bu sqllerin tüne edilmesi gerektiğini çıkarabiliriz.Bu sqlleri de gv$sql view ‘ında Cpu_time kolonuna göre order by yaparak bulabiliriz. Eğer tüne edilebilecek sql yoksa yada sql tuning ile yeterli performans kazanımı elde edemediysek bu durumda CPU eklemek faydalı olacaktır. Eğer Wait Time baskın çıkıyorsa bu durumda Cpu eklemenin hiçbir faydası olmayacaktır.Wait eventleri gözlemlemeli ve performans darboğazlarda geliştirme yapmalıyız sonucunu çıkarabiliriz.Şekil 1 e de bakıldığında bu yorumları çıkarabilirsiniz.
                Rac veritabanını tüne ederken her zmana çıkış noktamız her bir instanceyi tek başına çalışıyormuş gibi tüne etmeye yönelmektir. Sonrasında tabiki rac veritabanlarında ardaki intercnnect trafik hesaba katılmalı ve Rac veritabanı tüne edilirken istatiktiklerin yada tuning tollarının RAC yapısına oluştuğu ve buna göre yorumlanması gerektiği düşünülmelidir.


                Instance Recovery And RAC
                Instance Eviction yani crash durumlarında instance nin tekrar başlatılması ve crash recover edilmesi zamanı FAST_START_MTTR_TARGET parametresine bağlıdır. Bu parametre 0-3600 sn arasında bir değere set edilebilir. Mesela bu paramtre 1800 ise instance 30 dk da recover edilecek ve başlayacak demektir.Ancak I/O yük miktarıda 3600 değerine göre çok daha yoğun olacaktır. Bundan dolayı I/O sistemlerinizin de desteklediği bir değere set etmek mantıklı olandır. FAST_START_MTTR_TARGET parametresi “ alter system set FAST_START_MTTR_TARGET=1800 scope=both;” şeklinde set edilebilir.Ancak bu paramtre her node için farklı olabilir. Yani 1. Nod için 1800 iken 2. Node için 900 olabilir. Bu 2. Nodun 15 dk da instance recover yapacağını ancak 1. Nodun 30 dk .da instance recover edeceğini gösterir.
Şekil 2 : Instance Recovery And RAC          

                Daha hızlı instance recover işlemi için RECOVERY_PARALELISM parametresi set edilmelidir. Bu paramternin değerini aşağıdaki gibi görebilirsiniz.
                SQL> Show parameter recovery_paralelism;
                Eğer sonuç 0 ise paralel instance recovery set edilmemeiştir. 1 ise paralel instance recover devrede demektir.
                Eğer sonuç 1 ise PARALLEL_MIN_SERVERS parametresini paralel değeri için set edebilirsiniz. Bu parametre  CPU_COUNT -1 değerine set edilebilir.Yine CPU_COUNT parametresini aşağıdaki gibi görebilirsiniz.
                SQL> Show parameter cpu_count;
                Ayrıca instance recover işlemini geciktiren durumlardan biride instance failure olmadan önce çalışan transaction ların roll_back edilmesidir. Bu işlemin paralel yapılması içinde FAST_START_PARALLEL_ROLLBACK parametresini set edebilirsiniz.
FALSE:  Paralel transaction rollback yapılmayacağı anlamına gelir.
HI:          4*CPU_COUNT derecesinde paralel transaction  rollback yapılacağını belirtir.
LOW:     2*CPU_COUNT derecesinde paralel transaction rollback yapılacağını belirtir.

Son olarak instance recovery buffer_cache in %50 sini kullanır.Alert loğu da kontrol ederek bu değerin yeterli olup olmadığını kontrol edip ve eğer imkanınız varsa buffer_cache değerini artırabilirsiniz.

Oracle RAC Veritabanında Cache Fusion Etkisi,
Global Cache olarak bilinen memory birimi RAC veritabanlarında kullanılan ve tüm rac node larının kullandığı cache memory birimidir. Global cache deki data bloklarına erişimin etkisini ve cache deki tutarlılığın yönetimi iki şekilde anlamlandırılabilir.
Global Cache Servise istatistikleri :gc currunt block received,gc cr block received..
Global Cache Service Wait Events:gc current block 3-way, gc cr grant 2-way..
Cache Fusion Teknolojisi aslında RAC birimleri arasındaki çok hızlı haberleşmenin sağlandığı adeta bu birimleri senkron gösteren teknolojidir. Cache Fusion cevap süresi ise birbirleri arasındaki mesjlaşma süresi ve birbirleri arasındaki işlem olanağı sağlayan fiziksel birimlerdir. Bu fiziksel birimlere interconnect de denir.IPC protokol ve GCS protokol interconnect birimleridir.Interconnect disk I/O faktörlerinden ekilenmez ve aynı şekilde disk I/O cevap sürelerini de etkilemez.Yani cluster sistemlerdeki disk I/O performansı ile single instance daki disk I/O performansı farklı değildir.
Şekil 3 de RAC sistemlerdeki bazı eventlerin ortalam olamsı gereken bekleme süreleri verilmişti.Bu aralıkların dışında değerler görüyorsanız sisteminizi incelemeniz gerekir.

Şekil3: RAC Oratalama bekleme değerleri                        
AWR raporlarındaRAC istatistiklerinin tutulduğu tabloyu incelip eğer önemli bir artış varsa RAC tuning yapmanız gerekir. Aynı istatiskleri V$GES_STATISTICS view danda görebilirsiniz.

RAC Wait Event
Wait eventler, sessionların neden beklediklerini analiz etmede kullanılır.
Wait event aslında sorun değil, oluşmuş bir sorun sonucunda oluşan beklemenin adreslenmesinde kullanılan tanımdır. “Hangi session ne iş yaparken, hangi eventi bekliyor” sorusunun ve “Hangi session beklem eventini ortaya çıkaracak iş yapıyor ve hangi kaynağı tutarak yada aşırı yük oluşturarak bekletiyor.” sorusunun cevapları Performans anaklizi yapmada ilk adımdır. Bu analizler için AWR, ADDM gibi toollar kullanılabileceği gibi aşağıdaki view larda incelenebilir.
·         v$system_wait à Eventler için toplam bekleme.
·         v$session_event à Sessionlara ait beklemeler ve eventler
·         v$session_wait_class à Sessionlara ait event kategorileri ve beklemeler.
·         v$active_session_history à Aktif sessionlara ait son bilgiler.Her saniye snap alınır.
·         wrh$active_session_histor à Aktif sessionlara ait son bilgiler. V$active_session_history den en buyuk farkı 10 sn de bir snap alınıyor olması ve db restart olsa ile silinmemesidir.         
·         v$session_wait_history à Her bir aktif session için son 10 event.
·         v$session_wait à Sessionlara ait beklemeler.
·         v$sqlstats à Sql query lere ait beklemeler.Cluster_wait_time kolonu kullanılarak interconnect beklemeleri incelenebilir.

Global Cache Wait Event
               
                Aşağıdaki şekilde global cache wait eventler gösterilmiştir. Şekil 4 deki wait eventleri sonrasında açıklamaya çalışacağız.
               
Şekil 4 : Global cache wait events


                Global cache tüm rac nodelarının ortak kullandığı cache memory parçasıdır. Cluster içerisindeki senkronizasyon işlemlerinde kullanılır. Şekilde ve aşağıda kullanacağımız kısaltmaların anlamları ise şöyledir.
                gc: global cache                                cr:consistent reads

                gc current/cr request:   Hali hazırda işlenen memory birimi yada global cache deki uygun bir blok için yapılan talep ile alakalıdır. Talep gerçekleşene kadar yer tutar.
                gc current/cr block 2/3-way : Mevcut yada uygun olan bloklar için oluşturulan erişim taleplerinin 2 yada 3 network hop dan sonra karşılandığını gösterir. Network hop; datanın network üzerinden bir cihazdan diğerine taşınması işlemi yani bir network işlemidir.ping atarak hop count hesaplanabilir. Mesela bizim bilgisayarımıza internet üzerinden bir data girerken ISP, Switch,router vs. 16 cihaz geçiliyorsa 16 network hop yapmış demektir.
gc current/cr block busy: Mevcut yada uygun olan bir cache bloğu erişilmiştir ancak LMS proses tarafından yapılacak gönderme işlemi bazı sebeplerden dolayı erteleniyordur.
gc current/cr grant 2-way:Yetki tanımlanan block eğer local cache üzerinde değilse talep edilen instance üzerinde bir diskten okuma başlatılır.
                gc current grant busy: Yetki tanımlanan block eğer o an için başka bir proses tarafından tutuluyorsa grant mesajı alınsa dahi anlık olarak işlem elde edilmemiştir.
                gc current/cr block/grant congested: Block okumaları yada yetki gibi işlemlerde eğer internal kuyruklar 1 ms den fazla gecikme yaşıyorsa tıkanma anlamında congested wait eventi alınır.
                gc current/cr failure/retry: bir blok talebinin fail durumu dur.
                gc buffer busy: Global memory ye erişim zamanı, global memory i işarteleme zamanından daha az ise bu durumda müsait memory beklem durumu oluşur.

                Yukarıda RAC veritabanlarına ait bekleme leri kısaca tanımlamaya çalıştık. Şimdi en sık görülenleri açıklamaya ve çözüm önerileri sunmaya çalışalım.

                2-way block request: Şekil 5 de ki proses aslında tam olarak 2-way block request açıklamaya uygundur. Sga1 yani birinci noda instance sga2 den bir bloğun okunması için direct request gönderir.Sga2 bu request’i yani direk okuma isteğini aldığında , istenen bloğu göndermeden önce LGWR prosesini tetkiler ki eğer cache edilen block son hali ile redo dosyalarını yazılsın.Aynı şekilde LMS proseside istenen bloğu transfer etmeden önce LGWR den flush işleminin bittiğine dair yanıt bekler.Sonrasında block sga1 ‘e transfer edilir. ve wait event bitmiş olur. 2 –way block request de harcanan süre işte bu işlmelerin tamamında harcanın süredir.

Şekil 5 : 2 –way block request
                         

3-way blocl request: Şekil 6 da 3-way block request gösterilmiştir. Aslında 2-way dan farkı olayın 2 de b fazla noda üzerinde gerçekleşiyor olmasıdır.Request gönderilen noda bu requesti 3. Noda forward eder. Ve böylece işleme forward zamanıda eklenir ve bekleme süresi artabilir.
 Şekil 6: 3–way block request 
      

                RAC  Veritabanında Genel Tuning Kuralları
                1-Full Tablo Taramalarını Engellemek: Full scanleri engellemek GCS (Global Cache Service) isteklerini en aza indirmek için önemlidir. Çünkü bir quey tablolara full gidiyorsa kendi makinada cache biriminde de bulamadığı veriyi diğer makinlarda yani global cache de arayacaktır.
                2-Automatic Segment Space Management instancenin arasındaki tablo bloklarına bağlı senkronizasyonu sağlayacaktır.
                3-Sequence cashlerini artırmak önemli bir performans kazancı sağlayacaktır eğere insertlerin yoğun olduğu bir RAC db de tuning yapıyorsak.
                4-Parttitioning Buffer kullanımını azaltacağı için buffer busy wait contentionlarıda azaltacaktır.
                5-RAC Veritabanlarında library cache ve row cache operasyonları global olarak korine edilir.Dolayısıyla Ne kadar fazla pars varsa o kadar interconnect traffic var demektir.Bundan dolayı hard parse sayısının azaltılması gerekir.
                6-Kullanılmayan indexlerin silinmesi gerekir.Çünkü indexler dml işlemlerini yavaşlatırlar.Eğere okuma işlemlerinde performans artırıcı etki göstermiyorsa insert ,delete ve update işlmelerini yavaşlatacak buda inter-instance contentionlara sebep olabilecekir.
                7-Interconnect trafic herzamanprivate network üzerinden sağlanmalıdır.


                                                                                                              Özcan YILDIRIM

1 yorum:

"Sorularınız ve Eleştirileriniz Değerlidir"