Oracle Database yönetiminde performans, veri güvenliği ve yüksek erişilebilirlik (High Availability) denildiğinde akla ilk gelen bileşenlerden biri Redo Log mekanizmasıdır. Özellikle Data Guard mimarilerinde Standby Redo Log (SRL) dosyalarının doğru yapılandırılması, veri kaybını sıfıra indirmek (Zero Data Loss) için hayati önem taşır.
Bu rehberde, Oracle veritabanlarında Online Redo Log ve Standby Redo Log dosyalarının boyutlandırılması, yedekli (multiplex) mimaride tasarlanması, thread/sequence ilişkisi ve bu dosyaların güvenli bir şekilde drop ve recreate (silip yeniden oluşturma) işlemlerini adım adım ele alacağız.
1. Redo Log Mimarisinde En İyi Pratikler (Best Practices)
Doğrudan komutlara geçmeden önce, altyapıyı doğru tasarlamak gerekir. Sadece dosyaları silip büyütmek yetmez; sistemin sürdürülebilir olması şarttır.
Redo Log Dosya Boyutu Ne Kadar Olmalı?
Redo Log dosyalarının boyutu, sisteminizdeki yazma (DML/DDL) yoğunluğuna göre belirlenir. Oracle’ın önerisi, log dosyalarının saatte 2 ila 4 kez (yani her 15-20 dakikada bir) switch etmesidir (başkasına geçmesi).
- Çok sık log switch olması (örn. dakikada bir),
checkpoint incompletehatalarına ve disk IO darboğazına yol açar. - Çok seyrek switch olması (örn. 5 saatte bir), bir çökme (crash) anında kurtarma (recovery) süresini uzatır.
- Genel Kural: Modern sistemlerde (OLTP yükleri dahil) log boyutları genellikle 1 GB ile 4 GB arasında seçilir.
Aynalama (Multiplexing) ile Yedekli Yapı
Bir veritabanında asla tek bir noktadan hata alınmamalıdır (No Single Point of Failure). Her Redo Log grubunun (Group) en az 2 üyesi (Member) olmalıdır. Bu üyeler mutlaka farklı disk gruplarında (örn. ASM kullanılıyorsa +DATA and +RECO) veya farklı fiziksel disklerde barındırılmalıdır.
RAC (Real Application Clusters) ve Thread Mantığı
Eğer veritabanınız bir RAC (kümeleme) mimarisi ise, her bir instance (düğüm) kendi redo kayıtlarını yazar.
- Thread 1: 1. Instance’a ait log grupları.
- Thread 2: 2. Instance’a ait log grupları.
- Tekil (Single-Instance) mimarilerde ise sadece
Thread 1aktiftir. Log eklerken hangi instance için ekleme yaptığımızıTHREADparametresi ile belirtmemiz gerekir.
2. Mevcut Redo Log Durumunun Analiz Edilmesi
Herhangi bir silme veya değiştirme işlemine başlamadan önce mevcut durumun fotoğrafını çekmeliyiz. SQL*Plus veya SQL Developer üzerinden aşağıdaki sorgularla mevcut yapıyı inceleyebilirsiniz:
-- Redo Log Gruplarının Durumu, Boyutu ve Thread Bilgisi
SELECT group#, thread#, sequence#, bytes/1024/1024 AS mb, members, status
FROM v$log;
-- Üye Dosyaların (Member) Fiziksel Yolları
SELECT group#, member, type FROM v$logfile;Kritik Bilgi (Status Anlamları):
- CURRENT: Şu an aktif olarak yazılan log grubudur. Asla doğrudan silinemez!
- ACTIVE: İçindeki veriler henüz veri dosyalarına (Datafiles) tamamen yazılmamıştır (Checkpoint tamamlanmamış). Silmek için switch ve checkpoint tetiklenmelidir.
- INACTIVE: İçindeki veriler güvenle diske yazılmıştır ve arşivlenmiştir. Silinebilir durumdadır.
3. Online Redo Log Drop ve Recreate Adımları
Varsayalım ki mevcut log boyutunuz 200 MB ve siz bunları mimarinize uygun olarak 2 GB (2048 MB) boyutunda, 2 üye olacak şekilde yeniden yapılandırmak istiyorsunuz.
Adım 1: Yeni ve Büyük Log Grupları Ekleme
Mevcut çalışan sisteme zarar vermemek için önce yeni boyuttaki grupları ekleriz. (Örnek ASM mimarisine göre verilmiştir, dosya yollarını kendi sisteminize göre güncelleyebilirsiniz).
-- Thread 1 (Düğüm 1) için yeni gruplar ekleme (Grup 11 ve 12)
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 11 ('+DATA', '+RECO') SIZE 2G;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 12 ('+DATA', '+RECO') SIZE 2G;
-- Eğer RAC mimarisi ise Thread 2 (Düğüm 2) için de ekliyoruz (Grup 21 ve 22)
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 21 ('+DATA', '+RECO') SIZE 2G;
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 22 ('+DATA', '+RECO') SIZE 2G;Adım 2: Log Switch Tetikleme ve Eski Grupları Boşa Çıkarma
Eski küçük grupları silebilmek için durumlarının INACTIVE olması gerekir. Eğer sileceğiniz grup CURRENT ise log switch yaparız:
-- Aktif logu bir sonraki gruba geçirir
ALTER SYSTEM SWITCH LOGFILE;
-- Kirli verilerin veri dosyalarına yazılmasını (Checkpoint) zorlarız
ALTER SYSTEM CHECKPOINT;v$log sorgusunu tekrar çalıştırarak silmek istediğiniz eski grupların durumunun INACTIVE olduğunu doğrulamalısınız.
Adım 3: Eski Redo Log Gruplarını Silme (Drop)
Durumu INACTIVE olan eski küçük grupları artık güvenle silebilirsiniz:
ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE DROP LOGFILE GROUP 2;Not: Eğer ASM kullanmıyorsanız ve işletim sistemi seviyesinde (O/S) dosya sisteminde çalışıyorsanız, DROP LOGFILE komutu dosyayı veritabanı sözlüğünden siler ancak diskten silmeyebilir. Komuttan sonra fiziksel dosyaları rm veya del ile temizlemeniz gerekebilir. ASM’de ise otomatik silinir.
4. Standby Redo Log (SRL) Yapılandırması ve Recreate İşlemleri
Geldik operasyonun en kritik ve en çok kafa karıştıran sorusuna: Standby Redo Log (SRL) dosyalarını Primary (Prod) tarafta mı, yoksa Standby tarafta mı oluşturacağız?
🚨 Kritik DBA Kuralı: SRL dosyaları, Primary veritabanından gelen anlık redo kayıtlarını yakalamakla görevli olduğu için fiziksel olarak Standby tarafında oluşturulur ve orada çalışır.
Ancak unutmamanız gereken altın bir kural var: Yarın bir gün switchover (rol değiştirme) yaptığınızda, bugünün Primary veritabanı geleceğin Standby veritabanı olacaktır. Eğer Primary tarafına SRL eklemezseniz, rol değişiminden sonra replikasyon anlık (real-time) çalışamaz. Bu yüzden en iyi pratik (Best Practice), bu adımları hem Primary hem de Standby veritabanlarında sırayla uygulamaktır.
Standby Redo Log (SRL) Sayısı Nasıl Hesaplanır? (Altın Formül)
Standby log grubu sayısını belirlerken rastgele bir sayı seçemeyiz. Oracle, Primary taraftaki yükün Standby’a aktarılırken darboğaz (bottleneck) yaşamaması için net bir matematiksel formül sunar:
{Standby Grup Sayısı} = ({Her Thread İçindeki Online Log Grup Sayısı} + 1) * {Toplam Thread Sayısı}
Peki Bu Formüldeki + 1 Nereden Geliyor?
Primary veritabanı harıl harıl çalışırken, o an yazılan aktif log grubu dolduğunda arşivleme (Archiving) süreci başlar. Standby tarafında da RFS (Remote File Server) süreci Primary’den gelen veriyi SRL grubuna yazar.
Eğer Primary’deki grup sayısı ile Standby’daki grup sayısı eşit olursa, Standby tarafı dolu olan bir grubu arşivlerken (diske kalıcı yazarken) Primary’den yeni bir log switch gelebilir. Standby tarafı o an “arşivleme meşguliyeti” yüzünden Primary’yi bekletir ve bu da canlı sistemde (Primary) kilitlenmelere veya yavaşlamalara neden olur.
İşte bu yüzden, Standby tarafında her zaman en az 1 adet fazladan yedek (boş) grup bulunmalıdır.
Gerçek Hayat Örneği: 2-Node RAC Mimarisi İçin Hesaplama
Senaryomuzu şu veriler üzerine kuralım:
- Toplam Düğüm (Node / Thread) Sayısı: 2 (RAC mimarilerinde her node bir thread’dir).
- Node Başına Düşen Online Redo Log (ORL) Grup Sayısı: 3 grup (Yani Thread 1 için 3 grup, Thread 2 için 3 grup var).
- Yedeklilik (Multiplexing): Her grupta 2 üye (Member) olacak (Biri
+DATA, diğeri+RECOüzerinde).
8 GRUP * 2 ÜYE = 16 adet fiziksel dosya (member)
Aşağıdaki adımları uygularken veritabanı rollerine (Primary / Standby) dikkat ederek ilerlemelisiniz:
Adım 1: Mevcut Durumun ve Dosya Yapısının Kontrol Edilmesi
Öncelikle hem Standby hem Primary veritabanlarında mevcut SRL gruplarını ve durumlarını kontrol ediyoruz.
SELECT group#, thread#, sequence#, bytes/1024/1024 AS mb, status FROM v$standby_log;- UNASSIGNED: Grup boşta ve yeni logları kabul etmeye hazır.
- ACTIVE: Primary’den gelen loglar şu an aktif olarak bu gruba yazılıyor.
Adım 2: Standby Tarafında Log Apply (Kurtarma) İşleminin Durdurulması
Eğer aktif bir log apply süreci varsa, SRL dosyalarını silmenize Oracle izin vermez ve ORA-01156 hatası fırlatır. Bu yüzden Standby veritabanında kurtarma sürecini geçici olarak askıya alıyoruz:
SQL
-- Sadece STANDBY veritabanında çalıştırılacak:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;Adım 3: Eski ve Hatalı Boyuttaki SRL Gruplarının Silinmesi (Drop)
Eski küçük veya yedeksiz olan SRL gruplarını siliyoruz. Eğer bir grup ACTIVE durumdaysa, önce Primary tarafta ALTER SYSTEM SWITCH LOGFILE; çalıştırarak o grubun boşa çıkmasını (UNASSIGNED veya INACTIVE olmasını) sağlayabilirsiniz.
SQL
-- Durumu uygun olan eski SRL gruplarını siliyoruz:
ALTER DATABASE DROP STANDBY LOGFILE GROUP 11;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 12;Adım 4: Yeni Standby Redo Log Gruplarının Yedekli Olarak Eklenmesi
Yukarıda 2-Node RAC mimarimiz için hesapladığımız formüle uygun olarak, her grupta 2 üye (biri +DATA, diğeri +RECO disk grubunda) olacak şekilde yeni 8 grubumuzu ekliyoruz.
Bu komutları önce Standby veritabanında, ardından rollerin değişme ihtimaline karşı Primary veritabanında çalıştırın:
-- =========================================================
-- THREAD 1 (Düğüm 1) İçin Standby Redo Log Grupları (4 Grup)
-- =========================================================
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 11 ('+DATA', '+RECO') SIZE 2G;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 12 ('+DATA', '+RECO') SIZE 2G;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 13 ('+DATA', '+RECO') SIZE 2G;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 14 ('+DATA', '+RECO') SIZE 2G;
-- =========================================================
-- THREAD 2 (Düğüm 2) İçin Standby Redo Log Grupları (4 Grup)
-- =========================================================
ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 21 ('+DATA', '+RECO') SIZE 2G;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 22 ('+DATA', '+RECO') SIZE 2G;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 23 ('+DATA', '+RECO') SIZE 2G;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 24 ('+DATA', '+RECO') SIZE 2G;Adım 5: Standby Tarafında Log Apply İşleminin Yeniden Başlatılması
Yeni mimariyi tanımladıktan sonra, Standby veritabanında durdurduğumuz real-time apply mekanizmasını arka planda (disconnect) çalışacak şekilde yeniden tetikliyoruz:
SQL
-- Sadece STANDBY veritabanında çalıştırılacak:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;Son Kontrol (Doğrulama)
İşlem bittikten sonra Standby veritabanında v$standby_log sorgusunu çalıştırdığınızda, tüm grupların yeni boyutuyla (2048 MB) listelendiğini ve Primary’den gelen logların anlık olarak v$managed_standby veya v$dataguard_process üzerinde SRL’lere yazılmaya başlandığını doğrulamalısınız.
Leave a Reply