Oracle

Oracle Data Concurrency and Consistency

Tek kullanıcılı bir veritabanında, bir kullanıcı aynı verileri aynı anda değiştiren diğer kullanıcılar için endişe duymadan verileri değiştirebilir. Ancak, çok kullanıcılı bir veritabanında, aynı anda birden fazla transaction içindeki ifadeler aynı verileri güncelleyebilir. Eşzamanlı olarak gerçekleştirilen transactionlar anlamlı ve tutarlı sonuçlar üretmelidir. Aynı anda aynı tablo hatta aynı satırlar üzerinde işlem yapan çok kullanıcılı sistemler artık kaçınılmaz.Hal böyle olunca bilgilerin tutarlılığının sağlanması istenmeyen sonuçları almamak açısından çok önemlidir. Çok kullanıcılı bir veritabanı aşağıdakileri sağlamalıdır.

  • Kullanıcıların aynı anda verilere erişebileceği güvencesi (veri eşzamanlılığı – data concurrency). Kısaca pek çok kullanıcının aynı anda aynı dataya ulaşabilmesi durumu
  • Her kullanıcının, kendi işlemleri tarafından yapılan görünür değişiklikler ve diğer kullanıcıların taahhüt ettiği işlemler de dahil olmak üzere verilerin tutarlı bir görüntüsünü (veri tutarlılığı – data consistency) gördüğü güvencesi. Kısaca her bir kullanıcının kendisinin ya da bir başka kullanıcının transaction ı aynı anda calişsa bile tutarlı bir data setine sahip olabilmesi şeklinde özetlenebilir.

Transactionlar aynı anda çalıştığında tutarlı işlem davranışını tanımlamak için, veritabanı araştırmacıları serializability adı verilen transaction isolation modeli tanımladılar. Bu konu ile ilgili detaylı bilgiyi bir önceki yazımda vermiştim. Serializable bir transaction, başka hiçbir kullanıcı veritabanındaki verileri değiştirmemiş gibi görünmesini sağlayan bir ortamda çalışır.

Transactionlar arasında bu tür bir isolation derecesi genellikle arzu edilmekle birlikte, birçok uygulamayı serializable modda çalıştırmak, uygulama verimini ciddi şekilde tehlikeye atabilir. Eşzamanlı çalışan transactionların tamamen isolationı, bir transactionın başka bir transaction tarafından sorgulanan bir tabloya ekleme yapamayacağı anlamına gelebilir. Kısacası, gerçek dünyadaki düşünceler genellikle mükemmel transaction isolationı ve performans arasında bir uzlaşma gerektirir.

Oracle Database, multiversion consistency modeli ve çeşitli lock ve transaction türlerini kullanarak veri tutarlılığını(consistency) korur. Bu şekilde, veritabanı, eşzamanl ı(concurrent) olarak birden fazla kullanıcıya veri görünümü sunabilir, bu da her bir görünümün zaman içindeki bir noktayla tutarlı olmasını sağlar. Farklı veri bloğu versiyonları aynı anda mevcut olabileceğinden, işlemler bir sorgu için gereken zamanda işlenen verilerin versiyonunu okuyabilir ve zaman içindeki tek bir noktayla tutarlı olan sonuçları döndürür.

Multiversion Read Consistency

Oracle Veritabanında, multiversioning, aynı anda birden fazla veri versiyonu gerçekleştirme yeteneğidir. Oracle Database, multiversion okuma tutarlılığını korur. Oracle veritabanının sorguları aşağıdaki özelliklere sahiptir:

  • Read-consistent queries

Bir sorgu tarafından döndürülen veriler zaman içinde bir point için kesin ve tutarlıdır.

Not: Oracle Database hiçbir zaman,  kirli okumalara (dirty read) izin vermez. Dirty Read bir başkası tarafından (bir başkasının transaction’ı tarafından) henüz commit edilmemiş verinin, diğer kullanıcının transaction’ı tarafından okunmasına denir.

  • Nonblocking queries

Veritabanında da sorgulayanlar ve DML işemi yapanlar birbirlerini engellemez.

Oracle’ın garanti ettiği 2 tane uyumluluk kontrolü vardır. Bunlar, Statement level read consistency ve Transaction level read consistency dir. Bunlar, Oracle’ın her zaman bir sorgunun veri ile döneceğini ve her sorgunun veriye ulaşacağını garanti eden koşullardır.

