Oracle veritabanı güçlüdür ama lisanslama, yedekleme, felaket kurtarma ve performans yönetimi uzmanlık ister. Sanallaştırma ortamında lisans riskleri, RMAN, Data Guard, yama yönetimi, AWR ve dış kaynak DBA modelini sade bir dille anlatıyoruz.
Oracle Database, bankacılıktan üretime, kamudan perakendeye kadar pek çok kritik uygulamanın arkasında çalışır. Güçlü, olgun ve esnek bir platformdur. Ama bu gücün bir bedeli vardır: doğru lisanslanmadığında ciddi mali riskler doğurur, doğru yedeklenmediğinde felaket anında beklenmedik sürprizler çıkarır, doğru izlenmediğinde de performans sorunları iş süreçlerini yavaşlatır.
Bu yazıda Oracle veritabanı yönetiminin dört temel alanını, yani lisans, yedekleme, performans ve destek konularını ele alıyor; tam zamanlı bir DBA istihdam etmek ile dış kaynak DBA hizmeti almak arasındaki farkı tartışıyoruz.
Oracle Lisanslama: En Çok Gözden Kaçan Risk
Oracle lisanslaması teknik bir konu gibi görünmez ama altyapı kararlarını doğrudan etkiler. Kurulum yapmak teknik olarak çok kolaydır; lisans gereksinimini doğru hesaplamak ise uzmanlık ister.
Sürümler ve Metrikler
Genel olarak Oracle Database, Standard Edition 2 ve Enterprise Edition olarak sunulur. Lisanslama işlemci (processor) veya adlandırılmış kullanıcı (Named User Plus) metrikleriyle yapılabilir. Standard Edition 2'nin çalıştırılabileceği sunucu kapasitesine dair sınırlar vardır. Enterprise Edition ise daha geniş özellikler sunar ve birçok gelişmiş özellik ayrıca lisanslanan opsiyon ve paketlerle gelir.
Sanallaştırma Ortamında Dikkat
En büyük riskler genellikle sanallaştırmada ortaya çıkar. Oracle, bazı sanallaştırma teknolojilerini lisans açısından sınırlayıcı bir bölümleme olarak kabul etmeyebilir. Bu durumda yalnızca Oracle'ın çalıştığı sanal makinenin işlemci sayısı değil, o sanal makinenin çalışabileceği fiziksel sunucuların tamamı lisans hesabına dahil edilebilir. Geniş bir sanallaştırma kümesinde bu, beklenenden çok daha yüksek bir lisans ihtiyacı anlamına gelebilir.
Kurallar, sözleşmenize, kullandığınız sanallaştırma teknolojisine ve güncel lisans politikalarına göre değişebilir. Bu yüzden Oracle'ı sanal bir ortama taşımadan veya yeni bir küme kurmadan önce mutlaka uzman bir lisans danışmanından görüş almanızı öneririz. Teknik ekip olarak bizim rolümüz, Oracle iş yüklerini lisans açısından izole edilebilecek şekilde konumlandırmanıza ve mimari seçenekleri karşılaştırmanıza yardımcı olmaktır.
Özelliklerin Lisansla İlişkisi
Bazı araçlar kurulumla birlikte gelir ama kullanımları ayrı lisans gerektirir. Örneğin performans analizinde sık kullanılan bazı tanılama araçları Enterprise Edition üzerinde ek bir paket lisansı ister. Farkında olmadan bu özellikleri kullanmak, bir lisans denetiminde sorun yaratabilir. İyi bir DBA, hangi özelliğin hangi lisansla kullanılabileceğini bilir ve ortamı buna göre yapılandırır.
Yedekleme: RMAN ile Doğru Strateji
Oracle'ın yerleşik yedekleme aracı RMAN (Recovery Manager), tutarlı ve geri yüklenebilir yedekler almanın standart yoludur. Veritabanı dosyalarını işletim sistemi seviyesinde kopyalamak, veritabanı açıkken güvenilir bir yöntem değildir.
Sağlıklı bir RMAN stratejisi genellikle şunları içerir:
- ARCHIVELOG modu: Veritabanının arşiv günlüklerini tutması, belirli bir ana kadar geri dönüşü (point-in-time recovery) mümkün kılar. Üretim veritabanlarında neredeyse her zaman gereklidir.
- Tam ve artımlı yedekler: Haftalık seviye 0 ve günlük seviye 1 artımlı yedekler yaygın bir başlangıç modelidir.
- Arşiv günlüğü yedekleri: Gün içinde sık aralıklarla alınarak veri kaybı penceresi daraltılır.
- Kontrol dosyası ve parametre dosyası yedekleri: Otomatik kontrol dosyası yedeği açık olmalıdır.
- Saklama politikası: Ne kadar geriye dönebileceğinizi belirler ve eski yedeklerin düzenli temizlenmesini sağlar.
RMAN yedeklerinin bir kopyası mutlaka sunucu dışına, tercihen değiştirilemez bir depolamaya taşınmalıdır. Fidye yazılımı ya da yanlış bir komut, sunucudaki yedekleri de yok edebilir. Bu genel prensipleri 3-2-1 yedekleme kuralı yazımızda anlattık.
Son olarak: yedeklerin doğrulanması ve düzenli aralıklarla ayrı bir ortama geri yüklenerek test edilmesi şarttır. RMAN'ın doğrulama komutları faydalıdır ama gerçek bir geri yükleme testinin yerini tutmaz.
Felaket Kurtarma: Data Guard
Yedekten geri dönüş, büyük veritabanlarında saatler sürebilir. Kritik sistemler için daha kısa kesinti süreleri hedefleniyorsa Oracle Data Guard devreye girer. Data Guard, birincil veritabanındaki değişiklikleri sürekli olarak bir yedek (standby) veritabanına taşır. Birincil tarafta sorun olduğunda standby veritabanı kısa sürede devreye alınabilir.
- Fiziksel standby: Birincil veritabanının blok seviyesinde bir kopyasıdır ve en yaygın kullanılan modeldir.
- Koruma modları: Performans ile sıfır veri kaybı arasında farklı dengeler sunar. Seçim, iki lokasyon arasındaki mesafeye ve ağ gecikmesine göre yapılmalıdır.
- Planlı geçiş (switchover) ve felaket geçişi (failover): Her ikisinin de düzenli olarak test edilmesi gerekir.
Data Guard, Enterprise Edition ile kullanılabilen bir özelliktir; standby veritabanını raporlama gibi işler için açık tutmak gibi bazı gelişmiş kullanımlar ise ek lisans gerektirebilir. Standard Edition 2 kullanan ortamlarda ise arşiv günlüklerinin manuel veya üçüncü taraf araçlarla taşınmasına dayanan alternatif yöntemler değerlendirilebilir. Standby veritabanını farklı bir veri merkezinde konumlandırmak, felaket kurtarma planının temelidir.
Yama Yönetimi
Oracle, güvenlik açıklarını ve hataları gideren yamaları düzenli aralıklarla yayımlar. Yamaları uzun süre ertelemek güvenlik riskini artırır; plansız uygulamak ise uygulamayı bozabilir. Dengeli bir yama süreci şu adımları içerir:
- Yayımlanan yamaların ortamınızla ilgisini değerlendirmek.
- Önce test ortamında uygulamak ve uygulama ekibiyle doğrulamak.
- Üretimde bakım penceresi planlamak ve geri dönüş adımlarını hazırlamak.
- Data Guard kullanan ortamlarda standby tarafı önce yamalayarak kesintiyi azaltmak.
- Destek süresi biten sürümleri takip edip yükseltme planı yapmak.
Performans Yönetimi
Performans şikayetleri genellikle "sistem yavaş" cümlesiyle gelir. Sorunun kaynağı veritabanı, uygulama, depolama ya da ağ olabilir. Doğru teşhis için ölçüm gerekir.
- AWR ve ASH raporları: Enterprise Edition üzerinde, ilgili tanılama paketi lisansıyla, belirli bir zaman aralığında veritabanının neyle meşgul olduğunu ayrıntılı gösterir. Lisansınız uygun değilse Statspack gibi alternatifler kullanılabilir.
- Bekleme olayları (wait events): Veritabanının zamanını nerede harcadığını gösterir. Disk okuma, kilitlenme ya da ağ beklemeleri farklı çözümler gerektirir.
- SQL ayarlama: Yavaşlığın büyük kısmı genellikle birkaç sorgudan gelir. Eksik bir indeks ya da kötü bir yürütme planı, donanım eklemekten çok daha ucuz çözülür.
- Bellek ve depolama: SGA ve PGA ayarları ile depolamanın gecikme değerleri düzenli izlenmelidir.
Performans çalışmasının amacı, donanım bütçesini büyütmeden önce mevcut kaynakların doğru kullanıldığından emin olmaktır. Bu, özellikle çekirdek başına lisanslanan Oracle ortamlarında doğrudan maliyet tasarrufu anlamına gelir.
İzleme ve Proaktif Kontroller
İyi yönetilen bir Oracle ortamında sorunların çoğu, kullanıcılar fark etmeden yakalanır. Düzenli izlenmesi gereken başlıca noktalar şunlardır:
- Tablespace ve arşiv günlüğü alanlarının doluluk oranı
- Yedek işlerinin başarı durumu
- Data Guard senkronizasyon gecikmesi
- Alert log içindeki hata kayıtları
- Uzun süren oturumlar ve kilitlenmeler
- Kullanıcı hesapları, yetkiler ve parola politikaları
Güvenlik ve Erişim Yönetimi
Veritabanları, saldırganların asıl hedefidir. Oracle ortamlarında sık karşılaşılan güvenlik açıkları genellikle karmaşık değildir: varsayılan şifresi değiştirilmemiş hesaplar, gereğinden fazla yetkiye sahip uygulama kullanıcıları ya da tüm ağa açık bırakılmış dinleyici (listener) portları. Temel önlemler şunlardır:
- Kullanılmayan varsayılan hesapları kilitlemek ve güçlü parola politikası uygulamak
- Uygulama kullanıcılarına sadece ihtiyaç duydukları yetkileri vermek
- Veritabanı portlarına erişimi güvenlik duvarıyla sadece uygulama sunucularına sınırlamak
- Kritik işlemler için denetim (audit) kayıtlarını açmak ve düzenli incelemek
- Yedekleri ve hassas verileri şifrelemek; şifreleme özelliklerinin lisans gereksinimlerini önceden kontrol etmek
Kendi DBA'nız mı, Dış Kaynak DBA mı?
Tam zamanlı deneyimli bir Oracle DBA bulmak ve elde tutmak zordur. Tek bir kişiye bağımlı olmak da ayrı bir risktir: izin, hastalık ya da ayrılık durumunda kritik bilgi kaybolabilir. Dış kaynak DBA modeli bu sorunları farklı şekilde çözer:
| Konu | Kurum İçi DBA | Dış Kaynak DBA Hizmeti |
|---|---|---|
| Uzmanlık genişliği | Tek kişinin deneyimiyle sınırlı | Ekip olarak farklı senaryolarda deneyim |
| Süreklilik | İzin ve ayrılıkta risk | Yedekli ekip, dokümante süreçler |
| Maliyet | Tam zamanlı maaş ve eğitim giderleri | İhtiyaca göre kapsamlanmış hizmet |
| Mesai dışı destek | Nöbet düzeni kurmak zor | Hizmet seviyesine göre tanımlı |
| Kurum bilgisi | Çok yüksek | Zamanla oluşur, dokümantasyonla desteklenir |
Birçok kurum için en verimli model hibrittir: uygulamayı iyi bilen bir iç ekip ve rutin bakım, yedekleme, izleme ve acil durumlar için dış kaynak DBA desteği. Farklı veritabanı motorları için yönetilen hizmet seçeneklerini veritabanı yönetim hizmetleri rehberimizde anlattık.
Sık Sorulan Sorular
Oracle'ı bulutta çalıştırmak lisans maliyetimi artırır mı?
Bu, kullanılan altyapıya ve lisans sözleşmenizin koşullarına bağlıdır. Bazı ortamlarda doğru mimariyle maliyet kontrol altında tutulabilir, bazılarında ise beklenmedik bir artış olabilir. Taşıma kararından önce lisans danışmanından görüş almanızı öneririz.
RMAN yerine sanal makine yedeği yeterli mi?
Sanal makine yedeği, tüm sunucuyu geri getirmek için faydalıdır ama Oracle için tek başına önerilmez. RMAN, belirli bir ana geri dönüş ve blok seviyesinde doğrulama gibi veritabanına özgü yetenekler sunar. İkisinin birlikte kullanılması en sağlıklı yaklaşımdır.
Data Guard her ortam için gerekli mi?
Hayır. Gerekliliği, sistemin ne kadar süre kesinti kaldırabileceğine bağlıdır. Birkaç saatlik kesintinin kabul edilebildiği sistemlerde iyi test edilmiş RMAN yedekleri yeterli olabilir.
Dış kaynak DBA hizmetinin fiyatı nasıl belirlenir?
Veritabanı sayısına, boyutuna, kritikliğine ve beklenen destek saatlerine göre kapsamlanır. CloudRUX'ta veritabanı hizmetleri ihtiyaca göre teklif edilir.
CloudRUX Oracle Veritabanı Hizmetleri
Oracle ortamınızı çalıştırmak için bir sunucu herkesten alınabilir; asıl değer, yedeklerin test edildiğinden, yamaların planlı uygulandığından ve bir sorun olduğunda karşınızda sistemi tanıyan bir mühendis bulunduğundan emin olmaktır. CloudRUX, Türkçe konuşan mühendisleriyle Oracle ve diğer veritabanı platformları için izleme, yedekleme, performans ve felaket kurtarma hizmeti sunar; veriniz Türkiye'de kalır. Ayrıntılar için veritabanı çözümleri sayfamızı inceleyebilir, ortamınıza özel değerlendirme için bizimle iletişime geçebilirsiniz.