Oracle

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

50 total views, 2 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…)

278 total views, no views today


Oracle İstatistik

Oracle veritabanı ilk piyasaya sürüldüğü yıllarda, bir SQL cümlesinin nasıl çalıştırılacağına RBO (Rule Based Optimizer) isimli bir optimizer karar veriyordu. Bu kurallara sıra atanıyor ve sıra değeri en yüksek olan kural işletiliyordu.

Rule Based Optimizer(RBO) : Adı üstünde “execution plan” çıkarırken belli bir sırada tanımlı kural tablosundan faydalanır.Bu kural tablosu aşağıdaki şekildedir :

  1. Single Row by Rowid
  2. Single Row by Cluster Join
  3. Single Row by Hash Cluster Key with Unique or Primary Key
  4. Single Row by Unique or Primary Key
  5. Clustered Join
  6. Hash Cluster Key
  7. Indexed Cluster Key
  8. Composite Index
  9. Single-Column Indexes
  10. Bounded Range Search on Indexed Columns
  11. Unbounded Range Search on Indexed Columns
  12. Sort Merge Join
  13. MAX or MIN of Indexed Column
  14. ORDER BY on Indexed Column
  15. Full Table Scan

Daha sonra Oracle 7 ile birlikte CBO (Cost Based Optimizer) isimli daha kompleks bir optimizer oluşturuldu. Bu optimizer partitioning, paralel çalışma ve en önemlisi de verinin segmentler üzerinde nasıl dağıldığını da hesaba katacak şekilde geliştirildi.

CBO, mümkün olan tüm planları inceleyerek, COST değeri en düşük olan execution planı seçer. Buradaki COST’dan kastımız ise, verilen planın ne kadar kaynak kullanılacağının bir tahminidir. Bu tahminin gerçeğe yakın olabilmesi ve dolayısı ile COST’un yaklaşık olarak hesaplanabilmesi için CBO’nun tablo, index vb. segmentler hakkında ve bu segmentler üzerindeki veri dağılımlarının, density(yoğunluk), selectivity vb. bilgilerinden haberdar olması gerekmektedir. İşte bu bilgilere “OPTIMIZER STATISTICS”, veritabanı istatistiği denir.

NOT : Density değeri 0 ve 1 arasında bir decimal değerdir. 1’e yakın değerler kolonun unselective, 0’a yakın değerler ise selective (seçici) olduğunu gösterir. Density değerinin oluşabilmesi için tablo üzerinde gather statistics işlemi çalıştırılmalıdır. Density hesaplamak için “DENSITY = 1 / (NULL olmayan distinct değer sayısı)” örneğin “DENSITY = 1 / 2000 = 0,0005 ” dir.

İstatistik bilgileri USER_TAB_STATISTICS, USER_TAB_COL_STATISTICS… gibi data dictionary tabloları içerisinde saklanır.

Aşağıdaki sorguyu inceleyelim;
(continue reading…)

106 total views, 2 views today


Oracle Veritabanında SQL İzleme Yöntemleri


Oracle veritabanında çalıştırılan her SQL sorgusu, bir çalıştırma planı (execution plan) doğrultusunda işletilir. Bu plan ile, hangi indekslere (varsa ve uygunsa) erişileceği, hangi tip “join” işlemlerinin gerçekleştirileceğine karar verilir. Çalışma planı, bir yerden bir yere giderken izlenecek birçok yol arasında en hızlı ulaşımı sağlayacak güzergahın seçilmesi olarak da düşünülebilir.
İyi çalışan bir sorgu öncelikle kullanıcıya en uygun sürede hizmetin verilmesi için gereklidir Öte yandan, mevcut donanım kaynaklarının verimli şekilde kullanımı için de sorguların iyi çalışması gerekmektedir. Kötü çalışan bir sorgu; disk, bellek ve CPU açısından da darboğazlara yol açabilmektedir. Sorgular üzerinde bazı hallerde yapılacak ufak rötuşlar bile çok önemli performans kazançları sağlayabilmektedir.

Bir SQL sorgusunun iyileştirilmesini çeşitli koşullar tetikleyebilir. Bunlar arasında kullanıcı tarafından işlemin uzun sürdüğü şeklinde yapılan geri bildirimler olabileceği gibi, yapılan izleme, istatistik toplama çalışmaları kapsamında sorgunun fazla kaynak kullandığının tespit edilmesi de yer alabilir. Üzerinde çalışılması gereken sorguya karar verildiğinde, inceleme ve test çalışmalarının, olabildiği ölçüde uygulamadan ve diğer ara katmanlardan bağımsız olarak gerçekleştirilmesi yararlı olacaktır. Buradaki amaç uygulamanın kendi yapısından kaynaklanan farklı işlemleri devre dışı bırakarak, sadece SQL’in optimizasyonuna yoğunlaşılmasıdır. Bu nedenle, kullanılan izleme araçları ile, sorunlu olduğu düşünülen SQL sorgusu tespit edildikten sonra doğrudan sorgu üzerinde çalışılmalıdır.

Sorgularda dikkat edilmesi gereken bir diğer husus da, “literal” veya “bind” kullanımıdır. “Literal”de, aşağıdaki örnekte olduğu gibi, where koşulu içinde bir değer (value) belirtilmiştir. (continue reading…)

448 total views, 8 views today


Oracle Redefinition