Statement-Level Read Consistency

Oracle Database her zaman statement düzeyinde okuma tutarlılığını(read consistency) zorlar; bu, bir sorgu tarafından döndürülen verilerin zaman içinde tek bir nokta için kararlı ve tutarlı olduğunu garanti eder. Tek bir SQL ifadesinin tutarlı olduğu nokta, transaction isolation level ve sorgunun yapısına bağlıdır:

  • Read committed isolation level, bu nokta sorgunun açıldığı zamandır. Örneğin, bir SELECT ifadesi SCN 1000’de açılırsa, bu ifade SCN 1000 ile tutarlıdır.
  • Serializable veya read-only transaction, bu nokta transactionın başladığı zamandır. Örneğin, bir transaction SCN 1000’de başlarsa ve bu transactionda birden fazla SELECT ifadesi varsa, her ifade SCN 1000 ile tutarlıdır.
  • Bir Flashback Sorgu işleminde (SELECT … AS OF), SELECT ifadesi, zamandaki noktayı açıkça belirtir. Örneğin, bir tabloyu geçen perşembe saat 2: 00’de göründüğü gibi sorgulayabilirsiniz.

Yani transaction t anında bir sorgulama başlattığında bu t anına kadar olan bilgileri getirme garantisi vardır.Yani t+1 anında bir data girildiğinde bu datalar t anında başlatılan sorguda görülmezler.Peki bu değişiklikler olduğu halde nasıl tutarlı data getiriliyor.Oracle bunu rollback segment bilgisini okuyarak sağlar.

Transaction-Level Read Consistency

Oracle Database ayrıca, transaction-level read consistency olarak bilinen bir transaction daki tüm sorgulara okuma tutarlılığı sağlayabilir. Bu durumda, bir transaction daki her ifade aynı zaman diliminde veri görür; bu transactionın başladığı zamandır.

Serializable transaction tarafından yapılan sorgular, transactionın kendisinde yapılan değişiklikleri görür. Örneğin, employees güncelleyen ve ardından employees sorgulayan bir transaction güncellenen verileri görecektir. Transaction-level read consistency repeatable read isolation Leveldir ve sorguyu phantom read’a maruz bırakmaz.

Yani , transaction-level read consistency sinde statement-level read consistency sinden farklı olarak bir transaction içersinde tek bir sorgulama yerine birden fazla sorgulama için aynı garanti verilmektedir.Bu sayede bir sorgulama hiçbir zaman “dirty read” yapmayacağı gibi transaction ların yaptığı commit lerdende etkilenmez.Bu sadece SELECT için değil koşul içeren DELETE, UPDATE,sorgulama ile yapılan INSERT işlemlerinde de geçerlidir

Read Consistency and Undo Segments

Multiversion read consistency modelini yönetmek için, bir tablo aynı anda sorgulandığında ve güncellendiğinde veritabanı read consistency sağlaması için veri kümesi oluşturması gerekir. Oracle Database, verileri geri alma yoluyla(undo data aracılığıyla) okuma tutarlılığı(read consistency) sağlar. Bir kullanıcı verileri değiştirdiğinde, Oracle veritabanı, segmentleri geri almak için yazdığı undo segmentlerini oluşturur .

Undo segmentleri, uncommitted veya son zamanlarda değiştirilmiş transactionlar ile değiştirilen eski veri değerlerini içerir. Bu nedenle, aynı verinin birden fazla sürümü (verisyonu), hepsi zaman içindeki farklı noktalarda, veritabanında bulunabilir. Veritabanları, verilerin read-consistenti sağlamak ve nonblocking sorguları etkinleştirmek için farklı noktalardaki verilerin anlık görüntülerini(snaphot) kullanabilir.

Single instnace ve Oracle Real Application Cluster (Oracle RAC) ortamlarında read consistency garanti edilir. Oracle RAC, bir veritabanı instance’ından diğerine veri bloklarının read-consistent aktarmak için cache fusion olarak bilinen bir cache-to-cache bloğu aktarım mekanizması kullanır.

Aşağıdaki resimde statement-level read consistency sağlamak için  undo veri kullanan bir sorgu gösterir read committed isolation level.

