Tag: Oracle Assessing I/O for Blocks

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…)

1,032 total views, 3 views today


Oracle Index


Selamlar ,bu yazımda Veritabanlarında Index kavramının ne olduğunu ve nasıl kullanıldığını anlatacağım. Index kavramı özellikle Oracle Veritabanlarının Performance tuning çalışmaları konusunda çokça karşımıza çıkar.

Veritabanı teknolojilerinde verilerimizin tutulduğu tablolardaki verilere daha hızlı erişebilmek için oluşturduğumuz nesnelere Index denir.  Index, bir tablo veya tablo cluster ile ilişkilendirilen, veri erişim hızını arttıran, opsiyonel segment yapısıdır. Bir veya daha fazla alan üzerinde tanımlanan index yardımı ile, tablo segmenti içerisinde rastgele dağılmış küçük veri kümelerine yani disk üzerine rastgele dağılmış blok kümelerine erişim hızı sağlanır. Bir tablo segmentinin belli oranda kayıt içeren bir küme verisine erişirken gereksiz yere tüm tablo verisinin disk üzerinde taranması (FTS) engellenir ve disk I/O işlemi azaltılır.

Index i anlamak için başka bir yazıdan elde ettiğim örnek çok güzel; Ör: Elinizde 100.000 farklı kelime içeren İngilizce-Türkçe sözlüğünün olduğunu düşünün ve siz sürekli olarak bilmediğiniz ingilizce kelimeleri sözlükten bulup türkçe karşılıklarına bakmaktasınız. Eğer bu İngilizce Türkçe sözlüğünüz Kelimelerin baş harf(ler)ine göre sıralanmasaydı ne olurdu ? Siz mesela Computer kelimesini bulmak için neredeyse Tüm sözlüğü baştan aşağı taramanız gerekecekti. Buda haliyle hem çok zaman alacaktır hemde sizi gereksiz yere yoracaktır. Ancak eğer sözlüğünüz Kelimelerin baş harf(ler)ine göre sıralanmışsa, ki mantıklı olan yolda budur bu durumda siz Computer kelimesini bulmak için Sözlüğün içindekiler kısmından C harfinin başladığı sayfaya direk gider ve aramanızı burada gerçekleştirirsiniz. İşte buradaki Sözlüğün içindekiler kısmı ve kelimelerin baş harfine göre sıralanması mantığı ile Veritabanlarında kullanılan Index mantığı aynı şeydir.

Oracle veritabanında bir tablodan veri sorgulandığı zaman Oracle ilk olarak o tabloya ait index varmı yokmu bunu kontrol eder. Eğer index var ise ve istenilen kayıt sayısı tablonun ortalama %15 ine eşit veya daha az ise Oracle istenen verileri Index üzerinden bulup dönderir. Bu tip bir veri sorgulama normalden daha kısa sürede ve daha az maliyetli olarak gerçekleşir ve buna Index Scan denir. Eğer index yoksa yada index varken istenen kayıt sayısı tablonun tamamının %15 inden fazla ise Oracle bu durumda indexten gitmenin daha maliyetli olduğunu düşünüp Full Table scan dediğimiz tablonun tamamını tarar. Full table scan yada Index scan olup olmamasını Query Optimizer karar verir. Yukarda belirttiğim %15 oranıda yine bazen değişiklik gösterse de Oracle ın genel itibariyle bu konuda sunduğu threshold değeri %15 tir. Bu %15 değeri büyük tablolar için geçerli olsada denediğim küçük tablolarda %40 lara kadar varabiliyor. Ancak dediğim gibi  genel itibariyle Oracle diyorki eğer sorguladığınız veri, tablonuzun %15 ine eşit yada küçükse tablonuzda index varsa veriyi  çok hızlı bir şekilde ve daha az maliyetle size sunmak için ben indexi kullanırım diyor. Böylece istenen verileri bulmak için index kullanıldığında I/O miktarı düştüğü için hem hızlı bir şekilde veriler bulunur hemde sistem kaynakları çok tüketilmez.  Tablolarımızda Index kullanmanın avantajları olduğu gibi dezavantajları da vardır. Index kullanmanın  dezavantajları aşağıdaki gibidir.

  • Indexler fiziksel olarak diskte yer kapladığı için gerekmedikçe Index kullanmak ekstra disk maliyetini artıracaktır.
  • Indexler genel anlamda sorgularımızda performansı artırırken DML ( insert,update,delete ) işlemlerini ise yavaşlatmaktadır. Özellikle çok fazla DML işlemleri yapılan tablolarda index kullanmamak gerekir.
  • Index kullandığımız zaman veritabanının maintenance ( index maintenance ) yükü artacağı için ekstra bir yük gelicektir.

Genel itibariyle şöyle bir durum ortaya çıkarabiliriz. Veritabanlarında çok fazla sorgu (Select) yapılan tablolarda (Genellikle Rapor çekilen OLAP sistemlerindeki tablolar ) Index kullanmak performans açısından çok faydalı olduğu gibi sistem kaynaklarınıda yormaması yönüyle de bizim için vazgeçilmez bir nimetdir. Veritabanlarında çok fazla DML( Data Manipulation Language – Insert,Update,Delete) işlemleri yapılan tablolarda (Genellikle OLTP sistemlerde görülen tablolar ) Index kullanmak maliyetli ve performans sorunlarına yol açacaktır o yüzden gerekmedikçe böyle tablolarda kullanılmamalıdır.

