Oracle Database 12c Multitenant/Container veritabanı mimarisi ve mantığı

Oracle, 12 cloud veritabanını 25 Haziran 2013 itibari ile yayınlamış durumda. RMAN, ASM, RAC, Dataguard vb. birçok başlıkta yenilikler mevcut. Multitenant yani kiracılı veritabanı mimarisi ile konteynır mantığı 12c nin öne çıkan yeni özellikleri olarak görülüyor.

Konteynır mantığı ile bir çok pluggable veritabanını barındıran tek bir instance yaratılmış. Bundaki amaç her bir instance için kullanılmasa bile yaratılmakta olan background processlerinin kaynak kullanımını minumuma indirgemek. Tek bir instance altında yaratılan (konteynır) bir çok PDB (pluggable database) aynı background processlerini kullanıyor.

Tabiiki Non-CDB yani bildiğimiz instance mantığı hala geçerli.


CDB yani container database mimarisi kullanımı zorunlu değil fakat eğer kullanırsak getireceği artılardan birkaç tanesi:

1- Daha az kaynak kullanımı
2- Yüksek performans
3- Patch ve upgrade kolaylığı (Tek bir instance a geçilen patch yada upgrade bütün PDB leride etkiler, dolayısıyla 1 upgrade yada patch ile 10larca PDB yi aynı anda güncellemiş oluruz)
4- Tek instance altında schema mantığı yerine tek instance altında bir çok pluggable database (Yönetim açısından kolaylık)

Yönetim açısından kolaylık çünkü herbir pluggable database aslında tek bir konteynır altında toplanıp o konteynırın kaynaklarını kullansada, ayrı bir database gibi kapatılabilir, nomount, mount, open mode lara getirilebilir, backup/restore, export/import gibi yedekleme işlemleri gerçekleştirilebilir. Eğer konteynır kapatılırsa bütün PBD ler kapanır. Eğer konteynır açılırsa sadece konteynır açılır, PDB ler mount mode da kalır. Bu bir sorun gibi gözüksede bir event trigger ı yazarak konteynır açıldığı zaman PDB lerinde açılmasını sağlayabiliriz.

Daha sonraki yazılarımda CDB ve PDB mimarilerini örneklerlede anlatıyor olacağım.

Oracle Database 12c Architecture

Oracle Database 12c mimarisi haliyle biraz değişti. Yeni background process ler, memory alanları var. Bunları detaylı bir şekilde inceliyor olacağız.

Oracle Database 12c Architecture

Bu arada 12c New Features eğitimini Eylül 2013 itibari ile Bilginç IT Academy vermeye başlıyoruz.
bilginize.

SQL ve Tuning

‘SQL Tuning’, hem Database Adminler hem de Developerlar için olmazsa olmaz kavramlar arasındadır. Sistem performansı açısından admin ve developerların sürekli iletişim içerisinde bulunup, sisteme yük getiren sorguların tune edilmesini sağlamaları gerekmektedir.

SQL Tuning’in temel prensipleri arasında kendimize bir tuning metodolojisi belirleyip bu metodolojiyi takip etmek geliyor. Bizim tune işlemindeki öncelikli hedeflerimiz arasında response time’ı en aza indirgemek ve kaynak kullanımını minimalize etmek gelmelidir. Bunları yapabilmemiz için ise özellikle Oracle 11g ile birlikte çok gelişmiş bir ara yüze sahip olan Enterprise Manager bize yardımcı olacaktır. Enterprise Manager ile birlikte ADDM (Automatic Database Diagnostics Management), Top SQL Raporları ve dinamik performans viewlarını effektif bir şekilde kullanabilir ve sistemimizin son durumunu kontrol altında tutabiliriz. Özellikle manuel değilde otomatik tuning yapıyorsak SQL Tuning Advisor ve SQL Access Advisor hertürlü detayı gözler önüne seriyor.

Automatic Database Diagnostics Management sistemimizdeki SQL’lerin alınmış olan istatistiklerini inceler, tavsiyelerde bulunur, high load SQL’leri listeler. AWR raporları sayesinde istediğimiz zaman sistemimizin geçmiş dönemlerdeki performanslarını mukayese etme olanağı sağlar.

Özellikle Oracle 11g ile birlikte istatistiki verilerin önemi bir kat daha artmış durumdadır. Arka planda çalışan istatistikler sayesinde kendi en iyi execution planını çıkarıp, aynı sorgular geldiği zaman bu planı defalarca kullanıp bize istediğimiz minimal response time ve resourse usage’ı sağlayabiliyor. Fakat bu şu demek değildir: her zaman kendi oluşturduğu execution plan en iyisidir. Bu tamamıyle arz talep kavramına dayalı göreceli bir kavramdır. Nedeni ise; Oracle Optimizer’ı ‘cost base’ dir. Yani yaptığı her işi en düşük cost ve ortalama minimum süre için yani optimal cost’a göre hesaplar ve bu doğrultuda execution planını oluşturur ve uygular. Fakat bizim için costun değilde zamanın daha değerli olduğu durumlarda mevcut olacaktır elbet. İşte bu gibi durumlarda da yardımımıza ‘hint’ ler yetişiyor. Hint kavramı bize kendi execution planını değilde, bizim force ettiğimiz planı uygulaması gerektiğini söyler ve kullandırır. Aslında bir bakıma kılavuzluğu biz elimize almış oluruz. O yüzden dikkatli olmakta fayda var.

Buarada SQL Tuning Advisor ve SQL Access Advisor’ıda kullanmayı unutmamalıyız. Kötü yazılmış SQL Statementlarımızı daha iyi nasıl yazabilirizi örneklerle bize gösteriyor. Tavsiye ettiği SQL’leri uygun bulursak kullanabiliriz.

Aslına bakılıcak olursa cost ve time arasında bir karar vermemiz gerekir. Şundan emin olabilirizki en düşük cost’u Oracle bize default olarak sunuyor.