Adaptive Cursor Sharing

       Bir onceki baslikta gordugumuz bind variable ve cursor sharing yani benzer SQL statement`a sahip SQL`lerin ayni exectuion plani kullanmalarini gormustuk. Ancak bununda dezavantajlarinin oldugunu soylemek mumkun. Mesala benzer olan uc tane SQL ifademiz var, ve cursor sharing oluyorsa ilk calisan SQL icin olusturulan execution plan diger SQL`ler icinde calisacak ve eger ilk calisan SQL hard parse veya FTS(Full Table Scan) yapiyorsa ondan sonra gelen SQL`ler icinde ayni durum olacaktir. Ama diger SQL`ler FTS yapmiyor olabilir. Bu durumda cursor sharing avantajli durumdan cikacaktir.
Oracle 11g surumunden sonra bu durum icinde bir cozum olusturulmustur oracle bu sorunu Adaptive Cursor Sharing ile asabilmektedir.

Adaptive Cursor Sharing : Cost Based Optimizer (CBO)’ın execution planları oluştururken bir statement için daha fazla execution plan tutmasına olanak sağlayan yapı olarak ön plana çıkmaktadır. Bir statement için birden fazla execution planı tutuyor olmak daha önceki versiyonlardan farklı olarak ilk hard parse olan statement’ın planını daha sonra tekrar tekrar farklı parametrelerle çalışan aynı statementlarıda kullanmak zorunda bırakmamak anlamınada geliyor olacaktır. Bind variable kavramındaki execution planları ortak kullandırma mantığının aynı plana sahip olmaması gereken 2 cümle için ortak plan kullandırdığı zaman ne kadar maliyetli (costu yüksek) olduğunu görebiliriz. Mesala asagidaki SQL`i degerlendirelim.

                select * from emps where salary= :sal;

      Bu SQL icin, mesala :sal degeri once 10000 daha sonrada 2000 olarak set edilsin. 10000 olarak set edildiginde 1 tane sonuc geliyor(yani selectiviysi yuksek) ve execution plani optimizer uzerinde INDEX RANGE olarak calissin ve index uzerinden veriyi getiriyor olsun. Ama :sal degeri 2000 olarak set ettigimizde ise tablodaki verilerin % 40 `I geliyor. Bu durumda hatirlayalim optimizer bir sorguda istenen sonuc tum tablounun tahmini olarak % 10`undan daha fazla ise Full table scan yapilmasi cost(maliyet) acisinda daha avantajlidir.

Simdi ikinci calistiracagimiz SQL`in bu durumunu inceleyelim; Bilindigi gibi bu SQL ifadesi daha birçok kez çalışacaktır ve eğer Adaptive Cursor Sharing(ACS) olmasaydi ilk hard parse olan yani :sal = 10000’e göre oluşan execution plan :sal 2000 içinde uygulanacaktı ve daha avantajli olan Full Table Scan ile gelmesi gereken bir tablo index üzerinden getirilmeye çalışılacak ve response time’ı düşecekti ve sorgunun sonucu daha uzun sürede oluşacaktır.

Adaptive Cursor Sharing`den bilgileri alabilmemiz icin bize yardimci views(goruntuler) mevcuttur.

V$SQL :  tablosunda – IS_BIND_SENSITIVE,  IS_BIND_AWARE kolonlari
V$SQL_CS_HISTOGRAM : SQL ifadesinin bind sensitive olup olmadığını 3 adet frequency histogram ile yorumlamamızı sağlar. Ayrica Child cursorların kaçar kere çalıştığı bilgisinide içerir.
V$SQL_CS_SELECTIVITY : Bir SQL ifadesi ile beraber gelen where koşulundaki değerleri, bunların selectivitysini ve high value – low value aralığını tutar.
V$SQL_CS_STATISTICS : Adaptive Cursor’ın nekadar paylaşıldığını gösteren istatistik bilgilerini iceren bir view(goruntudur).