PX Deq Credit: send blkd Wait Event Tuning

PX Deq Credit: send blkd Nedir?

Wait eventi yüksek miktardaki datalar üzerinde parallel işlemler çalışıtırıken ortaya çıkar. Normalde bu eventin gözükmesi doğaldı. Ancak bu eventteki bekleme süresi 2-3 saniyeden fazla ise parallel işlemin tune edilmesi gerekir.Bekleme süresini aşağıdaki sql den öğrenebilirsiniz.

 Beklemenin sebebi ise parallel işlemler sonuçları QC proseslere göndermesi  sırasında large pool 'ın dolmasından kaynaklanır. Bu durumda  LARGE_POOL_SIZE değerini ve PARALLEL_EXECUTION_MESSAGE_SIZE  değerini artırmanız gerekir. Bu işlem içinde uygun memory’ ye sahip olmanız gerekir.

Oracle Performans Troubleshooting 2 (Ash Reports)

ASH (Active Session History) aktif olan session bilgilerinin performans istatistiklerinin tutulduğu rapordur. Mevcut session bilgileri v$session ve v$session_wait_history eventlerinden gözlemlenebilir. Örneğin aşağıdaki sql veritabanında o an en fazla gözlemlenen eventleri gösterir.

   SELECT event, COUNT (*)

    FROM v$session_wait_history

GROUP BY event

ORDER BY 2 DESC

Ancak bu viewlar aktif sessionlara ait performans bilgilerini gözlemlemek, sorun tespit etmek ve çözüm geliştirmek için yeterli historic (geçmişe dönük) bilgiye sahip değildir. Sessionlar hakkındaki historic performans dataları için ASH raporları kullanılabilir. ASH aktif sessionlara ait saniyelik sample(örnek veri) elde ederek istatistiksel yorum yapılabililinmesini sağlayan very koleksiyonudur.  İşte bu yazımızda ASH raporlarını tanıtmaya çalışacak, ASH raporları ile neler yapılır ve ASH raporları nasıl yorumlanmalıdır anlatmaya çalışacağız.

Aktif Session Nedir?

ASH raporlarındaki aktif session ile v$session.state ‘ACTIVE’ değeri karıştırılmamalıdır. ASH raporlarında çıkan sessionlar Oracle RDBMS ‘e (Relational Database Management System) çağrı yollayan sessionlardır. Bu sessionlar hakkında toplanan datalar;

·         Parse, Execute ve Fetch Operasyonları

·         I/O işleminin tamamlanması için meydana gelen bekleme

·         Rac Sistemlerde remote instanceden mesaj yada buffer beklemeleri

·         Cpu üzerindeki beklemeler

·         Tekrarlanan sesionlar için beklememe

·         Paralel işlemler

·         Idle Wait (Boş bekleyen session) dışındaki digger tüm bekleme olayları’ dır.

Exadata Nasıl Monitor Edilir?

Oracle Veritabanlarında ki gibi exadata da monitor önemlidir. Bu yazımızda exadata monitoring için kullanılabilecek bazı toollar hakkında bahsedeceğiz. Kısa başlıklar hakkında suncak olursa exadata;

·         Exadata Cell Metric

·         Exadata Cell Alert

·         Exadata Active Request

·         Database Wait Events gibi yöntemlerle monitor edilebilir.

 Ancak öncelikle exadata da metric ölçümlere ve alarmlara dair yapıyı imcelemekte fayda var.

Exadata Metric Ve Alarm Yapısı

Metric; Cpu, Grid Disk, IORM (IO Resource Management), Cell Disk, Flash Cache gibi Exadata Cell bileşenleri hakkında önemli çalışma ve istatistiksel bilgilerdir. CELLSRV bu bilgileri peryodik olarak toplar ve MS’e (Management Service) iletir.MS de bu bilgileri memeory de tutar ve saat te bir historic olarak diske yazar. Şekil 1 de bu işleyişi temsil etmektedir.

Şekil 1: Exadata Metric ve Alarm Yapısı

    

