Oracle Explain Plan Kullanımı
Merhabalar, bugün sizlere Oracle Explain Plan özelliğinden ve bu özelliği nasıl kullanabileceğimizden bahsedeceğim. Bildiğiniz gibi, hem uygulama katmanında hem de database seviyesinde sıklıkla sql sorguları yazıyoruz.
Bu sql sorgularının performansları, tüm uygulamamızın performansını etkileyen başlıca faktörlerden biri olarak karşımıza çıkıyor. Peki yazdığımız sorguların performanslı olup olmadığını nasıl tespit edebiliriz?
Bu sorunun cevabını, Oracle bize Explain Plan özelliği ile istatiksel olarak sağlıyor. Explain Plan fonksiyonu bir çok geliştirme aracının arayüzünde bulunuyor (Toad,PlSql Developer, Sql Developer vb.).
Ayrıca aşağıdaki komutları da kullanabiliriz:
Herhangi bir sorgu yazıp çalıştırmadan önce Oracle, çok kısa bir sürede, bu sorgunun hangi adımlar ile execute edileceğini tahmini olarak belirler ve bu adımları Explain Plan çıktısı olarak bize sunar.
Aşağıda basit bir sql sorgusu yazalım ve planını inceleyelim. Finans sektöründen bir örnek olarak, “bir şubedeki aktif kredi sözleşmelerine bağlı kefalet tutarlarının toplamı” bilgisini getiren sorguyu yazalım.
Name : Operasyon sırasında kullanılması öngörülen db objesidir.
Rows : Operasyonun bir kez gerçekleştirilmesiyle parent operasyona sağlanan tahmini satır sayısıdır.
Bytes : Operasyonun bir kez gerçekleştirilmesiyle parent operasyona sağlanan tahmini byte sayısıdır.(Satır x beklenen satır boyutu)
Cost : Operasyonun bir kez gerçekleştirilmesi için gereken tahmini CPU tüketimi.
Time : Operasyonun bir kez gerçekleştirilmesi için tahmini geçecek süre (saat:dakika:saniye)
Explain Planı yorumlarken en çok dikkat etmemiz gereken kısım, datasına ulaşmak istediğimiz tabloya nasıl eriştiğimizdir.
Bunu en performanslı şekilde yapabilmek için indexleri kullanırız. Yukarda sarı ile işaretlenen indexler, Oracle’ın bu sorgudaki tablolara erişirken kullanacağı indexler. Aşağıda bu indexlerin hangi kolonlar üzerinde tanımlandığına bakalım.
Görüldüğü gibi sql deki tabloların where koşullarında kullandığımız kolonlar indexlenmiş. Bu plana bakarak, tabloda var olan indexlerin kullanıldığı, performanslı bir sorgu olduğu yorumunu yapabiliriz.
Şimdi bu örneği biraz değiştirelim. Bu kez ihtiyacımız “sistem tarafından güncellenmiş sözleşmelere bağlı kefalet tutarlarının toplamı” olsun.
Görüldüğü gibi bu kez, tablolara full access söz konusu. Yani uygun bir index ile dataya erişemediği için, Oracle sorgu sonucunu alabilmek için tüm tabloya erişiyor.
Bu, performans açısından genelde kaçınmamız gereken bir durum. Çünkü bu erişim tipinde tablo segmentinin tüm rowları okunur, filtre varsa koşula uymayan değerler çıkarılır. Zaten bir önceki plan ile kıyasladığımızda, Cost değerleri arasında 4 kattan fazla bir fark görüyoruz. Yine tahmini Response Time değerinin, 1 dk lardan 4 dk civarına çıktığını görüyoruz. Eğer yukardaki gibi bir ihtiyacımız varsa agreements tablosundaki updated_by kolonuna index tanımlamayı değerlendirebiliriz.
Bu örneklere bakarak, “tüm sorgularımızda tablolara index aracılığı ile erişmek gerekir” gibi bir çıkarım yapmak da pek doğru olmaz. Eğer tablonun datası çok az ise Oracle’ın tabloya full erişmesi, index ile gitmesinden daha az maliyetli olabilir. Ya da index tanımladığımız alan yeteri kadar seçici olmayabilir. Bu durumda da Full Table Scan, indexe göre daha efektif olabilir. Bu noktada dikkat etmemiz gereken; eğer sorgu sonucunda getirilecek data tüm datanın %5 ve daha azı kadar ise index ile okumak mantıklıdır. Ancak eğer getirilecek data, tüm datanın büyük bir kısmı ise(seçici olmayan bir alan üzerinden filtreleme) bu kez de Full Table Scan daha avantajlıdır. Bizim örneğimizde de olduğu gibi, az miktarda olan bir dataya index olmadan erişmek için — özellikle erişilen tablolar büyük size’lı tablolar ise — Full Table Scan ciddi bir performans kaybına sebep olur.
Dolayısıyla bir sql planı üzerinde çalışırken, farklı alternatiflerin gerçek database üzerinden alınmış planlarını karşılaştırmalıyız. Çünkü explain plan bize net bir sonuç vermez, istatiksel olarak kıyaslama imkanı sağlar.
Bir sorgunun explain planı düzgünken kendiliğinden bozulabilir. Genelde bu durum, hiç değişiklik yapılmamış olmasına rağmen çalışma sürelerinde uzama yaşanması ya da yine değişiklik olmamasına göre uygulamada performans sorunları olarak karşımıza çıkabilir.
Aşağıda Oracle’ın explain planı oluşturmasını etkileyen faktörleri listeleyebiliriz:
* Tablo datasında büyük miktarda değişiklik(Insert, Update)
* Tabloya kolon ekleme/çıkarma
* Tabloya index ekleme ya da mevcut indexlerin güncellenmesi
* Oracle Database inin yönetimde kullanılan bir takım konfigürasyon parametrelerinin güncellenmesi
Yukarıdaki durumlardan biri yaşandığında daha önce performans sorunu olmayan sql’imizin planı değişebilir ve en doğru plan çalışmıyor olabilir. Bu gibi durumlarda veritabanı yöneticisi desteği ile beraber planı tekrar gözden geçirmekte fayda var.
Sonuç olarak, Explain Plan özelliği sql sorgularımızın performansını optimize edebilmek için bize büyük kolaylık sağlayan bir özellik. Pek tabii Oracle’ın sorgu çalıştırma mekanizması çok daha karmaşık ve yine Explain Plan içinde birçok farklı bilgi de mevcut.
Bu yazımızda temel seviyede Explain Plan outputu yorumlamaktan bahsettik, bir sonraki yazıda görüşmek üzere!
