Tag: Oracle Cardinality

Oracle Histogram

Tablo ve sütun istatistikleri, optimizer a çok şey anlatır, ancak Optimizera tablodaki veya sütundaki verilerin çeşitliliğini bildiren bir mekanizma sağlamaz. Örneğin, bu istatistikler sütunda verilerin skew data (çarpık/birbiriyle kesişmeyen veri) olup olmadığını veya bir tablodaki sütunlar arasında bir korelasyon olup olmadığını (farklı sütunlar arasındaki doğrusal ilişkinin yönü ve gücü) Optimizer’e söyleyemez. Verilerin çeşitliliği hakkındaki bilgiler, histogramlar, sütun grupları (column groups) ve sorgu istatistikleri gibi temel istatistiklerin uzantıları kullanılarak Optimizer’e sağlanabilir.

Histograms

Histogramlar, Optimizer ‘a bir sütundaki verilerin dağılımını anlatır.  Varsayılan olarak (histogram olmadan), Optimizer, bir sütundaki belirsiz değerler arasında tek bir satır dağılımını varsayar. (yani hep aynı değerde veri varmış gibi düşünür)

Yukarıda tarif edildiği gibi, Optimizer, bir eşitlik öngörüsünün kardinalitesini, tablodaki toplam satır sayısını eşitlik yüklemesinde kullanılan sütundaki farklı değerlerin sayısına bölerek hesaplar. Sütundaki veri dağılımı uniform (tekdüze) değilse (yani veri skew (çarpık) ise) kardinalite testi yanlış olacaktır. Düzgün olmayan bir veri dağılımını doğru bir şekilde yansıtmak için sütunda bir histogram gerekir. Histogramın varlığı, Optimizer tarafından cardinality’i tahmin etmek için kullanılan formülü değiştirir ve daha hassas bir uygulama planı oluşturmasını sağlar.

Oracle, sütun kullanım bilgilerine (SYS.COL_USAGE $) ve veri eğrilmesinin öncülüğünü esas alarak histogramlara ihtiyaç duyan sütunları otomatik olarak belirler.

Oracle, sütun kullanım bilgilerine (SYS.COL_USAGE $) ve skew veriye(çarpık)  bağlı olarak histogramlara ihtiyaç duyan sütunları otomatik olarak belirler. Örneğin, bir sütunda unique alan var ve yanlızca eşitlik var mıdır yok mudur şartı gelirse Oracle histogram oluşturmaz.

İki tip histogram vardır; frequency veya height-balanced. Oracle, sütundaki farklı değerlerin sayısına göre oluşturulacak histogram türünü belirler. (continue reading…)

Loading


Oracle Optimizer

Merhaba arkadaşlar bu yazıda  SQL işlemeyi (processing), optimizasyon yöntemlerini ve sorgu optimizerının SQL’i yürütmek için belirli bir planı nasıl seçtiğini anlatmaya çalışacağım.

Öncelikle optimizer’ın tanımı ile başlarsak optimizer bir SQL sorgusunun çalıştırmanın en etkili yolunu belirleyen gömülü/dahili bir yazılımdır.

Veritabanı full table scans, index scans, nested loops ve hash joins  gibi birçok şekilde bir SQL sorgusu çalıştırabilir. Optimizer, bir execution plan(yürütme plan) belirlerken, sorgudaki objeler ve koşullar ile ilgili birçok faktörü göz önünde bulundurur. Bu belirleme, SQL işlemede önemli bir adımdır ve yürütme süresini büyük ölçüde etkileyebilir.

NOT : Optimizer, Oralce veritabanı bir sürümünden diğer sürümüne aynı kararları vermeyebilir. Optimizer devamlı geliştirilen bir yazılım olduğundan çoğu zaman son sürümlerde daha iyi execution plan lar çıkartır.

