Açık ve önbelleklenmiş imleçlerin izlenmesi

Açık imleçler(cursors) library cache içinde yer tutmaktadırlar. Pekçok oturumunun, library cache içini tepeleme doldurmasının önüne geçmek için veya CPU’nun milyonlarca çözümleme(parse) çağrıları ile tıkanmasını önlemek için, OPEN_CURSORS parametresi ayarlanır.

OPEN_CURSORS parametresi, her bir oturumun oturum başına açabileceği maksimum imleç sayısını belirtir. Mesela, eğer OPEN_CURSORS parametresi değeri 1,000 olarak ayarlanırsa, bu durumda her bir oturum bir seferde en çok 1,000 imleci açabilir. Eğer tek bir oturum OPEN_CURSORS parametresince belirlenen değeri aşarsa, bu açacağı imleçler esnasında ORA-01000 hata mesajını alacaktır.

OPEN_CURSORS parametresinin varsayılan değeri 50’dir, ancak  pek çok uygulama için bu sayının en azından 500, hatta pek çok yeni nesil web uygulamalarında yüzlerce kullanıcı oturumunun paylaşımlı havuzları sık şekilde kullanmasından dolayı bu sayının 1,500 olması tavsiye edilir.

Eğer SESSION_CACHED_CURSORS parametresi ayarlanmazsa, değeri 0 olarak ayarlanır ve oturum için hiç bir imleç önbelleklenmez. Tabii, imleçler paylaşımlı havuzda öncelleklenecek, ancak bunları bulmanız gerekecektir ve bu durum en iyimser yaklaşımla bolca yumuşak çözümleme(soft parse) olayına sebep verecektir. Eğer bu parametre ayarlanırsa Oracle, library cache içine bakacak ve bu SQL komutu için 3 seferden fazla çözümleme(parse) çağrısı yapılıp yapılmadığına bakacaktır. Eğer yapılmışsa, Oracle bu komut ile ilişkili oturum imlecini oturum imleç önbelleği içine taşıyacaktır.  Bu oturum tarafından ilgili SQL komutu için yapılan daha sonraki çözümleme çağrıları oturum imleç önbelleğinden doldurulacak, böylece yumuşak çözümleme(soft parse) olayından bile kaçınılmış olunacaktır. Bu noktada çözümleme işleminden kaçınmak mümkün değildir ve “daha yumuşak” çözümleme olayları, daha az CPU tüketimi ve çok daha hızlı çözümleme anlamına gelecektir.

Optimizer’ın doğru indeksi kullanmama sebepleri

Bazı durumlarda SQL komutu indeks kullanmadığından veya doğru indeksi tercih etmediğinden kötü performans gösterebilmektedir. Eğer uygun bir indeks yoksa, optimizer muhtemelen full tablo taraması(FTS) yapacaktır. Bazen çoğunlukla ideal olduğu düşünülen indeks yerine başka bir indeks seçilip kullanılacaktır. Eğer optimizer bir indeks kullanmıyor veya yanlış olduğu düşünülen bir indeks kullanıyorsa, aşağıdaki durumların gözden geçirilmesi gerekmektedir:

  v Uygun indeksin var olduğundan emin olun. Uygun indeks, SQL komutunun filtre kısmındaki şartların, mümkün olan en fazla sayıda sorgudaki filtre sırasına uygun olarak, kolon isimlerini karma indeks şeklinde barındıran indekstir. Eğer bu şekilde bir indeks yer almıyorsa, optimizer atlanan kolonların benzersiz değerleri başına efektif olarak “index range scan” işlemi çalıştıran indeks ile INDEX SKIP SCAN işlemini kullanabilecektir. Bu gibi operasyonlar, atlanan kolonların benzersiz değerlerinin sayısı düşük olduğunda değer kazanacaktır. Aksi takdirde,  bu operasyon verimsiz olma eğilimine girecektir. Atlanan kolon sonrası veya eşitsizlik kıyaslamasında kullanılan kolon sonrasında indeks tanımına dahil olan herhangi bir kolon, taranacak indeks yaprak blok sayısını azaltmak için kullanılamayabilir. Bu durum çalıştırma planında “predicate information” bölümünü incelerken görülebilmektedir. İndeks bloklarına direkt olarak erişmek için kullanılamayacak olan kolonlar indekse etki eden ilave FILTER yüklemi olarak belirecektir.

CPU üzerinde “çözümleme zamanı” sorunu

Bir komutun çözümlemesi, bir PARSE çağrısının parçası olarak gerçekleştirilmesi için zorunlu olarak gerekmemekte, ancak başlangıç çözümlemesinden itibaren imlecin geçersiz olduğu durumlarda EXEC çağrısı vasıyasıyla da tetiklenebilmektedir. Bu demektirki, izleme dosyasında pek çok PARSE çağrısı görülmemesine rağmen “çözümleme” ile ilişkili performans sorunlarınız olabilmektedir. TKPROF aracı üzerinden görülebilen bununla ilgili istatistikler, çözümleme esnasında library cache içindeki kayıplar(misses) olarak ve çalıştırma esnasında ise library cache içindeki kayıplar(misses) olarak görülmektedir.  

Burada bunların görülme sayısı, komutun optimizasyon aşamasıda dahil ne kadar sayıda “full parse-tam çözümleme” ihtiyacını duyduğunu temsil ederken, halbuki TKPROF çıktısındaki çözümleme istatistiklerinde görülebilen “hafif çözümleme-soft parse” çağrıları daha düşük kaynak tüketim hassasiyetindedir.

İdeal olarak, bir uygulama imleci bir sefer çözümleyerek hem “hafif”,  hemde “sert” çözümleme çağrılarının üstesinden gelebilir ve aynı imlecin daha sonraki çalıştırma işlemleri için gerekli olan en uzun sürede bu imleci açık olarak tutmaktadır.  İmlecin geçersiz(invalidated) olmasının önlemi alındığında, imleç bir sefer çözümlenecek ancak pek çok kez çalıştırılabilecektir.