Redefiniton Oracle 9i ile Oracle dünyasına tanıtılan DBMS_REDEFINITION paketidir. DBMS_REDEFINITON paketi production ortamlarda veritabanında kesinti sürelerini nerdeyse sıfır denilecek sürelerde tablo’nun storage parametrelerini degiştirmek,farklı bir tablespace e taşımak veya yeni kolonlar eklemek,silmek ve degiştirmek için kullanılabilir. Örnekler verecek olursak ;

  • Lob alanlı yapılarda basic file’dan secure file a geçmek
  • Kolon eklemek, çıkarmak veya değiştirmek
  • Tabloyu partitionlı yapıya geçirmek
  • Tabloyu reorganize etmek
  • Ve tablodaki bütün storage parameterelerini değiştirirken kullanabiliriz.

DBMS_REDEFINITION paketi aslında arka planda aşağıda resimde gösterilen işlemi yapıyor.

Oracle Redefinition Example

 

 

 

 

 

 

  1. Öncelikle bu paketle tablonun Online redefinition işlemine uygun olup olmadığına bakıyor. Bu kontrolü yaparken bizden primary key veya rowid değerine göre kontrol yaptırmamızı isteyecek.
  2. Bu adımda tablonun hedeflediğmiz halini oluştururuz. Aslında bu biraz Create table as select’e benziyor.
  3. Üçüncü adımda ise ana tablomuzdaki verileri yeni oluşturduğumuz tabloya aktarır.
  4. Bu adımda ise ana tablo ile yeni tablo arasında veri anlamında çok fark var ise istediğimiz zaman bu verilerin senkronozisyonunu sağlar.
  5. Son adımda ise tabloya kısa bir süreliğine erişimi kapatarak verilerin senkronozisyonunu sağlar ve daha sonrasında tabloların isimleri yer değiştirir. Böylece amacımızada ulaşmış oluyoruz.

Aslında bütün resmin kısaca bir defa daha üstünden geçersek hedeflediğimiz tabloyu oluştururuz. Daha sonra DBMS_REDEFINITION paketini kullanarak ana tablodaki veriler yeni tabloya atılır aslında burda yapılan işlem insert table(a,b,c) select a,b,c from table işlemidir, tabi bununla birlikte yeni tablo materialized view e çevrilir ve aynı anda ana tablo için materialized view log olusturup tablomuza gelen insert,delete ve update işlemlerini kayit altina alınır. Daha sonrasında tablolarımızı her senkron etme işlemimizde ise materialized view log kullanılarak refresh (fast refresh) edilir. En sonda tabloların ismi rename yapılarak isim değişikliği yapılır.

Aşağıda yapacağım örnekte Lob alan bulunan tablomda compress özelliğini kullanacağım ve bunu yaparken redefinition kullanacağım için çok az kesintim olacak.
(continue reading…)

2,713 total views, 2 views today


Materialized View

Materialized View diğer viewlerden farklı olarak sadece data dictionary de tutulmuyor bundan farklı olarak fiziksel olarak veride tutan view/objedir. Materialized View ile referans aldığımız sql’in o anki verilerini fiziksel olarak tutarız ve ihtiyacımıza göre view ın verisini değişik opsiyonlarla güncelleyebiliriz.

Tekrar edecek olursak viewler bir sql sorgusunun saklanma şeklidir, Materialized Viewler ise hem sql sorgusu hemde veriden oluşmaktadır. Bu nedenle Materialized View verileri replicate(kopyasini almak) etmektedir. Peki replicate neden gerekebilir ?

Aslında daha çok DW uygulamalrında sıkça rastlarız ama bunun dışında veritabanı transferlerindede kullanılabilir. Örneğin salı günkü verilerden yola çıkarak, çarşamba günü rapor hazırlama işlemleri bu şekilde daha hızlı gerçekleştirilebilir. Salı akşamı sorgular çalıştırılır, Materialized Viewler güncellenir, çarşamba günü sorgular çalıştırıldığında Ana tablo yerine bu Materialized View lerden ilgili bilgiler çekilmiş olur. Bu da bizim kaynakları kullanma performansımızı arttıracak. Fakat bu durumda güncel verilerden yararlanmamış oluyoruz, sadece önceki güne ait verilerden yararlanmış oluyoruz. Tabi istersek bunu önleme yöntemleri de mevcut, Materialized View de.

Yani Materialized Viewler daha çok aşağıdaki konulara çözüm olur.

  • Kayıt sayınız artıp, rapor sorgularınız çok geciktiğinde.
  • Birden fazla tablodan sorgu almak sizi zorladığında.
  • Özet tablolarınızı periyodik olarak doldurmak istediğinizde.
  • Anlık olmayan raporlarınızda, yani 1 gün gecikmeli ya da ayda bir verdiğiniz raporlarda veya periyodik güncellenmesi gereken verilerde.

Materialized View oluşturmak için Sintaksis  aşağıdaki gibidir;

- Normal
CREATE MATERIALIZED VIEW view-name
BUILD [IMMEDIATE | DEFERRED]
REFRESH [FAST | COMPLETE | FORCE ]
ON [COMMIT | DEMAND ]
[[ENABLE | DISABLE] QUERY REWRITE]
AS
SELECT ...;
-- Pre-Built
CREATE MATERIALIZED VIEW view-name
ON PREBUILT TABLE
REFRESH [FAST | COMPLETE | FORCE ]
ON [COMMIT | DEMAND ]
[[ENABLE | DISABLE] QUERY REWRITE]
AS
SELECT ...;

(continue reading…)

4,490 total views, 2 views today


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Live Traffic Feed

    Feedjit Widget
  • 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: