TKPROF ile SQL uygulamalarının performans analizi

TKPROF, SQL izleme(trace) dosyalarını sırasıyla analiz etmek ve bu izleme dosyalarında yer alan bilgilerden okunabilir formda raporlar hazırlamak için işletim sistemi seviyesinde kullanılan bir Oracle yardımcı aracıdır.  TKPROF aracını kullananarak ayrıntıların çağrılması platformdan platforma değişiklik göstermesine rağmen, TKPROF tüm Oracle sürümlerince desteklenmektedir ve tüm Oracle veritabanı sürümlerinde aynı işleve sahiptir.

SQL izlemesi, bütün bir instance için veya bireysel oturumlar için etkinleştirilen veya devredışı bırakılan bir işlemdir. Bir oturum için SQL izlemesi etkinleştirildiğinde, oturumu tutan Oracle prosesi, tüm veritabanı çağrılarını ve operasyonları ile ilgili detaylı bilgileri bir izleme dosyasına yazar. Özel veritabanı olayları, bind variables(bağlaç değişkenler) gibi daha spesifik bilgilerin sırasıyla Oracle’ın izleme dosyasına yazılmasına sebep vermek içinde ayarlanabilir.  

SQL izlemesi, bireysel SQL komutlarındaki performans bilgilerini içerir. Her bir komut için aşağıdaki istatistikleri oluşturur:

• Çözümleme(parse), çalıştırma(execute) ve satır alıp getirme(fetch) sayıları
• CPU süresi ve tamamlama süresi
• Fiziksel okumalar ve mantıksal okumalar
• İşlem gören satır sayısı
• Library cache üzerindeki kayıplar(misses)
• Her bir çözümleme işlemindeki kullanıcı adı
• Her bir commit and rollback işlemi
• Her bir SQL komutu için bekleme olayı ve her bir izleme dosyası için özet bilgisi

Eğer SQL oturumunu için SQL komutunun imleci(cursor) kapanmışsa, SQL izlemesi aynı zamanda aşağıdakiler ile ilgilide satır kaynak bilgilerini sağlayacaktır.

• Her bir SQL komutunun güncel çalışma planını gösteren satır işlemleri
• Satır üzerindeki her bir işlem için tamamlama süresi, satır sayısı, ardışık okumalar(consistent reads) ve fiziksel yazma sayısı 

Bir instance veya oturum için SQL izlemesini etkinleştirmek münkün olmasına rağmen, bunların yerine DBMS_SESSION veya DBMS_MONITOR paketlerinin kullanılması tavsiye edilmektedir. Bir oturum veya instance için SQL izlemesi etkin olduğunda, kullanıcı oturumu veya instance oturumu içinde çalıştırılan tüm SQL komutlarına ait performans istatistikleri izleme dosyalarına yazılır. SQL izlemesinin kullanılması veritabanında şiddetli performans etkisi oluşturabilir ve aşırı CPU kullanımı, yetersiz disk alanı gibi artan sistem yüklerine sebebiyet verebilir.

Aslında, SQL izleme dosyaları text dosyaları olduğundan bir editor programla açıldığında rahatlıkla okunabilir formattadır, yani binary değildir. Ancak, aşırı oranda satırlar tekrarlı olmaktadır, çok ayrıntılıdır ve kısmen karışık formattadır. Örneğin, eğer bir uygulama bir imleç açıp bir seferde tek satır imlecinden 1,000 satır alıp getirirse, izleme dosyası içinde 1,000 tane farklı giriş olacaktır.  Tabii, çıplak gözle bunların ne olduğunu anlamak imkansız hale gelecektir. İşte bu sebeple, izleme dosyasını sırasıyla daha kolayca anlaşılabilecek bir formata dönüştürmek için, işletim sistemi komut satırından çağrılan bir araç olan, TKPROF kullanılır.

Indekslerin daha büyük bloğa sahip tablespace içerisine taşınması ve performanslarının durumu

Eğer bir indeks daha büyük blok büyüklüğündeki tablespace içinde yeniden inşa edilirse IFFS(Index Fast Full Scan) performansında iyi veya kötü yönde bir değişiklik olurmu?