İndexler aşağıdaki özelliklere sahiptir:

  • Usability (Kullanabilirlik) : İndexler kullanılabilir (varsayılan) veya kullanılamaz durumda olabilirler. Kullanılamaz bir index DML işlemleri tarafından korunmaz ve optimizer tarafından yoksayılır. Kullanılamaz bir index bulk loads (büyük hacimli) işlerin performansını artırabilir. Bir indexi silip yeniden oluşturmak yerine, indexi kullanılamaz hale getirebilir ve daha sonra yeniden oluşturabilirsiniz. Kullanılamayan indexler , index segment alanı tüketmez. Kullanılabilir bir indexi kullanılamaz hale getirdiğinizde, veritabanı indexi segmentini siler.
  • Visibility (Görünürlük) : İndexler görünür (varsayılan) veya görünmez durumda olabilirler. Görünmez bir index DML işlemleriyle korunur ve varsayılan olarak optimizer tarafından kullanılmaz. İndexi görünmez yapmak, kullanılamaz hale getirmek veya düşürmek için bir alternatiftir. Görünmez indexler, bir indexin silinmesini sınamadan veya genel uygulamayı etkilemeden geçici olarak indexleri kullanmadan önce özellikle kullanışlıdır.

Composite Indexes

Kompozit (Birleşik) index olarak da adlandırılan index tipi, tablodaki birden çok sütunda bulunan bir indexdir. Kompozit bir index deki sütunlar, verileri alacak sorgular için en anlamlı olan sıraya göre görünmeli ve tabloda bitişik olmamalıdır.

Kompozit indexler, WHERE tümcesinin kompozit index içindeki sütunların tümüne veya baş kısımlarına başvuru yaptığı SELECT ifadeleri için verilerin alınmasını hızlandırabilir. Bu nedenle, tanımda kullanılan sütunların sırası önemlidir. Genel olarak, en sık erişilen sütunlar önce gider.

Unique and Nonunique Indexes

İndexler unique veya unique olmayan olabilirler. Unique indexler, bir tablonun hiçbir iki satırının ana sütun veya sütunda yinelenen değerleri olmadığını garanti eder. Örneğin, iki çalışan aynı çalışan kimliğine sahip olamaz. Böylece, benzersiz bir indexde, her veri değeri için bir satır bilgisi vardır. Bloklar veriler sütun verileriyle ile sıralanır.

Unique olmayan indexler, indexe alınmış sütun veya sütunlardaki değerleri çoğaltmaya izin verir. Örneğin, çalışanlar tablosunun ilk_adı sütunu birden fazla Mike değeri içerebilir. Unique olmayan bir index, satır içi sıralamaya dahil edilmez, bu nedenle unique olmayan indexler, sütün verilerine ve rowid’e (artan) göre sıralanır.

Oracle Veritabanı, bitmap index veya cluster key index sütun değeri null olduğunda, tüm sütunların boş olduğu tablo satırlarını indekslemez.

Index Çeşitleri

Oracle Database, performans işlevselliği sağlayan birkaç indexleme alternatifi sunar. Indexler şu şekilde sınıflandırılabilir:

  • B-tree indexes : Bu index standart index türüdür. Primary key ve son derece seçici(selectivity) indexler için mükemmeldirler. Kompozit indexler olarak kullanıldığında, B-tree indexleri, indexe alınmış sütunlara göre sıralanmış verileri alabilir. B-tree indexleri aşağıdaki alt türlere sahiptir:
    • Index-organized tables : Normal tablolarda (Heap-Organized Table) veriler disk üzerinde hangi bloğa sığıyorsa oraya saklanır, index-organized tablolarda ise veriler, PK için tanımlanmış olan index yapısı içerisinde saklanır. Tablonun kendisi bir index’tir. Bu tip tablolara PK ile erişim çok daha hızlıdır.
    • Reverse key indexes : Bu index tipinde, indeksin byte’ları tersinde çevrilerek saklanır, örneğin 103 değeri 301 olarak saklanır. Bunun amacı indekse yapılan insert işlemlerinin birden çok bloğa yayılmasını sağlamaktır.
    • Descending indexes : Default olarak ascending olarak tanımlanan index yapısı DESC keyword’ü ile ters bir dizilimle DESCENDING olarak saklanabilir.
    • B-tree cluster indexes : Bu index tipi, cluster yapıdaki tabloların cluster key’lerini indexlemek için kullanılır. Index, bir row’u point etmek yerine cluster key ile ilişkili olan row’ları içeren bloğu point eder.
  • Bitmap and bitmap join indexes : Bu index türü belli başlı değerlerin sürekli olarak tekrar etmesi durumunda kullanılır.
  • Function-based indexes : Index tanımlı alanın, WHERE koşulunda bir fonksiyon içerisinde kullanılması kaçınılmaz ise bu alanı fonksiyonu ile beraber indexlememiz gerekir; aksi halde index kullanılmaz.
  • Application domain indexes : Uygulamaya özel özelleştirilmiş bir indexdir.

(continue reading…)

1,365 total views, 3 views today


  • Sertifikasyon



  • Etiketler

  • Topluluklar

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

    Her yeni yazı için posta kutunuza gönderim alın.

    Diğer takipçilere katılın: