Statement Processing and CBO Part1-Part 2

Merhaba arkadaşlar;

Bu yazıda sizlere Statement Processing and CBO hakkında bilgiler vermeye çalışacağım. Bu konuda çok iyi olduğum söylenemez :) Fakat yapmış olduğum bazı araştırmaları sizlerle paylaşmak istedim. Faydalı olmasını umarak başlayalım isterseniz.

Statement Processing deney olay esasında 4 temel kısımdan oluşur. Şimdi önce bu 4 temel olayın ne olduğunu söyleyeyim, daha sonra da bunların açıklamalarına geçeyim: Aslında önce isim sonra açıklama yapmak da olabilir; ama öncelikle ismleri belirtirsem daha yi olacağını düşündüğüm için böyle bir yöntem izledim. İsteyen arkadaşlar burayı atlayarak direkt isim açıklama bölümünden başlayabilirler. Tamam tamam farkındayım çok uzattım. Hadi başlayalım madem. :)


4 Temel Kısım

- Parsing
- Opitimization
- Row-source generation
- Execution.

Yukarıda vermiş olduğum kısımları şimdi sıra ile inceleyelim isterseniz.


1- Parsing

Şimdi Parsing denen olaya girmeden önce orada kullanacağım bazı kelimelerin anlamlarını sizlerle paylaşayım. Paylaşayım ki sonra bu neydi diye bana sormayın :) Aslına bakarsanız amacım anlatımın estetiğini korumak. Ondan en başta anlatıyorum. Yoksa zamanı geldiğinde de değinebilirdim. Neyse gelelim bu kelimlelere…


Shared pool check :

Kısaca Shared pool, SQL komutlarının memory de bulundukları yer olarak tanımlayabiliriz. Bu SQL cümlecikleri shared pool'un library cache denilen bölümünde hayatlarını sürdürür.

Biraz toparlayayım. Bildiğiniz ya da bilmediğiniz gibi Parse olayı biraz maliyetli bir iştir. Bizim de bu maliyeti olabildiğince aşağıya çekmemiz lazım. Bu amaç doğrultusunda bize hizmet eden şey. Shared pool oluyor. Şimdi bu adam bu kutsal hizmeti nasıl yapıyor bir de ona bakalım isterseniz. Parse edilen bir SQL komutu burada bir süre saklıyor. İlerleyen zamanda aynı komutu çalıştırmaya kalktığımızda bu komutun daha önce pars edildiğini fark ediyor ve tekrar pars edilmesinin önüne geçiyor. Ve bize ciddi kazançlar sağlıyor. Ya da bunun gibi bişey :)

Şimdi pars olayına geçelim. Pars olayı esasında şöyledir arkadaşlar :

SQL de yazdığımız cümleciklerin Oracle'ın anlayacağı dile çevrilmesi olayıdır. Yani esasında Oracle bizim SQL de yazdıklarımızın ne demek olduğunu anlamıyor. Anlayabilmek için bir şekilde kendi diline çevrilmesi gerekiyor. İşte bu çevrilme olayının yapıldığı duruma Parsing deniyor. Şimdi bu olay nasıl gerçekleşiyor ona bi bakalım. Bunu maddeler halinde sıralayalım.

* Öncelikle cümle parçalara ayrılıyor.

* Sonra ne tip bir operasyon olduğu belirleniyor.

* Daha sonra gerçekten geçerli ve anlamlı bir komut olup olmadığı tespit ediliyor. (syntactic ve semantic analizi yapılıyor)

* SQL cümleciğnin anlamlı olduğuna karar verilince sıra shared pool check'e geliyor. (Ne demek olduğunu yukarda anlattım :) ) Burada SQL cümleciği hem text, hem de işlev olarak tamamen aynı olup olmadığına dair bir kontrol gerçekleşir. Eğer SQL cümlemiz bu kontrolü geçemezse Optimization ve row source generation kısımlarına uğraması kendisine anlayacağı bir dille beyan edilir. Bu kısımlar ne demek mi? Biraz sabırlıolursanız anlatacam :)



2- Optimization