Oracle Exadata Teknolojileri

                                

                Günümüzde data yönetiminin önem kazanması ile birlikte datanın en kısa zmaanda işlenmesi ve analiz edilmesi de önem kazandı. Artık şirketler geçmişe dönük verilerini analiz edip istatistik lerine göre pazarlama, üretim, kaynak temini gibi alanlarda bu istatistiklerden oluşan raporları kullanıyor ve daha doğru sonuçlara ulaşıyorlar. Bu yöntem eskiden de vardı ancak günümüz teknolojisi ile birlikte dakika lar seviyesinde bu raporları elde edebiliyor ve iç çalışma mekanizmalarını devreye alabiliyorlar. İşte bu kadar kısa sürede dev veri ambarlarını  ve veritabanlarını yönetmemizi sağlayan tenolojilerden en tanınmış olan Oracle Exadata dır.

                Şekil 1 de basitçe şematize edilen exadata’nın geleneksel veritabnına göre çok farklı ve güçlü bir sistematiği vardır. Bu yazımızda Exadata nedir? Neyi sağlar? Donnaım ve yazılım özellikleri? Veri işleme performansı ne kadar hızlıdır? gibi sorularına cevap olabilecek exadata tanıtım teknik ve kapasite tanıtımını yazacağız.

Şekil 1: Oracle Exadata Server

                Exadata iki temel bileşenden meydana gelir.

                1-Database Makinası (Oracle Exadata Database Machine)

                2-Depolama Makinası (Oracle Exadata Storage Machine)

                Bu iki bileşen arada infiniband adı verilen özel bir network ile birbirine bağlıdır. Bu network fiber optik kablolama teknolojisi ile üretilmiştir. Geleneksel veritabanlarında bu network 2 Gb/s  hızına sahipken, exadata network 20 Gb/s hzızına sahiptir. İki adet infinibanddan oluşan exadata network toplamda her bir yön için 40 Gb/s hızına kadar ulaşabilir.

Oracle Performance Troubleshooting 1 (AWR Reports)

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.

Oracle Data Guard Architecture

Oracle teknolojilerinin işletmeler tarafından en önemli kısımlarından biride Data Guard Teknolojisidir.  Çünkü data guard ile işletmeler datalarını daha sağlam bir zeminde korumaya almış, data kaybetme riskini neredeyse yok denebilecek seviyeye almış ve erişilebilirliği ise maximum seviyede tutumuş olurlar.Bu da işletmleri gerek müşterilerine karşı gerekse katma deer bakımında daha güvenilir göstermektedir.

 Öyleyse yazımızın devamında data guard nedir? Data guard mimarisi ve temel terminolojileri konusun da açıklamalar yapacağız ve mantıksal anlamda anlamay çalışacağız.Sonraki yazılarımızda da teknolojik anlamda derinlemesine inceleyecek ve pratik örnekler ve kurulum odelleri sunacağız.

Data Guard Konfigurasyon

DataGuard temel anlamda bir veritabanının başka bir yere anlık kopyalanması ve her hangi bir anda kopya veritabanının açılarak production olarak hizmet sunabilmesi denilebilir. Biz burada asıl veritabanına primary kopya veritabanına ise standby diyeceğiz. Bir Dataguard Konfigurasyonunda en az bir adet primary veritabanı olmalıdır.Yine data guard konfigürasyonunda  bir veya birden fazla standby veritabanı bulunabilir.Konfigurasyon içersinde primary  ve standby veritabanları arasındaki haberleşme Oracle NET ile sağlanır. Yani listener ve tns ler yardımıyla.

Ayrıca Belirtmekte fayda varki primary ve standby veritabanları farklı şehirlerde bile olabileceği gibi aynı makinada bile olabilir.

Standby veritabanı fiziksel olabileceği gibi mantıksalda olabilir. Ama temel bir data guard konfigürasyonu aşağıdaki gibi şematize edilebilir.

Şekil-1: Temel Data Guard Konfigurasyonu

Enqueue Waits & Locks Nedir Ve Nasıl Tune Edilir?

            Enqueue bir oracle shared memory (paylaşımlı memory) birimidir.enqueue ile database kaynaklarına gelen erişimler serileşitirlir.Bir proses Kaynağa erişirken, yapacağı işlemi bitirinceye kadar bu kaynağı lock konumunda tutar. Yani başka proseslerin erişmesine izin vermez. Gelen diğer proseslerde  bu lock durumunun bitmesini bekler.Lock oluşturan prosesin yaptığımı işleme görede lock tipi şekillenir. Kaynak locklı durumda iken gelen prosesler bir kuyruğa girerler. İşte bu tip locklara enqueue lock denir. Genel olarak gösterimi “enq: .. contention” gibidir.Biz bu yazımızda en yaygın görülen aşağıdaki enqueue tipleri detaylı inceleyeceğiz ve diğer enque tiplerini de tanımlayacağız.

            TX       à Transaction Locks

            TM      à DML Locks

            ST        à Space Management Enqueue

            Bekleme Parametreleri

            P1:Enqueue adı ve bekleyen prosesin beklediği mode.Aşağıdaki sql ile v$session_wait view den enque tipini öğrenebilirsiniz.

                SELECT sid,

              CHR (BITAND (p1, -16777216) / 16777215)

              || CHR (BITAND (p1, 16711680) / 65535)

                 "Name",

              (BITAND (p1, 65535)) "Mode"

             FROM v$session_wait

 WHERE event = 'enqueue';

            P2:Lock Kaynağını belirtir. V$lock tablosundaki ID1 kolonu ile aynıdır.v$lock.id1

            P3:Lock Kaynağını belirtir. V$lock tablosundaki ID2 kolonu ile aynıdır.v$lock.id2

Buffer Busy Wait Nedir ve Nasıl Tune Edilir?

Buffer Busy Wait event, bir session buffer cache içerisinde ki bir data bloğuna erişmek istediğinde, bu blok başka bir session tarafından kullanılıyorsa ortaya çıkan bir bekleme durumudur.  Buffer cache deki bahsedilen durumda olan data bloğu datafileden buffer cache alınıyor yada buffer cache içerisinde değiştiriliyor olabilir.

Buffer Busy wait eventi ile karıştırılmamalıdır.Buffer busy eventi Automatic Storage Management (ASM) kullanan veritabanlarında cache edilen metadaya erişimde yaşanan bekleme olayı olarak tarif edilir.

V$SESSION gibi viewlara baktığınızda buffer busy wait event’e ait parametreler görürsünüz.Şimdi bu parametrelerin ne olduğunu ve nasıl kullanılabileceğini inceleyelim.

Oracle RAC Servis Yönetimi

Belli bir gruba ait iş yükünü yönetmek yada database gelen bağlantıları yaptıkları işe göre guruplandırıp, bu guruplara benzer  karakteristiklerde kurallar tanımlamak için oracle veritabanında servisler kullanılır. Örneğin çalışan Batch joblarda  İnsan kaynakalrı  ile alakalı olanlar için HR adında bir servis tanımlayıp insan kaynakları uygulamalarından gelen bağlantıları HR servisi üğzerinden database ulaştırabilir, sonrasında hr servisnin kullandığı cpu yu kısıtlayabilir veya farklı bir bağlantı metodu tanımlayabilir yad istersek bir rac sisteminin sadece belli bir noduna bağlanmasını sağlayabiliriz.

                Bir servisi tüm node larda çalışacak şekilde oluşturursak buna UNIFORM servis denir. Yada tam Tersi olarak sadece tek bir makinada hizmet verecek şekilde oluşturursak buna da SINGLETON servise denir.

                Yine bir servisi öncelikli olarak rac1 instancede çalışacak ancak rac1 instance online olmadığında yada crash durumu olduğunda rac2 instacede çalışacak şekilde oluşturusak; bu durumda rac1 PREFERRED , rac2 ise AVAILABLE instanceler olmuş olur.

                Oracle Servisleri yukarıda tanıtmaya çalıştık. Şimdi bu servisler nedir, nasıl oluşturulur ve nasıl yönetilir  konularında açıklamalar ve örneklemeler yapmaya çalışacağız.

                Default Servisler

                Bir database de en fazla 115 servis uygulama için oluşturulabilir. SYS$BACKGROUND ve SYS$USERS ise oracle tarafından default oluşturulan , silinemeyen ve değiştirlemeyen servislerdir.Yani internal servislerdir diyebiliriz. Default servisler tüm rac nodelarında daima erişilebilir durumdadır yani avail dir.

                Servis oluşturma ve yönetme

                Servisleri Enterprise Managerda, Cluster Managed Database Services sayfasında oluşturabilir ve yönetebilirsiniz. Ayrıca srvctl de bu işlemi daha pratik ve hızlı yapabileceğim bir komut yönetcisidir. Burada daha çok srvctl ile devam edeceğiz.

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.