Bu grafik, altında “SCN 10023″ yazan bir SELECT ifadesini gösterir. Açıklamada, her biri farklı bir SCN: 10021, 10021, 10024 (shaded blok), 10008, 10024 (shaded blok), 10011, 10021 şeklinde bir bloklar sütunu bulunur. ” Scan Path ” etiketli bir ok, SELECT ifadesinden sütun boyunca sonuna kadar gider, ancak ok, shaded blokların sağına çıkar ve sütunun sağına asılı olan bloklardan geçer: biri SCN 10006 ve diğeri ile SCN 10021 ile. Undo Segment etiketli bir daire bu iki bloğa işaret eder.

Veritabanı bir sorgu adına veri blokları alırken, veritabanı her sorgudaki verinin sorgu başladığında bloğun içeriğini yansıtmasını sağlar. Veritabanı, bloğun, sorgu işlemenin başladığı noktadaki bloğu yeniden yapılandırması için gereken değişiklikleri geri alır.

Veritabanında işlemlerin sırasını garanti altına almak için SCN adı verilen internal sıralama mekanizması kullanılmaktadır. SELECT ifadesi execute aşamasına girerken, veritabanı, sorgunun çalışmaya başladığı sırada kaydedilen SCN’yi belirler.  Yukarıdaki şekilde bu SCN 10023’tür. Sorgu yalnızca SCN 10023 ile ilgili taahhütlü verileri görür.

Yukarıdaki şekilde 10023’ten sonra SCN’lere sahip bloklar, SCN 10024’e sahip iki blokta gösterildiği gibi değiştirilmiş verileri gösterir. SELECT ifadesi, blokta yapılan değişikliklerle tutarlı bir versiyonunu gerektirir. Veritabanı, geçerli veri bloklarını yeni bir buffere kopyalar ve blokların önceki sürümlerini yeniden oluşturmak için undo verilerini uygular. Bu yeniden yapılandırılmış veri bloklarına consistent read (CR) klonları denir. Yukarıdaki şekilde, veritabanı iki CR klonu yaratır: bir blok SCN 10006’ya ve diğer blok ise SCN 10021’e uyumludur. Bu şekilde, Oracle Database dirty read’i önler. (continue reading…)

Loading


RDBMS KAVRAMI ve ORACLE RDBMS YAKLAŞIMLARI

Merhaba arkadaşlar veritabanında Data Concurrency ve Consistency konusunu yazmadan önce aşağıdaki veritabanı yaklaşımlarını öğrenmenin gerekli olduğunu düşünüyorum.

Tutarlılık (Consistency) ve erişilebilirlik (Availability), veri yönetim sistemlerinde iki farklı türde modelin doğmasına sebep olmuştur. Bunlar ACID ve BASE modelleridir.

ACID Modeli

ACID Standartları RDBMS veritabanlarında transaction işlemleri sırasında yapılan işlemlerin ne şekilde yapılması gerektiğini anlatan prensiplerdir. Geleneksel veritabanı ile çalışmış olan hemen hemen herkesin aşina olduğu bir modeldir. Bu modelde çalışan sistemler tutarlılık konusunda son derece hassastır ve veri kaybına oldukça pesimist yaklaşır. ACID, yeteneklerini ortaya dökebilmek için kilit mekanizmalarını kullanır. Bu mekanizmalar verinin diskte ve memoryde tüm kullanıcılar tarafından aynı görünmesini, verinin güncellenmesi sırasında onay gelene kadar tüm istemcilerin bekletilmesini mümkün kılar. Gerekirse tüm veritabanı kilit altına alınır. Gerektiğinde çakışan işlemlerin en maliyetli olanı hariç hepsi iptal edilir. Tabi ki pesimistlik seviyesine müdehale edebilirsiniz. Ancak ACID pesimist olması için dizayn edilmiştir.

Bu yaklaşım, verileri denetim altında tutan lock ve latch mekanizlarını kullanarak veri bütünlüğünü son derece güvenli noktaya taşımıştır. Hızdan daha çok veri tutarlılığının ön planda olduğu, özellikle paraya dokunan işlemler için ACID vazgeçilmezdir.

Aslında ACID; Atomicity, Consistency, Isolation ve Durability kelimelerinin kısaltılmış halidir. Bu ifadeleri inceleyecek olursak; (continue reading…)

Loading


Oracle SQL Tuning Araçları


SQL tuning araçları otomatik veya manueldir. Bu bağlamda, veritabanının kendisi tanı, tavsiye veya düzeltici eylemler sağlayabilirse, bir araç otomatik hale getirilir. Manuel bir araç, bu işlemlerin tümünü gerçekleştirmenizi gerektirir.

Tüm ayarlama araçları, veritabanı örneğinin topladığı dynamic performance view lerinin, istatistiklerin ve metriklerin temel araçlarına bağlıdır. Veritabanının kendisi, SQL ifadelerini ayarlamak için gereken verileri ve meta verileri içerir.

Otomatik SQL Tuning Araçları

Oracle Database, SQL tuningile ilgili birçok advisor sunar.

Ek olarak, SQL plan management performans gerilemelerini önleyebilen ve SQL performansını iyileştirmenize yardımcı olabilecek bir mekanizmadır.

Tüm otomatik SQL tuning araçları, SQL tuning setlerini giriş olarak kullanabilir. SQL tuning set (STS), execution istatistikleri ve execution context ile birlikte bir veya daha fazla SQL ifadesi içeren bir veritabanı nesnesidir. Otomatik sql tuning araçları aşağıdakiler gibidir.

  1. Automatic Database Diagnostic Monitor (ADDM)
  2. SQL Tuning Advisor
  3. SQL Access Advisor
  4. SQL Plan Management
  5. SQL Performance Analyzer

Automatic Database Diagnostic Monitor (ADDM)

ADDM, Oracle Veritabanına yerleşik kendi kendine diagnostic (teşhis) yazılımıdır.

ADDM, performans sorunlarının kök nedenlerini otomatik olarak bulabilir, düzeltme önerileri sağlayabilir ve beklenen faydaları ölçebilir. ADDM ayrıca hiçbir işlem yapılmayan alanları da belirler.

ADDM ve diğer advisorlar, istatistikleri toplamak, sürdürmek ve kullanmak için veritabanı bileşenlerine hizmet sağlayan bir altyapı olan Automatic Workload Repository (AWR) kullanır. ADDM, yüksek yüke neden olan SQL de dahil olmak üzere olası performans sorunlarını belirlemek için AWR’deki istatistikleri inceler ve analiz eder.

Örneğin, ADDM’yi gece çalışacak şekilde yapılandırabilirsiniz. Sabahları, soruna neyin neden olduğunu ve önerilen bir düzeltme olup olmadığını görmek için en son ADDM raporunu inceleyebilirsiniz. Rapor, belirli bir SELECT ifadesinin çok miktarda CPU tükettiğini gösterebilir ve SQL Tuning Advisor’ı çalıştırmanızı önerebilir.

ADDM analizi yukarıdan aşağıya doğru yapılır, önce semptomları tanımlar ve sonra performans problemlerinin kök nedenlerine ulaşmak için analizi inceler. ADDM, performans sorunlarını tanımlamak için DB time statistic (zaman istatistiğini) kullanır. Veritabanı zamanı (DB) zamanı, boşta olmayan tüm kullanıcı oturumlarının bekleme süresi ve CPU zamanı da dahil olmak üzere, kullanıcı isteklerini işlemede veritabanının harcadığı kümülatif zamandır.

Performans sorunlarını tanılamanın yanı sıra, ADDM olası çözümleri de önerir. Uygun olduğunda, ADDM, içinden seçim yapabileceğiniz birden fazla çözüm önerir.Örneğin;

  • Donanım değişiklikleri
  • CPU ekleme veya I/O sisteminin konfigurasyonu
  • Veri tabanı yapılandırması
  • Başlatma parametresi ayarlarının değiştirilmesi
  • Şema değişiklikleri
  • Bir tablo veya indexi bölümlere ayırma ya da automatic segment space management kullanma karma
  • Uygulama değişiklikleri
  • Indexler için önbellek seçeneğini kullanma veya bind variable kullanma
  • Diğer danışmanları kullanmak

(continue reading…)

Loading


SQL İşleme (Processing)

