Merhaba Arkadaşlar,

Bu yazımda sizlere Oracle Veritabanlarında performans sorunlarına neden olan bazı wait eventleri anlatacağım. Veritabanını en çok yoran 5 wait eventi AWR raporlarından bulabilirsiniz. Ben bu yazıda AWR raporlarında en sık karşılaştığım Wait eventleri anlatacağım. AWR raporuyla ilgili merak ettiklerinizi bu linkteki yazımdan bulabilirsiniz.

AWR Wait Events

Db file sequential read: Bu event bir user ın Buffer cache üzerinden ardışık okuma (sequential read )yaptığı sırada bir Fiziksel I/O yapmaya çalışması ve bu işlemi beklemesi sonucu oluşur. Bu tip durumlar genellikle tablo üzerindeki verilere full table scan değilde index  kullanarak erişildiği durumlarda tekli blok (Single Block) okumaları sonucunda oluşur.

Bu events gerçekleşiyorsa olası muhtemel sebebleri Yanlış index kullanımı, İndexlerin fragmente olması yada belirli disklerde aşırı I/O trafiği oluşması şeklindedir. Bu sorunun çözümü olarak indexlerin doğru kullanılması ve fragmente olmuş indexler defragment edilmeli ve index maintenanceların sağlıklı bir şekilde tamamlandığı teyit edilmelidir.

AWR ve ADDM raporlarında çok sık görünen bu wait event ile karşılaştığımızda her zaman sorun var diyemeyiz. Ancak bu wait event cereyan ettiği durumda database de ‘Enqueue ’ ve ‘Latch Free’ olayları için çok fazla zaman harcanıyorsa bu durumda sistem mutlaka incelenmelidir.

db_file_sequential_read

Db file scattered read: Fiziksel olarak birbirine yakın (komşu) olmayan çoklu blokların (multiblock) memory e dağınık olarak alınması sırasında yada Buffer cache e full scan yapıldığı sırada ortaya çıkar. Yani Db file scattered read çoklu blokları okumak için I/O yapıldığı sırada hızlı full scan sırasında ortaya çıkan wait event diyebiliriz.

Bu wait eventden kaçınmak için küçük boyutlu tablolar cache e alınabilir.

Direct path read: Oracle Instance sı Datafile lardan asenkron olarak veri çektiğinde bu veriyi beklendiği şekilde SGA deki Buffer Cache alanina değilde PGA alanina koyduğu takdirde bu event oluşur.

Bu tip event genelde Sorting (Sıralama) işlemleri sırasında Temp Tablespace in yüksek kullanımı, Lob segmentlerin oluşumu sırasında ve Paralelde birden çok session Full tablescan ettiği durumlarda oluşur. Bu sorunu çözmek için Bellek alanı artırılmalı, parallel işler gerekmedikçe yapılmamalı bunun yanında okumalarda Lob segmentlere dikkat edilmelidir.

pfgrf210

DB CPU: Bu event kullanıcıların database üzerinde çalıştırmış olduğu query lerin CPU üzerinde geçen toplam zamanını ifade eder. Bu toplam zamanın içerisine Oracle ın Background processleri (SMON,PMON..) dahil değildir.

Bu değerin yüksek çıkması demek Oracle instance sının zamanın çoğunu CPU da harcaması demektir. Bu wait event i azaltmak için AWR raporundaki SQL ordered by CPU kısmındaki SQL ler TUNE edilmelidir.

 

Log file sync: Bu event Kullanıcıların başlatmış oldukları bir Transaction Commit ledikleri yada Rollback yaptıkları sırada LGWR process inin bekleme yapması sonucu kaybedilen zaman olarak bilinir.

Eğer bu wait event sürekli olarak görülüyorsa muhtemelen LGWR process inin I/O performans I kötüdür yada uygulama tarafından çok sık olarak Commit geliyordur. Bu problemin çözümü olarak gerekmedikçe çok fazla commit yapmamak ve Redo log file ların üzerinde bulunduğu diskin I/O performansını inceleyip gerekirse SSD disk gibi yüksek performanslı disk kullanmak şeklinde belirtebiliriz.

 

Enq: TX – row lock contention: Bu tip event bir kullanıcı session ının başka session tarafından tutulan bir satırı update etmeye çalışırken oluşur, bu bir uygulama problemidir. Normalde bir transaction ın bir row ile işi bittiği zaman commit yada rollback edip o row u serbest bırakması lazım serbest bırakmadığı durumlarda bu wait events ile çok sık karşılaşılır.

Bu problemin çözümü ise row u tutan session eğer aktif ise bu session ın commit etmesini sağlamak yok aktif değilse ilgili sessionı öldürüp işlemi rollback yapmaktır.

ARCH wait on SENDREQ: Bu wait event Dataguard kurulan Standby ve Disaster veritabanlarının Archiver Process ler tarafından arşivlerle beslenmesi ve local disklerede bu arşivlerin  yazılması esnasında geçen toplam zamandır.

Bu değerin yüksek çıkmasının temel sebebi Standby tarafına gönderilen arşivlerin networkten dolayı geç ulaşmasından dolayıdır. Bu sorunu çözmek için Network ü optimize etmek ve sqlnet.ora dosyasındaki DEFAULT_SDU_SIZE parametresini optimize bir değere (32767) çekmek gerekir.

 

Gc current block busy: Bu wait event Cluster olan veritabanlarının node ları arasında gerçekleşir. Bir transaction bir bloğu talep ettiği zaman o talep master instance a gider.Normalde  Bu talep cache fusion transfer yoluyla karşılanır.

Ancak bazı durumlarda bu blok transferi ilgili bloğun diğer instance tarafından tutulmasından dolayı yada ilgili transaction kayıtlarını redo loglara hemen yazılamadığı için ertelenir işte bu durumda bu wait event tetiklenir. Bu wait event Log Writer process inin tune edilmesiyle çözülebilir.

Gc cr block busy wait: Bu wait event de yukardaki gc current block busy wait event gibi çalışır. Tek fark olarak yukardaki event current mode da çalışırken bu wait event CR modunda çalışır. Bu wait event Log Writer process inin tune edilmesiyle çözülebilir.

Böylece bir yazının daha sonuna gelmiş bulunmaktayım bir sonraki yazıda görüşmek dileğiyle esen kalın..

Reklamlar

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s