• Rastgele giriş yapılan indeksler %70-75 aralığında PCT_USED değerine sahipken, bu indeksler, doldurulan farklı evreler içinde eş zamanlı olarak rastgele 50-50 blok bölünmesi meydana getirir. Bir indeksi yeniden insa ederek, %15 kadar indeks yoğunluğu artabilir ve böylece tüm indeks büyüklüğü azalabilir. Azalan blok geneli aynı zamanda indeks büyüklüğü ve blok büyüklüklerinin farklılıklarına bağlı olarak, indeksi de bir miktar azaltabilir. Fast Full Index Scan üyelik maliyetleri indeksin tüm büyüklüğü ile orantılı olduğundan, bir indeksi birleştirmek(defragmantation), en fazla potensiyel faydalar sunan erişim yolu olmaktadır. Bir indeksin büyüklüğünü azaltmak bu yüzden daha sonraki performansı etkiler.  Oysaki, mevcut blok büyüklüğünde indeksin yeniden inşası muhtemelen aynı benzer sonuca ulaşır(artı blok genel giderleri), indeksi sıkılaştırır ve potensiyel olarak daha iyi performans ile sonuçlanır. Buna karşın, indeks bloğu bir kez tekrardan bölünmeye başladımı, neticede bu indeks kendisinin önceki durumuna tekrar geri döner. İşte bu yüzden, daha büyük blok büyüklüğünün ötesinde, indeksin birleştirilmesi (defragmentation) genel bir performans iyileştirme yolu olmaktadır.

• İndeksi daha büyük bloğa sahip tablespace içinde saklayarak, bu indeksin ait olduğu tablodan farklı bir fiziksel veri dosyası içinde saklamak gerekmektedir. Bu veri dosyası performansı arttırmak için nispeten daha hızlı bir disk olmalı ve indeksler dışında başka dosyalar içermemelidir. Daha büyük blok büyüklüğünden ziyade, indeksin depolandığı yeni yerin fiziksel karakteristikleri esasında performansı etkiler. Eğer bir indeks aynı blok büyüklüğünde, daha büyük bloğa sahip indeksler ile aynı fiziksel karakteristiklere sahip yerde yeniden inşa edilirse, daha sonraki performans aynı şekilde artar(veya azalır).

Tabii bunun yanında pekçok muhtemel sebepler vardır, sistem daha büyük blok büyüklüğüne sahip indeksler kullanırken, daha az meşgul olmakla beraber indeksin daha büyük kısmı fiziksel olarak önbelleklenir.

Indeks Fast Full Scan, nadirende olsa bir ölçeklenebilirlik sorunudur. Bu noktada, aslında gerçekten kullandığımız uygulamaların yüzlerce büyüklükte eşzamanlı indeks fast full scan yapmasını istermiyiz? Uygulamayı bu gereksiz indeks fast full scan giderlerinden kurtarmak, indeksleri boş yere daha geniş bloğa sahip tablespace içine taşımaktan daha verimli bir yol olacaktır. Tabii bu başka bir yazıda tartışma konusu olur. 

Peki, esas bu yazının ana konusuna gelelim. Indeks Fast Full Scan işleminin performansı indeksin daha büyük bloğa sahip tablespace içine taşınması neticesinde değişirmi? Kesinlikle, değişir…Ancak, bu bahsedilen değişim, indeksin daha büyük bloğa sahip olması sonucunda çoklu blok(multiblock) okuma performansının geliştirilmiş olması anlamına gelmez.  

"db file sequential read" bekleme olayı üzerine detaylı bir inceleme

db file sequential read bekleme olayı, indekslere,rollback(veya undo) segmentlerine, rowid yoluyla erişilen tablolara, kontrol dosyalarına ve veri dosyası başlıklarına karşı tek-blok okuma işlemi gerçekleştiren işlemlerin SQL komutlarınca(hem kullanıcı hemde tekrarlamalı) başlatılır. Bu bekleme olayı sistem çapında beklemelere göre genellikle top 5 bekleme olayları içinde yer almaktadır.

Bu objeler için fiziksel I/O istekleri gayet normaldir, yani db file sequential read bekleme olayının veritabanındaki varlığı, illada veritabanı veya uygulama ile ilgili birşeylerin yanlış olduğu anlamına gelmez. Bir oturumun bu olay üstünde uzun zaman harcaması da her zaman kötü bir şey olmayabilir. Buna karşılık, bir oturum eğer kuyruğa ekleme(enqueue) veya “latch free” olayları için çok fazla zaman harcıyorsa, işte bu durum iyiye işaret olmaz. İşte bu iki olay tekli blok okuma konusunu çetrefilli bir duruma sokar. Peki ne zaman “db file sequential read” olayı sorun haline gelir? Aşırılık nasıl tanımlanır? Ne zaman ve nereye bir çizgi çekmelisiniz?  Aslında bu sorulara Oracle uzmanlarınında şu ana kadar kesin cevapları yoktur, hala araştırılır ve standart cevaplar bulunmamıştır hala ne yazıkki… Mesela, db file sequential read beklemesi proses yanıt süresinin büyük bir bölümünü temsil ediyorsa o zaman “aşırılık” kelimesi bir anlam kazanır. Diğer bir yol ise, bilimsel olmayan bir avam yaklaşımı takınarak, kullanıcılar bu bekleme olayından sıkıntı yaşayıp çığlık atana kadar beklemek olacaktır. Tabii bu durum profesyonel bir yaklaşım olmaz, hele hele proaktif olarak performans geliştirme iddiasında iseniz.

“db file sequential read” bekleme olayının üç parametresi vardır: file#, first block# ve block count. Bu bekleme olayı “User I/O” bekleme sınıfı altında yer almaktadır. db file sequential read bekleme olayı ile karşılaşıldığında aşağıdaki anahtar noktalara dikkat edilmesi gerekir.

• Bir Oracle prosesi, SGA içinde olmayan bloğa ihtiyaç duymakta olup bu veritabanı bloğunun diskten SGA alanına okunmasını beklemektedir.
• Bireysel oturumlarda bakılması gereken en önemli iki değer, TIME_WAITED ve AVERAGE_WAIT kolonları olacaktır.
• Dikkate değer db file sequential read bekleme olayı sıklıkla uygulama katmanından kaynaklanır. 

Aslında, V$SESSION_EVENT görünümünden “db file sequential read” bekleme olayında hangi oturumların yüksek TIME_WAITED değerine sahip olduğunu kolayca keşfedebiliriz. TIME_WAITED değeri LOGON_TIME değeri ile birlikte değerlendirilmeli ve daha kesin bir analiz için bu oturuma ait diğer boşta olmayan olaylar ile kıyaslanmalıdır.  Günler ve hatta haftalar boyunca açık olan oturumlarda db file sequential read olayı süresi dolgunca miktarda birikir.  Bu durumda, TIME_WAITED değeri sorun olmayabilir. Ayrıca, TIME_WAITED diğer boşta olmayan olaylar ile birlikte bir perspektife konduğunda, bu durum bizleri gafil avlanmaktan korur. Daha büyük önem taşıyan başka bekleme olayları bulunabilir. Aşağıdaki örneğe dayalı olarak, SID # 31 dikkati çekmeli ve diğerlerine göre daha kısa zamandan beri oturum açık olmasına rağmen yüksek bekleme süresinin nedeni incelenmelidir.

Oracle muteksler

Mutex(mutual exclusion-karşılıklı dışlama), kısa formu karşılıklı dışlamaktır. Mandallarla benzerlik gösteren mutex, SGA alanındaki paylaşımlı veri yapısına kontrollü erişim için kullanılan düşük seviyeli bir serileştirme mekanizmasıdır.  Serileştirme, bir objeyi aşağıdakilerden korumak için gereklidir:

• Ayrılırken birisi objeye eriştiğinde
• Obje okunurken başkası tarafından düzenlendiğinde
• Obje düzenlenirken başkası tarafından okunduğunda 