Bir veritabanı sisteminde SQL çalıştırdığımız zaman arka planda nelerin olduğunu bilmek önemli. Bilindiği takdirde örneğin “bind variable kullanımı”, “bulk işlemler” vb. durumlarda Oracle tarafında olan işlemlerin nasıl etkilendiği farkında olunacak ve buna göre bir yaklaşım belirlemek mümkün olacaktır.

SQL işlemleri 2 ana başlık altında toplanır :

  • DDL(Data Definition Language) : “Data Dictionary” üzerinde değişikliğe sebeb olan create, drop, alter gibi işlemlerdir.
  • DML(Data Manipulation Language) : Veriye ulaşmak ya da değiştirmek amacıyla yapılan işlemlerdir.(Select, update,delete…vs.)

SQL Processing işlemi parsing, optimization, row source generation ve execution adımlarından oluşur. Sql ifadesine göre bazı adımlar atlanabilir.

SQL Parsing

Yukarıdaki diyagramda gözüktüğü üzere SQL işlemesinin ilk aşaması SQL sorgusunun parse edilmesidir. Parse etmeyi şöyle açıklayabilirim. Bir uygulamaya ya da bir operasyona anlamlı gelecek şekle getirmektir. Binary bir dosyayı parse ederek CSV formatında bir dosyaya çevirirseniz, sizin için anlamlı bir hale gelecektir ancak öncelikle parser’ın binary dosyanın dilinden anlıyor olabilmesi ve sizin elinizde bunu tercüme edecek bir dokümantasyonun bulunması gerekmektedir. Oracle’ın yaptığıda aslında bundan çok farklı değildir. Oracle da kendisi için anlamlı gelecek bir format oluşturmaya çalışır fakat sistematiği biraz farklıdır.

Bir sql ifadesi çalıştırılacağı zaman veritabanı üzerinde parse call talebi ile veritabanı üzerinde cursor açılır. Bu cursor session bazlı açılır ve private SQL area üzerinde tutulur. Cursor ve private SQL area program global area (PGA) içindedir. Parse call işlemi 3 aşamadan oluşur.

  • Syntax check
  • Semantic check
  • Shared pool check

(continue reading…)

Loading


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


SQL Sorgusunun Shared Pool’dan Silinmesi (Flush)

Bir tabloda sürekli olarak belirli satırları sorguluyor ya da değiştiriyorsanız, her seferinde diske gitmeniz mantıklı olmaz. Çünkü I/O maliyetli bir işlemdir. Bu yüzden bellek performans için can simididir. Sıkça okuduğunuz ya da sıkça değiştirdiğiniz şeyleri her seferinde diske yazmak ya da diskten okumak yerine bunu bellekte kotarabilirseniz, performansı arttırabilirsiniz. Bellekte çalışmak performans konusunda artış sağladığından Oracle da böyle yapar; diskte çalışmak yerine mümkün olduğunca belleği kullanır. İşte bu yüzden bir sorguyu ikinci defa çalıştırdığınızda, sonuçlar daha hızlı gelir. Çünkü sorguda kullanılan block’lar hâlâ ‘sıcaktır’ ve diske hiç gitmeden, direkt bellekten sonuç döner. Bellekte yer kalmadığında, daha sıcak (kullanım sıklığı daha fazla) olan block’lar, soğuk (kullanım sıklığı daha az) block’ların yerini alır. Oracle kapalı bir yazılım olduğundan arka plânda ne olduğunu elbette bilemiyoruz. Ama zekice yazılmış bir Least Recently Used – LRU algoritmasıyla bu işin yapıldığını tahmin edebiliriz.
İşlemlerin bellekte gerçekleştirilmesi güzel bir olay. Ama bazı durumlarda (performans problemleriyle karşı karşıya kaldığımızda ya da testlerin daha tutarlı olması gerektiğinde) Oracle’a bazı komutlarla müdahele etmemiz gerekir.

1. BUFFER CACHE

Oracle’da birçok şey sadece bellekte tamamlanıyor. Örneğin bir DML işlemi (insert, update, delete) yaptığınızda gidip veritabanı dosyalarına yazması gerekmez. Ya da bir sorgu çalıştırdığınızda, sorgu biter bitmez, veri saklayan block’ların bellekten atılması gerekmez. Block’lar sorgulara göre bellekte tutulabilir. Hatta çalıştırdığınız sorgular, diske hiç erişmeden sonuç dönüyor olabilir. Bununla ilgili bir örnek üzerinden gidelim. Önce aşağıdaki gibi tabloyu yaratıyoruz:

create table test as select * from dba_objects;

Yarattığımız tabloda toplamda 96.760 kayıt var ve tablonun bulunduğu tablespace’te her block 8K’dan oluşuyor. DBA_SEGMENTS’ten baktığımda tablonun 11.534.336 byte (11MB) kapladığını ve 1408 block’tan oluştuğunu görüyorum. Tablo istatistiklerini topladığımdaysa, 1387 block görünüyor. (Block boyutunu 1K’ya kadar indirip, PCTFREE değerini düşürebilseydik; bu ikisi arasındaki fark daha da ufak olabilirdi.)
Sırada basit bir sorgu yazmak var:

SELECT COUNT(*)FROM test WHERE OBJECT_ID >1000;

Şimdi de sorgunun ne kadar disk okuması yaptığına bakalım.

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
77mjdqdj82paz    1395          1           1450

Buradaki DISK_READS, okunan block sayısı; EXECUTIONS ifadenin kaç kere çalıştığı; BUFFER_GETS ise SQL ifadesi nedeniyle bellekten ne kadar blockokunduğunu gösteriyor. Bunları daha iyi görebilmek için aynı sorguyu defalarca çalıştırıyorum:
Sorguyu defalarca çalıştırdıktan sonra, EXECUTIONS sayısı arttığı hâlde DISK_READS artmıyor, fakat BUFFER_GETS ciddi bir artış gösteriyor. Yani SQL’in diske gitmeden sürekli bellekten sonuç döndüğünü görebiliyoruz. Bu güzel bir özellik ama eğer bir SQL’i test ediyor olsaydım, sonuçları sürekli bellekten okumak beni yanıltırdı. Bu gibi durumlar için bellekteki block’ları boşaltmak daha doğru sonuçlar elde etmemi sağlar. Burada aşağıdaki komutla manüel olarak buffer cache’in içini boşaltıyoruz.

ALTER SYSTEM FLUSH BUFFER_CACHE;

Özetle FLUSH BUFFER_CAHCE yaparsanız;
• Bellekte tutulan block’lar atılır.
• Dirty Buffers (değişime uğramış ama diske yazılmamış, bellekte tutulan block’lar) diske yazılır
• SQL Plan bozulmaz
• SQL ile ilgili istatistikler silinmez

2.SHARED POOL

İlk kez çalışan SQL ifadeleri hard parse yapılır. SQL ifadesi hash’lenerek ona özel bir kimlik (SQL_ID) verilir; ihtimaller hesaplanarak en uygun (cost’u en düşük) plan belirlenir. Bu masraflı bir iştir; CPU’ya maliyeti vardır. Bu yüzden plan tekrar tekrar hesaplanmaz. Aynı ifade söz konusu ise aynı plan üzerinden gidilir. Bu güzel bir özellik ama bazı zamanlar operasyonumuz sonrası SQL’imiz için yeni bir execution plan oluştursuz isteriz. Bu gibi durumlardan sakınmak için shared pool’u boşaltmak bir çözümdür;

ALTER SYSTEM FLUSH SHARED_POOL;

Yukarıda anlattıklarım zaten bilinen şeyler. Fakat göstermek istediğim bir durum var. Aşağıdaki sorguyu çalıştırırsanız artık sonuç boş gelecektir –ki bu beklediğimiz bir şey. Çünkü SQL ID ve buna bağlı her şey gidiyor.

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
no rows selected.

Şimdi ilk sorgumuzu tekrar çalıştırıp, disk okumalarına bakalım:

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
77mjdqdj82paz    0          1           1450

İlk defa çalıştırıldığı ve sql plan ilk defa hazırlandığı hâlde, hiç disk okuması yapılmıyor.
Özetle FLUSH SHARED_POOL yaparsanız;
• Bütün SQL planları ve bellekte tutulan SQL bilgilerini atarsınız.
• Ancak bu buffer cache’te tutulan data block’larını etkilemez. Daha önce eriştiğiniz block’lar hâlâ bellektedir. (continue reading…)

Loading


  • Sertifikasyon



  • Etiketler

  • Topluluklar

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