Oracle Data Guard mimarisi, yüksek erişilebilirlik ve felaket kurtarma senaryoları için tasarlanmış olsa da, doğru kullanıldığında güçlü bir test altyapısı da sunar. Özellikle Oracle 19c ile birlikte snapshot standby özelliği, production verisinin birebir kopyası üzerinde yazma işlemleri yapabilmeyi mümkün kılar.
Bu yazıda, physical standby veritabanını snapshot standby moduna çevirerek teknik olarak nasıl izole bir TEST ortamı oluşturabileceğinizi ve sonrasında redo apply mekanizmasını bozmadan tekrar physical standby moduna nasıl döneceğinizi detaylı şekilde inceleyeceğiz.
Snapshot Standby Mimarisi Nasıl Çalışır?
Physical standby veritabanı normalde primary veritabanından gelen redo log’ları apply ederek birebir senkronizasyon sağlar. Ancak snapshot standby moduna geçildiğinde:
- Redo apply işlemi durdurulur ( alter database recover managed standby database cancel; )
- Guaranteed restore point oluşturulur ( Bu 19c 'de convert to snapshot standby komutuyla otomatik olarak oluşturulur.)
- Veritabanı read-write moda geçirilir ( alter database open; )
Bu sayede veritabanı, transaction kabul edebilir hale gelir. Ancak arka planda Data Guard ilişkisi korunur.
En kritik nokta: Snapshot modundan çıkıldığında veritabanı restore point’e geri döndürülür ve tüm test değişiklikleri discard edilir.
Snapshot Standby Kullanımında Kritik Noktalar
- Flashback Database özelliği aktif olmalıdır
- Yeterli FRA (Fast Recovery Area) alanı bulunmalıdır
- Uzun süre snapshot modda kalmak redo backlog oluşturur.
- Primary ile lag süresi artar
Ayrıca snapshot standby sırasında oluşan archive log’lar apply edilmez, bu nedenle dönüş sonrası apply süresi uzayabilir.
Physical Standby → Snapshot Standby Geçiş Süreci
1. Redo Apply Sürecini Durdurma
alter database recover managed standby database cancel;
Bu komut Managed Recovery Process (MRP)’i durdurur. MRP aktif olduğu sürece veritabanı snapshot moda geçirilemez.
2. Veritabanını Kapatma
shut immediate;
Instance seviyesinde temiz shutdown yapılır. Bu adım sırasında aktif session’lar rollback edilir.
3. Mount ile Başlatma
startup mount;
Control file yüklenir ancak datafile’lar open edilmez. Snapshot dönüşümü için gerekli state budur.
4. Snapshot Standby’e Dönüştürme
alter database convert to snapshot standby;
Bu işlem sırasında Oracle:
- Otomatik olarak guaranteed restore point oluşturur
- Standby redo log akışını durdurur
- Veritabanını read-write moda hazırlayan internal flag’leri set eder
5. Database Open
alter database open;
Bu noktadan sonra veritabanı read-write modda çalışır. Artık primary’den bağımsızdır.
6. Test İş Yüklerinin Çalıştırılması
@after_clone.sql
Test ortamı oluşturulduktan sonra TEST ortamında olması gereken değişiklikleri bir sql dosyasına ekleyip, buları çalıştırıyoruz. Tipik kullanım senaryoları:
- DDL operasyonları (index rebuild, partition değişiklikleri)
- DML testleri (bulk insert/update)
- Execution plan analizleri
- Patch/upgrade öncesi validasyon
Bu ortam production verisinin birebir kopyası olduğu için sonuçlar oldukça gerçeğe yakındır.
Snapshot → Physical Standby Geri Dönüş
Test tamamlandıktan sonra veritabanının tekrar Data Guard yapısına dahil edilmesi gerekir.
1. Instance Shutdown
shut immediate;
2. Mount Mode
startup mount;
3. Physical Standby’e Dönüşüm
alter database convert to physical standby;
Bu adımda:
- Veritabanı guaranteed restore point’e flashback edilir
- Snapshot sırasında yapılan tüm değişiklikler silinir
- Redo apply için hazır hale gelir
4. Instance Restart
shut immediate;
startup mount;
5. Redo Apply Yeniden Başlatma
alter database recover managed standby database disconnect from session;
MRP tekrar başlatılır ve veritabanı primary ile senkronize olmaya başlar.
Performans ve Operasyonel Avantajlar
Bu yaklaşımın klasik RMAN clone yöntemlerine göre avantajları:
- Ek storage ihtiyacı minimumdur
- Clone süresi yoktur (anlık dönüşüm)
- Production ile veri tutarlılığı maksimumdur
- Otomasyon için uygundur
Özellikle CI/CD pipeline’larında database test aşaması için snapshot standby oldukça etkili bir çözümdür.
Sonuç
Oracle 19c snapshot standby özelliği, Data Guard altyapısını sadece DR değil aynı zamanda gelişmiş test senaryoları için de kullanılabilir hale getirir. Doğru konfigürasyon ve dikkatli kullanım ile hem güvenli hem de hızlı bir test ortamı elde edebilirsiniz.