Muteks tarafından korunan her yapının kendine ait bir muteksi vardır(mesela, ebeveyn(parent) imlecin kendine ait bir muteksi vardır ve her bir yavru(child) imlecinde kendine ait muteksi vardır. Her bir yapı, her bir muteksin bu yapının değişik bir parçasını korumasıyla birden çok muteks tarafından korunabilmektedir. Şimdi bu paragrafı teker teker açalım.

Bir muteks, birden fazla yapıyı koruyabilir. Hem muteksler hemde mandallar serileştirme mekanizmaları olmasına rağmen, muteksler mandalların yapamadığı belirli özelliklere sahiptir.

• Daha küçük ve daha hızlı

Muteksler, mandallara iyi bir alternatiftir, çünkü daha küçük ve daha hızlı olmasından dolayı daha kolay alınırlar. Muteks alımı, mandal alımı ile kıyaslandığında daha az talimat kullanmaktadır.

• Daha düşük yanlış çekişme oranı

Mandal, genellikle birçok objeyi korumaktadır. Mandal, bir veya birden fazla “sıcak” objeyi korurken, mandalın kendisi, bu mandal tarafından korunan bir objeye erişirken serileştirme noktası meydana gelir. Bu olay, çekişmenin erişilmeye çalışılan hedef obje için olmasından ziyade, koruma mekanizması için(bu da mandaldır) olmasından dolayı "yanlış çekişme noktası" olarak adlandırılır. Mandalların aksine, muteksler ile her bir korunan yapı için muteks oluşturmak mümkündür.  Bu da demek olurki, her bir yapı kendine ait muteks tarafından korunabildiğinden, daha az yanlış çekişme meydana gelebilmektedir.

• Mandallar ve pinlerin yerine

Bir muteks, pekçok oturum tarafından, tüm oturumların S(Shared) modda muteksi temin etmesi ile eşzamanlı olarak başvurulanabilir. S modda mutekse başvuran toplam oturum sayısı başvuru miktarı ("ref count") olarak adlandırılır. Bir muteks için “ref count” sayısı muteksin kendisi içinde saklıdır. Ayrıca bir muteks, tek bir oturum tarafından X(Exclusive) modda da tutulabilir.

Mutekslerin ikili bir yapısı vardır. mandallar gibi serileştirme mekanizması olarak işlev yapabildiği gibi, bir objenin library cache içinde bütünlüğünü yitirmesini(aged out) engelleme gibi pin işlevide yapabilir. Örneğin; bir muteksin “ref count” miktarı, library cache pin olayı yerine geçmektedir. Her bir oturum bir imleci çalıştırırken, “library cache pin”i oluşturmak ve silmek yerine, “ref count” miktarını arttırır ve azaltır. Böylece “ref count” deyimi “n distinct pin” ile yer değiştirmiş olur.

"MEMORY_TARGET not supported on this system - ORA-00845" hata mesajı

Oracle 11g versiyonundan itibaren otomatik bellek yönetimi özelliği MEMORY_TARGET ve MEMORY_MAX_TARGET parametrelerince tanımlanmaktadır. Otomatik bellek yönetimi(AMM) hem SGA hemde PGA’yı yönetir. MEMORY_TARGET için bir değer girilir ve bellek tahsisi için maksimum olarak MEMORY_MAX_MEMORY parametresi sınırına kadar genişleyebilir.  MEMORY_TARGET değeri ayarlandığı zaman Oracle, SGA_TARGET ve PGA_AGGREGATE_TARGET içinde optimal işyüküne uygun değerler tanımlar. Oracle, SGA_TARGET ve PGA_AGGREGATE_TARGET değerini otomatik olarak kontrol ettiğinden, manuel olarak bu değerlerinin üstünde bir değer atanmasına gerek yoktur.

Linux tabanlı sistemlerde paylaşımlı bellek dosya sistemi /dev/shm üzerinde mount edilmelidir. MEMORY_MAX_TARGET değeri /dev/shm üzerinde mount edilen paylaşımlı bellekten daha az olmalıdır. Bu sebeple paylaşımlı bellek dosya sisteminin AMM’nin çalışması için yeterli büyüklükte olduğundan emin olunması gerekir.

Linux tabanlı sistemlerde paylaşımlı bellek dosya sistemini mount etmek için önce root hesabıyla oturum açılır.

Aşağıdaki örnekte, Linux sistemde 4,5GB bir paylaşımlı bellek dosya sistemi mount edilmektedir.

# umount tmpfs
# mount -t tmpfs shmfs -o size=4500m /dev/shm

Bu paylaşımlı bellek dosya sisteminin her açılışta kalıcı olarak aktif olması için /etc/fstab dosyasına aşağıdaki giriş eklenir.

shmfs /dev/shm tmpfs size=4500m 0 

ORA-00845 hatası genellikle MEMORY_MAX_TARGET değerinin, /dev/shm için tahsis edilen bellek toplamına eşit veya daha fazla olması durumunda meydana gelmektedir. Böyle durumda /dev/shm nin mount edildiğinden ve AMM nin çalışması için yeterli belleği bulundurduğundan emin olmak gerekmektedir. Ayrıca, MEMORY_MAX_TARGET ve MEMORY_TARGET parametrelerinde tanımlanan değerlerin /dev/shm üzerinde mount edilen miktardan az olduğundan emin olunması gerekir.

V$ACCESS görünümü kullanarak kilit tutan objelerin tespiti üzerine bir inceleme

Geçtiğimiz günlerde OTN’de bir soru ve cevabı dikkatimi çekti. Soru;”V$ACCESS görünümü kullanarak kilitli objelerin tespit edilmesi” ile ilgiliydi ve cevap veren gurulardan birisinin cevabı V$ACCESS görünümü ile kilitli objelerin görülemeyeceği şeklindeydi. V$ACCESS görünümünü daha önceden bende kilit tutan objelerin tespitinde kullanılır diye bildiğimden, bu cevap hakkında kafamda kuşkular oluştu. Aslında V$LOCKED_OBJECTS gibi bir görünüm daha fazla kilit hakkında bilgi tuttuğu için benimde tercihim olmasına rağmen, bu cevap ile ilgili bugün test ortamında bir deneme yaptım ve sonucunu bu yazı ile paylaşıyorum.

Oracle dökümanlarında V$ACCESS hakkında bulduğum bir paragraf;

"V$ACCESS görünümü, library cache üzerinde mevcut durumda uygulamaya girmiş kilitler hakkında bilgi vermektedir."

V$ACCESS görünümü oturumlar tarafından belirli instance için library cache seviyesinde hangi objelerin erişim erişim yaptığı ve kilit tuttuğu ile ilgili bilgi vermektedir. Bu görünüm kilit tutulup tutulmadığı ile ilgili bilgi içermez. Aşağıdaki örnekte test1 ve scott adlı 2 farklı oturumdan işlemler yapacağım ve V$ACCESS görünümü bilgilerini alacağım.

Oracle veritabanında yanıt süresini iyileştirme modeli - LOGOFF tetikleyicileri

Kullanıcılarınıza performansın ne anlama geldiğini sorduğunuzda muhtemelen hemen hemen hepsinin cevabı yaptıkları işlemlerin yanıt zamanı veya tamamlanma zamanı esnasında geçen süre olacaktır. Kullanıcılar bizleri performans problemleri için aradığında, işlemin yanıt süresi veya veri işlem ile ilgili yaşadıkları darboğazdan şikayet ederler. Bir kısım veritabanı hit ratio durumlarının kötü olduğu, aşırı önbellek tampon işlemleri olduğu, çok fazla fiziksel okuma meydana geldiği veya SQL komutlarının çok fazla CPU kullandığı gibi teknik sorunlardan şikayet etmezler elbette.

OWI(Oracle Bekleme Arayüzü), veritabanı yanıt sürelerini belirlemek için çok önemli bir rol oynamaktadır. OWI, bir oturumun açık olduğu süre boyunca karşılaştığı darboğazları belirlemek için yüzyüze kalınan bekleme olaylarını ve bu esnada geçen zamanı izler. Veritabanı yanıt süresi “hizmet süresi” ve “bekleme süresi” parametrelerini içermektedir.

Yanıt süresi = Hizmet Süresi + Bekleme Süresi

Yanıt süresi, bir prosesin CPU üzerinde harcadığı zamanın toplamıdır. Bekleme süresi ise, bir prosesin işleme devam etmeden önce çeşitli kaynakların uygun olması esnasında beklediği toplam süredir.  Bu formül, herhangi bir zamanda, bir prosesin ya CPU üzerinde bir isteği hizmete aktif olarak sunması yada CPU dışında hizmete sunması ve bekleme durumunda olması şeklinde bir kanıya dayanmaktadır. Bu durumda veritabanı yanıt süresini, hizmet süresini veya bekleme süresini veya her ikisini kısaltarak iyileştirebiliriz.

Oracle veritabanında kuyruğa ekleme(enqueue) olayları - Bölüm 2

Çeşitli tipte kuyruğa ekleme tipleri olmasından dolayı, bir kuyruğa ekleme bekleme olayı farklı sebeplerden meydana gelebilir. Yaygın sebepler ve bunlara karşı alınacak olan önlemler, farklı oturumlar tarafından çekişme yaşanan kuyruk ekleme tipine ve moduna göre değişmektedir. Oracle, her bir kuyruk ekleme tipi için X$KSQST yapısı içinde istek sayısı ve beklemelerin instance seviyesinde istatistiğini tutar.

select *
from   v$enqueue_stat
where  cum_wait_time > 0
order by inst_id, cum_wait_time;

   INST_ID EQ TOTAL_REQ# TOTAL_WAIT#  SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
---------- -- ---------- ----------- ---------- ----------- -------------
         1 SQ      66551         437      66551           0           498
         1 CU      64353         133      64353           0          1616
         1 HW     453067       18683     453067           0         11811
         1 CF     119748          76     119605         143         37842
         1 TX   22687836        9480   22687758          71        672435
         1 TC       3620         724       3620           0        679237
         1 TM   89822967          91   89817200           5       4056333

Yukardaki alınan sonuç ile kullanıcıların hangi tip ve modda kuyruğa ekleme beklemeleri ile yüzyüze kaldığını tespit edebilirsiniz. Can acıtan nokta, kullanıcılar bu beklemeler sebebiyle herhangi bir hata mesajı almazlar ve oturumları donar. Zaten, arandığınızda söylenende oturumların ansızın donduğu ve cevap vermediği şeklindedir.

Tüm kuyruğa eklemeler hakkında detaya girmeyeceğim, çünkü bir kısmının gereksiz olduğunu düşünüyorum. Ancak, en sık ve yaygın karşılaşılan kuyruğa ekleme beklemelerine detaylı olarak aşağıda odaklanacağım.

Mod 6 TX kuyruğa ekleme bekleme olayı

Mod 6 TX kuyruğa ekleme beklemesi(P1= 1415053318, P1RAW= 54580006) en yaygın karşılaşılan kuyruğa ekleme bekleme olayıdır(Oracle Database 10g itibariyle enq: TX—row lock contention.) Bu bekleme olayı satır seviyesinde çakışma olduğuna işaret eder. Bu beklemeye olayı, satırlar bir işlem için kilitlendiği zaman, bu esnada başka bir işlemin aynı satırlara güncelleme veya silme işlemi yapmaya çalışmasında meydana gelir. Bu genellikle program tabanlı bir hatadır. Bu durumda bekleyen oturum, bloklayan oturumun işlemi için işleme(commit) veya geri alma(rollback) yapana kadar bekleyecektir. Kilidi, bloklayan oturumun sonlandırılması dışında, serbest bırakacak başka bir yol yoktur. Tabii, eğer bu bloklayan oturum sonlandırılırsa(kill) yaptığı işlem geri alınacak ve bu işleme bağlı girişlerde ortadan kalkacaktır. Bu genelde istenmez. Aşağıdaki liste mod 6 TX kuyruğa ekleme beklemesi için bir örnektir.

ADDR     KADDR    SID TY    ID1    ID2 LMODE REQUEST CTIME BLOCK
-------- -------- --- -- ------ ------ ----- ------- ----- -----
A3950688 A395069C  10 TM 188154      0     3       0     3     0

A304E2A0 A304E2B0  10 TX  65585 147836     0       6     3     0
01AD23D4 01AD24A4  20 TX  65585 147836     6       0    10     1
A3950A28 A3950A3C  20 TM 188154      0     3       0    10     0

Oracle veritabanında kuyruğa ekleme(enqueue) olayları - Bölüm 1

Oracle 9i itibariyle “kuyruğa ekleme (enqueue)”  bekleme olayı parametrelerinin isimleri mod, ID1 ve ID2 dir. Oracle 10g itibariyle ise ilk parametre aynı kalmasına rağmen ikinci ve üçüncü parametreler temsil ettikleri kuyruğa ekleme işlemi için özel bilgileri vermektedir. Kuyruğa ekleme, bekleme olayına bağlı olarak yönetim, uygulama, konfigürasyon,uyumluluk ve diğer bekleme sınıfları altında toplanır. Kuyruğa ekleme bekleme olaylarının üstesiden gelirken aşağıdaki önemli noktaları göz önünde bulundurmanız gerekmektedir.

• Kuyruğa eklemeler, veritabanı nesnelerine uygulanan kilitlerdir.
• Kuyruğa eklemeler hareketlidir, uygulama tarafından başlatılır.
• Oracle oturumu belirli bir kuyruğa ekleme işlemi elde etmek için bekler. Kuyruğa ekleme ismi ve modu, P1 parametresi içinde kayıtlıdır. İlgili işlem için harekete geçme, rekabet olan kuyruk bekleme tipine bağlıdır.
• Oracle 10g itibariyle tüm kuyruğa eklemeler bağımsız bekleme olayı olarak listelenmektedir. 

Kuyruğa ekleme nedir?

Kuyruğa ekleme, kullanıldığı ortama bağlı olarak değişik anlamlar taşır. Fiil olarak kullanıldığında, bir  kuyruğa kilit yerleştirme hareketi olarak ifade edilir. Sıfat olarak kullanıldığında ise TX kuyruğa eklemesi gibi özel bir kilit olayını ifade eder.

Kuyruğa eklemeler, şema nesneleri, arkaplan görevleri ve redo mesaj dizileri(threads) gibi pekçok paylaşımlı kaynağa erişimi yöneten sofistike kilitleme mekanizmasıdır. Oracle, kuyruğa eklemeyi iki amaç için kullanmaktadır. Birincisi, kilit modları uyumlu olmadığında bir çok eşzamanlı oturumun aynı kaynağı paylaşmasını önlemek için kuyruğa eklemeler devreye girer. İkincisi, oturumların kilit modları uyumlu olduğunda aynı kaynağı paylaşmasına izin vermek için kullanılır. Bir oturum, bir nesnenin tümü veya bir kısmı için kilit talep ettiğinde ve talep edilen kilit modu başka bir oturum tarafından tutulan mod ile uyumlu olmadığında, talep eden oturum bu kilit isteğini kuyruğa sokar(yani kuyruğa ekleme) ve işlem sırasına göre hizmete girmesini bekler.  Bu olay, “kuyruğa ekleme beklemesi” olarak adlandırılır.  Kuyruğa ekleme beklemeleri  tampon(buffer) beklemeleri dışındaki çeşitlli lokal kilitler için olan beklemelerdir. 

Kuyruğa ekleme kaynağı nedir?

Kuyruğa ekleme kaynağı, kuyruğa ekleme kilidince etkilenen veritabanı kaynağıdır. Oracle, kuyruğa ekleme kaynaklarını X$KSQRS(kernel servisi kuyruğa ekleme kaynağı) veya V$RESOURCE görünümleri üzerinden görülebilen dahili dizin yapısını kullanarak yönetir.

select * from v$resource;

ADDR                TY     ID1       ID2
----------------    ---    -------   -------
C000000047BE4D40    TX     4980825   115058
C00000003FEB4A58    TM     6112      0
C00000004262E758    WL     1         25603
C00000004AD99538    TX     327726    202076
C00000004A5C6CE8    TM     507       0
C00000003FB7C4F8    TX     5898241   23053
C00000004BB3A968    DX     28        0
. . .

Oracle Latches

Latches  nedir??
Mandallar(latches), Oracle paylaşımlı bellek alanlarını(SGA) koruyan serileştirme mekanizmalarıdır. Basit anlamda mandallar iki prosesin aynı SGA alanını eşzamanlı güncellemelerinden ve muhtemelen bu olaya bağlı bozulmalardan korur. Mandallar, birden fazla kullanıcı prosesinin belirli bir zamanda aynı kod parçasını çalıştırmasını önlemek için kullanılmaktadır.

Oracle oturumları neredeyse tüm veritabanı işlemleri için SGA’dan okumak veya SGA’yı güncellemek ihtiyacı duyar.  Örneğin;

• Bir oturum diskten bloğu okurken, bu oturum önbellek tamponunda serbest bloğu değiştirir ve önbellek tampon LRU(en son kullanılan) zincirini düzeltir.
• Bir oturum SGA’dan bir blok okuduğunda, LRU zinciride değiştirilir. Yeni bir SQL komutu ayrıştırıldığında(parsed) SGA deki library cache’e eklenir.
• Bloklarda değişiklikler yapıldığı gibi, girişlerde redo tamponuna yerleştirilir. Veritabanı yazıcısı periyodik olarak kirli tamponları önbellekten diske yazar ve statülerini “kirli” den “temiz” e değiştirmek zorundadır.
• Redo log yazıcısı, girişleri redo tampondan redo log dosyalarına yazar.

Mandallara karşılık kuyruğa alma(enqueues)
Kuyruğa almalarda(enqueues), Oracle içindeki diğer bir kilitleme mekanizmasıdır. Kuyruğa alma  daha gelişmiş bir mekanizmadır ve birçok eşzamanlı prosesi, bilinen kaynakların değişik derecelerde paylaşımına olanak verir. Eşzamanlı kullanılabilen herhangi bir nesne kuyruğa almalarla korunabilir. Tablolarda değişik seviyelerde paylaşımlara izin verilir, örneğin iki proses paylaşımlı modda veya paylaşımlı güncelleme modunda bir tabloyu kilitleyebilir.Kuyruğa almanın bir farklılığı, işletim sistemi kilitleme mekanizması kullanılarak elde edilmesidir. Kuyruğa alma ile bir değerin kilit içinde saklamansına izin verilir. İşletim sistemi kilit yöneticisi, kilitlenmiş kaynakların izini tutar. Eğer bir proses, talep edilen modun uyumsuzluğu sebebiyle ve bir bekleme için kilit talep edildiğinde bu kilidi kabul edemezse, işletim sistemi bekleyen prosesi FIFO içinde servis edilen bekleme kuyruğuna koyar. Mandallar ve kuyruğa almaların arasındaki diğer bir fark ise, mandallarda kuyruğa almalardaki gibi sıralanmış kuyruk bekleyicileri yoktur. Mandal bekleyicileri uyanmak ve yeniden denemek için ya zamanlayıcıları yada  sadece çoklu işlemcilerde kullanılmak üzere devirleri kullanır.  Tüm bekleyicilerin zamanlayıcıya bağlı eşzamanlı yeniden denemesinden itibaren herhangi biri mandalı alabilir ve makul olarak en son alan olur.

"SQL*Net more data to client" paket cevap süresi optimizasyonu hakkında bir çalışma

Bu yazıda bu hafta başında başıma gelen, network paketlerinin gecikmesi neticesinde Oracle kullanıcıların işlemlerinde yaşağıdığı ani yavaşlamayı, sebebi ve sonuç analiz metodu ile birlikte açıklayacağım. Aslında olayın hikayesi, bazı kullanıcıların bu Salı günü aniden kullandıkları programın cevap süresinin ani olarak yavaşladığından şikayet etmesiyle başladı. Kullanılan program istemci/veritabanı yapısında bir programdır ve bu programı AR-GE bölümünde sınırlı sayıda kullanıcı kullanmaktadır. Kullanılan Oracle 10g veritabanı ise dedicated yapıda ayrı bir Linux sunucu üzerinde hizmet vermektedir.

İlk iş olarak toolkit’lerimi kullanarak paylaşımlı havuzdan aşırı önbellek kullanan işlem olup olmadığını tespit ettim, ancak gerek proses başına, gerekse SQL ve PL/SQL işlemi başına önbellek kullanımında bir anormallik yoktu. Ayrıca, SGA alanında ve belli başlı hit oranlarındada geçtiğimiz haftaya göre bir farklılık yoktu. Bunun ardından AWR raporunu hem geçen hafta Pazartesi-Salı günlerini kapsayacak şekilde, hemde bu hafta Pazartesi-Salı günlerini kapsayacak şekilde 2 sefer çalıştırdım.

Geçen hafta Pazartesi-Salı günlerini kapsayan AWR raporu;

Top User Events

Event	Event Class	% Activity	Avg Active Sessions
CPU + Wait for CPU	CPU	18.16	0.19
db file sequential read	User I/O	14.10	0.12
db file scattered read	User I/O	11.30	0.08
log file sync	Commit	4.03	0.03
enq: TX - row lock contention	Application	1.96	0.06

Top Background Events

Event	Event Class	% Activity	Avg Active Sessions
db file parallel write	System I/O	2.92	0.03
CPU + Wait for CPU	CPU	8.65	0.03
log file parallel write	System I/O	3.51	0.02
reliable message	Other	1.75	0.01

Bu hafta Pazartesi-Salı günlerini kapsayan AWR raporu:

Top User Events

Event	Event Class	% Activity	Avg Active Sessions
CPU + Wait for CPU	CPU	14.16	0.18
db file sequential read	User I/O	12.10	0.12
db file scattered read	User I/O	8.30	0.07
log file sync	Commit	3.17	0.02
enq: TX - row lock contention	Application	1.64	0.02

Top Background Events

Event	Event Class	% Activity	Avg Active Sessions
db file parallel write	System I/O	2.62	0.04
CPU + Wait for CPU	CPU	9.54	0.04
log file parallel write	System I/O	2.43	0.05
reliable message	Other	1.98	0.02

Yukardada görüldüğü üzere bu haftaki bekleme olayları, geçen hafta aynı periyoda nazaran yaklaşık %10 daha iyi. Peki o zaman sorun nerede???