Merhaba, yazı dizinde stajımın 3. haftasına geçtik. (gerçekte şu anda 4. haftadayız) 16.07.2007 haftasına aslında Ersin damgasını vurdu diyebiliriz :)) Peş peşe pazartesi ve salı günü "Statement Processing and CBO" sunumları vardı. Gerçekten güzel sunumlardı, Ersin'in sunumlarına bayılıyorum zaten, anlatımı hoş oluyor :)
Bu makalede de Ersin'in sunumlarından bahsedeceğim, yani konumuz "Statement processing and CBO". Bu da önemli bir konu diyeceğim ama diyeceksiniz ki "bütün konulara önemli
diyorsun sende önemsiz konu yokmu"... Bende cevap veriyorum ki "önemsiz olsa hiç Tonguç eğitim programına koyar mıydı hiç" :)) Dolayısıyla artık bu konular önemli, neden önemli, çünkü Oracle'ı Oracle yapan şeyler bunlar geyiğine girmeyeceğim. Zaten CBO'nun ne olduğunu anlayınca Oracle'ın neden bu kadar değerli olduğunu bir kez daha anlıyor insan. CBO'nun ne olduğunu anlamak derken, nasıl çalıştığını anlamak imkansız zaten :) Jonathan Lewis
denen bir amca var, o kafayı yoruyor bu konulara senelerdir, ama o da hala yaza yaza bitiremediğine göre ve hala aklı başında olduğuna göre biz zaten sadece tanımını anlamakla yetiniriz. Ha, ben biraz daha ileri gidicem diyorsanız alın bir 10053 Trace, o zaman zaten "agugu" yapıp dudağınızla oynamaya ve kafanıza bir huni takıp etrafta dolaşmaya başlarsınız :))
Neyse gelelim konumuza biz, Ersin böylesine zor bir konuyu gerçekten güzel anlattı. Ha, birde perşembe günü bir workshop yapacaktı ama bilinmeyen nedenlerden dolayı :P nedense artık, sunumu iptal etmek zorunda kaldık :P Şaka bir yana, Ersin buna çok iyi hazırlanmıştı fakat gün kötü bir gündü, herşey ters gitti ve en sonunda Ersin örnekleri çalıştıracağı sunucuya da bağlanamayınca "arkadaşlar ben artık sizi tutmayayım" dedi ve perşembe günü maalesef örnekleri yapamadık. Ersin bize nasıl trace alınacağını falan uygulamalı olarak göstercekti, fakat çok önemli değil, çünkü bir hafta önce ben bloga güzel bir örnek koymuştum :)) Tkprof workshop diye. Hafta içinde kendim bile çok kullandım aynı kodları, zaten o zaman anladım blog'un ne olduğunu :))
10046 trace almak bir developer için o kadar da mühim değil, çünkü zaten bu onun işi olmayacak. Zaten çoğu durumda autotrace ve runstats de yeterli. Ayrıca 4. Hafta içinde performans sunumları olacak, ve bir çoğunu yine blog'dan yayınlayabilmeyi umuyorum. (En azından kendi yaptıklarımı yayınlayacağım kesin :) ) Trace ve performans değerlendirme konusundaki eksiklerimizi bir çok arkadaşım ile birlikte tamamlamış olacağız.
Biraz geyik modundayım, o yüzden uzun uzun yazıyorum. Kafamda da "CBO'nun neresinden başlasam şimdi" sorusu var. Kyte'ın kitabı güzel bir örnek bu konuda. Lewis'in kitabı ve sunumları var, oldukça etkili. Ersin'in sunumunu ve aldığım notları da açıp birşeyler yazmaya çalışacağım sizlere.
• Statement Processing 4 kısımdan oluşur: 1- Parsing, 2-
Opitimization, 3- Row-source generation, 4- Execution.
1- Parsing: SQL cümlelerinin bizim anlayıp yazdığımız syntax'ından, Oracle'ın anlayıp çalıştıracağı duruma getirilmesi olarak ifade edebiliriz. Öncelikle cümle parçalara ayrılır, sonra ne tip bir operasyon olduğu belirlenir, sonra syntactic
ve semantic analizi yapılır, yani gerçekten geçerli ve anlamlı bir komut olup olmadığı anlaşılır, sonra sırada shared pool check vardır. Shared pool check'in
üzerinde durmak lazım biraz. Shared pool, SQL komutlarının memory'de bulunduğu alandır. SGA'dadır. SQL cümleleri shared pool'un library cache denilen bölümünde yaşar. Shared pool'un espirisi kısaca şu: Parse edilen bir SQL komutu burada bir süre saklansın, yine aynı komut çalıştırılmaya kalktığında biz aynı komut olduğunu tesbit edelim ve dolayısıyla bir daha parse edilmesinden kurtulalım. Parse maliyetli bir iştir ve dolayısıyla bu bize büyük kazanç sağlar. Evet konumuza dönelim, SQL'in anlamlı olduğu anlaşılınca shared pool check'e geldi sıra. Bunun da adımları var. Statement check, semantic check, enviroment check gibi. Kısaca, SQL cümlesi hem text olarak hem de işlev olarak tamamen aynı olduğu konusunda kontrol edilir. Eğer bu kontrolü geçemezse, statement processing'in devam eden kısımlarına uğramak zorunda kalır SQL'imiz (Optimization ve row source generation)
2- Optimization: Burası aslında en çok üzerinde durulan konu 2 gün boyunca. Optimization, sorgunun optimize edilmesi, en iyi şekilde nasıl çalıştırılacağının tesbit edilmesi ve execution plan'ının oluşturulması işlevidir. Oracle'ımızda şu anda Cost Based Optimizer(CBO) var. Eskiden Rule Based Optimizer(RBO) vardı. Nedir bunlar peki? Eskiden başlayalım :)
Rule Based Optimizer(RBO): Kurala dayalı optimizer. Optimizer'ın daha önceden belirlenmiş, sabit, katı (:P) bir çok kuralı var. Bunlara göre execution plan'ı seçiyor. Örneğin, sorguda istenen tablo üzerindeki alanda index varsa kullan, falanca tip iki tablo join ediliyorsa şu şekilde et gibi. Öncelikler belirlenmiş ve nasıl belirlendiyse öyle bir şekilde işliyor. Peki bunun kötü yanı ne? Kötü yanı, en optimum execution plan'ın duruma göre değişebilmesi. Örneğin, aynı tablo, aynı veri, aynı index üzerinde aynı sorgu çalıştırılıyor olsa bile, bazen index kullanmak daha iyi olabilirken, sorgunun farklı bir değeri için full table scan daha hızlı çalışabilir. Bazı joinleri hash join yaparsın, bazılarını duruma göre "nested loops" yaparsın. Yani bu tarz dezavantajları vardı, bizim sabit fikirli RBO'muzun :))
Cost Based Optimizer(CBO): Maliyete dayalı optimizer tamamen dinamik çalışır. Mantığı ksıaca şöyledir: Tablo üzerinde daha önce toplanmış bazı istatistiklerden yararlanarak, istenen bir sorgu için bir çok ihtimali göz önünde bulundurarak her kombinasyon için ayrı birer maliyet *tahmin* eder, ve içlerinden en az maliyete sahip olan execution plan'ı seçer. CBO, aynı sorgunun farklı zamanalrda çalıştırılması için bile farklı execution plan'ler çıkarabilir. Tamamen o anki olaya dayalı olarak, istatistikler ışığında anlık execution plan üretir. İstatistikleri yeterince güncelse(ki genelde öyledir çünkü Oracle bunalrı da çaktırmadan otomatik toplar) genellikle CBO yanılmaz, en iyi plan'ı üretir. Çok nadiren yanıldığı olabilir tabi, o zaman da direk optimizer'a sorgu içinde hint vererek o şekilde çalışmasına zorlayabiliriz. Ama bu optimizer'ı baltalamak olur ki, ne yaptığımızı, şu anda nasıl bir veriye sahip olduğumuzu, ilerde nasıl bir veriye sahip olabileceğimizi, olayın içindeki tüm obje ve faktörleri(indexler, join edilecek tablolar, içindeki veriler vs.) optimizer'dan iyi biliyor olmamız lazım.
RBO Oracle'ın çok eski versiyonlarında vardı. Daha sonra 8i ile birlikte CBO'yu geliştirdiler RBO'yu geliştirmeyi bıraktılar. Default çalışan optimizer CBO'dur. Halen geriye dönük uyumluluk açısında RBO varolmasına karşın artık RBO kullanılması tavsiye edilmiyor.
3- Row source generation: Execution Plan'ın Oracle'ın anlayacağı şekile çevrilmesi ve özel data structure'ına dönüştürülmesi işlevidir.
4- Execution: Bütün bu işlemlerden sonra execution gelir. Execution kesinlikle varolan bir adımdır. Parsing'in bir kısmı ve Optimization az önce belirttiğimiz şartlarla es geçilebilir fakat execution 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.
• Statement Processing konusunun espirisi, aslında CBO ile tanışmak ve parsing olayının nasıl elemine edilebileceğini anlamaktan ibaret. Bind variable'ların kullanılması bu noktada önemli.
• İkinci gün (17.07.2007) Ersin CBO konusunun ayrıntılarından ve Explain Plan'dan bahsetti biraz. Maliyetin ne olduğu konusu var önce: Maliyet, aslıdna bir çok faktörün bulunduğu matematiksel bir formül. Tahmin ettiği değerleri yerine koyuyor CBO ve tek bir rakam olarak maliyeti hesaplıyor. Sonra bu maliyetleri kıyaslayarak en iyisine ulaşıyor.
• Explain Plan, execution plan'in biraz değişik, bizim anlayabileceğimiz şekilde şekillendirilmiş halidir diyebiliriz. Explain Plan içten dışa doğru okunur. Soldan en fazla boşluğa(girintiye) sahip olan en içtedir. İç levelde olanlar önce çalıştırılır. Aynı levelde olanların ise hangi sırada çalıştırılacağı kesin değildir, zaten bu pek birşey de ifade etmez maliyet olarak. Her bir satırda yazan operasyonların ne olduğu konusunda sunumda bir miktar bilgi var, ek linkler de koyacağım links kısmına, onları uzun uzadıya burda yazmayacağım.
• Son olarak anlatılan HINT'ler var. Hint'lerin amacından yukarıda biraz bahsetmiştim. CBO'ya müdahale etmek için kullanılıyorlar. CBO'ya verilen komut gibi düşünebilirsiniz. Siz hint oalrak belirtirseniz CBO belirttiğiniz şekilde oluşturur execution plan'ı. Hint'lerle kaynakalrı da linkler kısmında belirttim, bütün hint'leri, açıklamalarını ve örneklerini bulabilirsiniz.
Ersin'in bu muhteşem iki sunumunu, çalıştırdığı demo'ları, Ertürk'ün geçen sene yapmış olduğu CBO sunumunu ve Hakkı abinin geçen sene yapmış olduğu Statement Processing sunumunu içeren rar dosyasını buradan indirebilirsiniz.
Sanırım Turkcell'de staj programına dahil olmadığı halde bu yazı dizisi takip edenler, ek kaynakalrla birlikte eğer incelemeye devam ederlerse bu sunumlara katılanlardan çok daha fazla bilgi sahibi olabilirler. Herhangi bir soru olursa bana  adresinden mail atabilirsiniz, cevabına mutlaka ulaşıp yanıtlamaya çalışırım.
Herkese iyi çalışmalar.
|
Set as Homepage
Add to Favourites
Recommend
Contact
