Oracle Sürümleri ve Mimari Seçenekler

Merhaba Arkadaşlar

Geçtiğimiz yazıda Oracle lisans ücretlerine değinerek seçim yapmada önemli olan kriterlerle devam edeceğimizi söyledik. Hangi sürümü neden seçmeliyim, hangi özeliği ekstra olarak kullanmalıyım sorularına yanıt arıyoruz.

Öncelikle en çok bilinen Oracle veritabanı sürümlerine bir göz atalım:

1. Express Edition: Veritabanı özelliklerine dair dikkate değer miktarda kullanım özelliği sunulur. Fakat elbette kısıtlamalarıyla beraber gelir. Bu sürüm ücretsizdir. Ancak, en fazla 4 GB veritabanı boyutuna izin verir. Diğer bir durum ise ticari seçeneklerle kullanımı da mümkündür.
2. Standart Edition: Bu sürümde veritabanı boyutu sınırsız olsa da işlemci kısıtı vardır. En fazla 4 işlemcili sunuculara izin verilir. Bu da küçük ve orta halli şirketler için ideal olabileceğini gösterir. Bütün performans ve yönetim paketleri de bu sürüme dahil edilmez. Sadece RAC teknolojisi kullanılabilir.
3. Enterprise Edition: Büyük ve kurumsal şirketlerin tercihi olabilecek bu veritabanında işlemci, boyut veya paket kısıtlaması yoktur. Bu sürüm elbette çok pahalıdır. Ayrıca sürüme dahil edilmeyen bir kaç özellik de vardır.RAC ve Partitioning bunlardan en çok göze çarpanlarıdır. Ancak yedekleme, kurtarma, aynı anda çalışan sorgular gibi kritik özellikler içerir. Bunun dışında kalan yönetim ve performans paketleri de ayrıca lisans alınarak sürüme dahil edilir. Tuning, Konfigürasyon Yönetimi gibi...

Bunların dışında Standart Edition One ve Personel Edition da vardır ki bunlar çok da ihtiyacınız olmayacak sürümlerdir. 

Şimdi, Oracle'ın sunduğu teknolojik altyapıya bir göz atalım. "Neden Oracle?" sorusu eminim pek çoğumuz henüz mantıklı bir cevap verecek durumda değiliz. Üstelik karşımızda Microsoft SQL Server'ı ucuzluğuyla savunan birisi de varsa, kendimizi çaresiz bulabiliriz. Fakat ücret her zaman en son bakılacak kriter olmalıdır. Yazılımcılar olarak ölçeklenebilirlik, performans en önde gelmelidir. Oracle bu açıdan her türlü ihtiyaca farklı çözümler geliştirmiştir. Örneğin; Data Guard, RAC gibi çözümler farklı ihtiyaçlara cevap verir. Şimdi bunların neler olduğuna bakalım:

• Real Application Clusters (RAC): Bildiğimiz gibi veritabanları güçlü yazılımlardır ve güçlü donanımlar üzerinde koşarlar. Bu güçlü donanımların da fiyatları her şirketin cebine uymaz. Ve tek bir donanımın verebileceği hizmet sınırlıdır(CPU-RAM kapasiteleri). Bu durumlarda birden fazla düşük kapasiteli sunucuyu birleştirerek istediğiniz güçteki donanımı oluşturabilirsiniz. Çünkü RAC teknolojisi bu donanımları sizin yerinize tek bir sunucu gibi çalıştırabilir. Çünkü birazdan bahsedeceğimiz Paylaşımlı Disk Mimarisini kullanır. Bu yapının olduğu bir sunucuya yeni sunucular ekler veya çıkarabilirsiniz. Bununla Yüksek Kullanılabilirlik, Ölçeklenebilirlik, Yönetilebilirlik özelliklerinizi artırırsınız. Ayrıca işletim sistami/donanım bakımı esnasında sunucu üzerindeki instance'lar tek tek kapatılarak kesintisiz hizmete devam edilir. Yani bu yapıda birden fazla instance yürütülebilir anlamına geliyor. Zaten donanımı birleştirmenin asıl amacı da budur. 
• Yüksek Kullanılabilirlik Mimarisi (MAA): Maximum Available Architecture olarak açılır. Bu teknoloji fazlasıyla pahalı olup müthiş performans artışı sağlar. Bildiğimiz gibi standby/yedek veritabanları daima daha düşük kapasiteli donanımlardan seçilir. Bu da uygulamaların stanby veritabanını kullanmaları durumunda performansı etkiler. Fakat eğer MAA kullanıyorsanız RAC teknolojisi ile standby veritabanınız senkronize olarak çalışır ve product ve standby veritabanınız kombine çalışır. Yani eğer product veritabanı için RAC satın aldıysanız artık standby veritabanınızda da RAC var demektir. 
• Standby Veritabanı: Bu veritabanı kullanılabilirlik özelliğinizi artırır. Böyle bir yapıyı kullandığınızda product veritabanındaki işlemlere ait redo bilgileri taşınarak yedek/standby veritabanına sanki işlemler o anda yapılıyormuş gibi uygulanır. Bu da büyük veri dosyalarını kopyalamanın getireceği yavaşlıktan sizi kurtarır ve ana veritabanına yük bindirmez. Ana veritabanının başına gelebilecek tehlikeler durumunda yada bakım esnasında kullanıcıların etkilenmemesi için bu veritabanı ayağa kalkar. Sözü gelmişken Data Guard için ayrı bir madde oluşturmadan burada anlatalım. Bu teknoloji de standby veritabanını otomatik olarak yönetir ve size pek bir iş bırakmaz. Standby veritabanı seçilirken daha ucuz bir donanım seçilebilir ve RAC lisansı alınmayabilir. Yine Oracle'da şöyle bir güzellik daha vardır ki; iki sunucu karşılıklı olarak hem product hem de standby veritabanı olarak kullanılabilir. Bu sayede birisine zarar gelirse diğeri aktif olarak hizmete geçer.
• Bağlantı Havuzu (Shared Pool): Veritabanında kullanıcıların sunucuya bağlanması gerçekten çok pahalı bir işlemdir. Bu farklı algoritmalarla çözülmek istenmiştir. Mesela her transaction açıldığında bağlantı kurulup, kapandığında da kapatılabilir. Fakat bu zahmetli ve sunucuya yük getiren bir seçimdir. Kaldı ki binlerce kullanıcı bu işlemi tekrarlarsa sonuçlar çekilmez olabilir. Buna bir çözüm olarak Oracle bağlantı havuzunu getirmiştir. Bağlantılar açıldıktan sonra kapatılmadan beklemede kalır. Bekledikleri yer önbellekte havuz olarak kullanılan bir bölgedir. O anki aktif işlem hangi kullanıcınınsa o kullanıcıya ait bağlantı buradan çekilir ve işlem tamamlanınca tekrar havuza bırakılır. E-ticaret uygulamaları gibi kesin bir yeri olmayan ve çok kullanıcılı uygulamalar için ideal bir yöntemdir. Ayrıca Oracle 11g ile gelen Database Resident Connection Pooling (DRCP) sistemi de vardır ki bu teknoloji ile uygulama katmanına ait prosesler, sunucu prosesleri ile direkt iletişim kurmazlar. Bu da tahmin edeceğiniz gibi performansı artırır. 
• Dedicated Server: Çok kullanılan ve basit bir yapıdır. Her kullanıcı bağlantısı o kullanıcıya adanan bir proses ile sağlanır. Örneğin 50 kullanıcı o anda sisteme bağlıysa 50 adet proses bu bağlantıları yönlendirir. Çok kullanıcılı sistemler için sıkıntılı bir mimaridir. 
• Shared Server: Çok kullanıcısı olan OLTP tarzı sistemlerde idealdir. Bu sistemde bağlantılar her zaman aktif olarak çalışmaz. Bağlantı süresinin çoğunda beklemede kalırlar. Kullanıcı uygulamaları adanmış prosesler yerine dispatcher prosesi denilen bir prosesle iletişime geçerler. Bu proses gelen istekleri bir istek kuyruğuna yerleştirir ve çıkan sonuçları da bir yanıt kuyruğuna yerleştirir. Sonra da bu sonuçları bağlantıyı talep eden kullanıcıyla paylaşır. Bu bilgiler ise SGA'da tutulurlar. 

Böylelikle en çok ihtiyaç duyulan Oracle mimari seçeneklerini tanımış olduk. Şirketin kullanıcı sayısına ve donanım kapasitesine göre bu seçenekler değerlendirilerek bir sonuca varılır. 

Herkese iyi çalışmalar...