Burada da önce aşağıda kullanacağımız bir takım ifadeleri açıklamak istiyorum. Eee bu da benim tarzım. :) Herkesin yoğurt yiyişi farklı ne de olsa. :)


Rule Based Optimizer(RBO):

Bu vatandaş biraz kuralcı takılıyor. :) Kurala dayalı bir optimizer yani. Bu vatandaşın başlangıçta bir takım kuralları var. Bu kurallar çerçevesinde execution plan'ı belirliyor. Yalnız bu vatandaşın kuralları çok katı olduğundan ve bunun sonucunda bir takımı sıkıntıları olduğundan dolayı Oracle artık bunu kullanmıyor. Sıkıntıları ne diye soracak olursanız şu şekilde belirteyim. İndex i görünce vatandaş dayanamıyor ve duruyor. Be kardeşim ne duruyon. Tamam index kullanmak genel olarak avantajlı; fakat Her zaman index kullanmak avantajlı değil, bazen table da full scan yapmak daha makbul diyor kullanıcı ama dinlemiyor. Bunun üzerine Kullanıcı kızıyor ve sen sana söylediğimi yapsana diyor ama nafile. Adam dinlemiyor. Bunun üzerine kullanıcı vatandaşı büyük patron Oracle’a şikayet ediyor. Oracle da “Sen benim kullanıcımın dediğini yapmazsan sana ne hacet.” diyerek resti çekiyor. Ve bizim vatandaş böylece işinden oluyor. :)


Hint:

Hint i zor kullanmak ve “ben ne diyorsam o.” Demek ile eş anlamlı olarak görebiliriz. Zaten öyle de. Diyelim ki Oracle da birşeyler yapmak istiyoruz; fakat bazı prosedürler buna izin vermiyor. Ama o olayı mutlaka yaptırmamız gerekiyorsa o zaman devreye bizim hint giriyor ve konuya müdahale ediyor. Oracle başta direnir gibi yapıyor ama bizim eleman “ Kardeşim konuşma da sana söyleneni yap. Biz ne yaptığımızı biliyoruz. Senden ne isteniyorsa onu yap.” diyor. Tabi emir demiri keser hesabı sonuçta istediğimizi oracle a kabul ettiriyoruz. :) Yani oracle güzellikten anlamadığı zaman bazen böyle şeyler olması iyi oluyor dimi arkadaşlar :) Fakat yine de olayları şiddet kullanmadan halletmemiz önerildiği için çok zor durumlarda kalmadığımız sürece bu yöntemi kullanmazsak iyi olur. Çünkü burada her şeyden sen sorumlu oluyorsun. Ama diyorsanız ki hint olmadan bu işten çıkamam. O zaman yapacak bir şey yok. Yalanın bile mübah olduğu durumlar var.:)


Cost Based Optimizer(CBO):

Bu eleman tamamen maliyete dayalı bir mantık ile hareket eder. Adamın çalışma mantığı şu şekilde:

Tablo üzerinde daha önce toplanmış bazı istatistiklerden yararlanarak, istenen sorgu için maliyet çıkarır ve içlerinden en az maliyete sahip olan execution plan'ı seçer. Burada bu olay tamamen tahmin den ibarettir. Öyle ki aynı sorguyu farklı zamanlarda çalıştırdığında bile farklı sonuçlar verebilir. Yani eleman anlık düşünüyor ve ana göre hareket ediyor. :) Her ne kadar tahmin üzerinden iş yapsa bile istatistikleri sürekli güncel olduğundan dolayı yanılma payı çok azdır. Hal böyle olunca sözüne büyük ölçüde güvenilebilir. Fakat çok az yanıldığı her zaman doğru sonuçlar vereceği anlamına gelmez. Bu durumda da sorgu içerisinde hint vererek “Kardeşim ben ne yaptığımı biliyorum sen ne diyorsam onu yap.” diyip dediğimizi yaptırtabiliriz. O da hay hay sen nasıl istersen der ve dediğimizi yapar. Yani RBO gibi asilik yapmaz. :)

Bir de şöyle bir durum var. CBO süresi düşük olunca her zaman cevap süresi de kısa olacak diye bir kaide yok. Bazı durumlarda CBO süresi oldukça kısa olmasına rağmen cevap süresi oldukça uzun olabilir.

Şimdilik bu kadar açıklama yeter. Gelelim bizim optimizer dediğimiz elemanın ne iş yaptığına ve bunu nasıl yaptığına.

Optimization, bir SQL cümleciğinin nasıl çalışması gerektiğine karar veren elemandır. Sorgunun optimize edilmesini, en iyi şekilde nasıl çalışacağını belirleyen ve execution plan'ının oluşturulması olayıdır. Yukarda da değindiğim gibi şu anda sadece CBO kullanılıyor. RBO laf dinlemediği için artık Oracle ile çalışmıyor. :)

3- Row source generation:

Execution Plan'ın Oracle'ın anlayacağı şekle çevrilmesi ve özel data structure'ına dönüştürülmesidir. Bu aşama artık son aşama olup sorgu sonucunun kullanıcıya ulaştığı aşamadır.

4- Execution:

Bütün bu işlemlerden sonra execution gelir. Execution kesinlikle var olan bir adımdır. Execution asla ve asla es geçilemez. Çalıştırılan SQL bir DDL ise veya veriyi güncelleyen bir SQL ise ( update, insert delete ) execution adımı operasyonun son adımıdır.

Query ise (select) bir sonraki adım fetch adımıdır. Burada parse edilen komutlar kullanıcıya döner.

GÜN İLE İLGİLİ ÖNEMLİ NOKTALAR

"Eveeet. Nihayet bitti." dediğinizi duyar gibiyim. Ama daha bitmedi. Tonguç abi nin söylediği bazı önemli noktaları yukarıda yazmadım. Onlar önemli ve özel oldukları için ayrıca yazmakta fayda olacağını düşündüm ve burada onları yazmaya karar verdim. Onlar da bittikten sonra daha da bir şey yok. :)


* Pars için ayrılan süre olabildiğince kısa tutulması büyük uygulamalar için oldukça önemlidir.

* Bir tablodan az miktarda bilgiyi kullacaksak tablonun tamamını çekmemek gerekir.

* Az olan bilgiye ulaşmak için index kullanmak oldukça avantaj sağlarken tablonun tamamı için paralel kullanılmalıdır.

* Bir SQL in nasıl çalışması gerektiğine karar veren yapı OPTIMIZER’dir.

* Hint kullanmak çok fazla önerilmez. Fakat çok zor durumlarda kullanılması avantaj sağlayabilir.

* Bir sistemde ne kadar az kaynak (disk, bellek, network…vs ) kullanılırsa cevap süresi bir o kadar daha kısalır.

* Primary key indexlenen kolon bilgilerinin yanı sıra RowID leri de tutar.

* DDL(Data Definition Language) : "Data Dictionary" üzerinde değişikliğe sebep olan create, drop, alter gibi işlemlerdir.

* DML(Data Manipulation Language) : Veriye ulaşmak ya da değiştirmek amacıyla yapılan işlemlerdir.(Select, update,delete vs.)

* “Selectivity” ; bir satır kümesinin parçası anlamına gelir.Örneğin “all_objects” tablosunda “… where object_type = ‘TABLE’” koşulu için dönen satırlar “selectivity” kavramını karşılar. [0-1] arası değer alır.”0” ın anlamı satır kümesinden hiç satır dönmemesi, “1” de satır kümesindeki tüm satırların dönmesi olarak yorumlanır.

* Oracle da en fazla iki tablo join edilebilir.

* SGA(system Global Area), içersinde veri barındıran bir grup paylaşımlı bellek yapısı(shared memory structure) ve Oracle veritabanı “instance”’ı hakkında kontrol bilgileri taşıyan bellek
kısmıdır.



Not: Arkadaşlar ben ilk yazımı yazarken iki günü tek yazı halinde yazdım. Bir de baktımki ayı bir part olarak yazılacakmış o. :) Buradan kesip ayrı bir yazıymış gibi yazmak yerine durumu izah edeyim dedim. Part 1 ve Part 2 burada sizlere sunulmuş durumda.

GERÇEKTEN THE END :)