Veritabanına bir sorgu geldiğinde optimizer aşağıdaki adımları gerçekleştirir;

  1. Optimizer, mevcut access paths (erişim yollarına) ve hint lere(ipuçlarına) dayanarak SQL ifadesi için bir dizi potansiyel plan oluşturur.
  2. Optimizer, her planın maliyetini data dictionary’deki istatistiklere dayanarak tahmin eder. İstatistikler, tabloların, dizinlerin ve ifadenin erişebildiği bölümlerin veri dağıtımı ve depolama özellikleri hakkında bilgiler içerir.

Cost, bildirimi belirli bir execution planla yürütmek için gereken beklenen kaynak kullanımıyla orantılı tahmini bir değerdir. Optimizer, Access path (erişim yollarının) maliyetini hesaplar bu hesap I/O, CPU ve RAM kullanım bilgilerini  içeren tahmini bilgisayar kaynaklarının kullanımıdır.

Daha yüksek maliyetli (yani coştu daha yüksek) olan planların daha düşük maliyetli (coştu daha düşük) olanlardan daha uzun sürmesi gerekir. Paralel bir plan kullanırken, kaynak kullanımı doğrudan geçen zamanla ilişkili değildir.

  1. Optimizer planları karşılaştırır ve en düşük costlu planı seçer.

Optimizer dan elde edilen çıktı, optimum uygulama yöntemini tanımlayan bir execution olandır. Planlar, Oracle Veritabanı’nın bir SQL ifadesini çalıştırmak için kullandığı adımların birleşimini gösterir. Her adım ya veritabanından fiziksel olarak satırları alır ya da ifadeyi veren kullanıcı için hazırlar.

Oracle Database tarafından işlenen herhangi bir SQL ifadesinde, optimizer aşağıda listelenen işlemleri gerçekleştirir.

Operasyon Açıklama
İfadelerin ve koşulların değerlendirilmesi Optimizer, önce sabitleri içeren ifadeleri ve koşulları olabildiğince tamamen değerlendirir.
İfade dönüşümü Örneğin, ilişkili alt sorguları veya view leri içeren karmaşık ifadeler için, optimizer orijinal ifadeyi eşdeğer bir birleşme ifadesine dönüştürebilir.
Optimize edici hedeflerin seçimi SQL ifadesi için bir optimizasyon yaklaşımı belirlenir.
Access path seçimi Sorgu tarafından erişilen her tablo için, optimizer tablo verilerini elde etmek için mevcut Access pathlerden birini veya daha fazlasını seçer.
Birleştirme sırasının seçimi İkiden fazla tabloyu birleştiren bir sorgu için, optimizer ilk önce hangi tablo çiftlerinin birleştirileceğini ve ardından hangi tablonun sonuçla birleştirileceğini seçer.

 

NOT : Bazen, belirli bir uygulamanın verileri hakkında optimizer için mevcut olandan daha fazla bilgiye sahip olabilirsiniz. Bu gibi durumlarda, optimizera bir ifadenin nasıl yürütülmesi gerektiği konusunda talimat vermek için SQL ifadelerindeki hintleri kullanabilirsiniz.

Optimizer Bileşenleri

Optimizer işlemleri şunları içerir: Bir Optimizer’ın bileşenleri varmadan önce girdisi yapılan bileşene “parsed query” yani parse edilmiş SQL sorgusu denmektedir. İlerleyen bölümlerde parsed sorgudan bahsediyor olacağım.

Oracle optimizer 1

Query Transformation

Parse edilmiş sorgunun yapısının değiştirilmesine ihtiyaç varsa ve bu faydalı bir çalışma olarak kabul edilmekteyse Query Transformer sorgunun yapısını değiştirebilir.

Query Transformation, aşağıdakiler dahil olmak üzere birkaç sorgu dönüştürme tekniğini kullanır:

  • View Merging
  • Predicate Pushing
  • Subquery Unnesting
  • Query Rewrite with Materialized Views

(continue reading…)

Loading


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress