Oracle Data Guard günlük işletim ve arıza senaryoları (19c / 23ai)
OracleSeviye: İleriSüre: 5 dk (kontrol) – 4 saat (yeniden kurma)Kurulu bir Data Guard (physical standby) yapılandırmasının günlük işletim ve arıza kurtarma runbook'u; kurulum için Data Guard kurulum rehberi kullanılır. Ne yapacağınızdan emin değilseniz 'Durum ve gecikme kontrolü' ile başlayın: salt-okur teşhis sizi doğru senaryoya yönlendirir (planlı switchover, failover, eski primary'yi reinstate, arşiv boşluğu, RECOVER … FROM SERVICE ile ileri sarma, standby'ı yeniden kurma, snapshot standby, apply/read-only, koruma modu/FSFO/observer, datafile ve redo log işleri, standby'dan RMAN yedeği). Her senaryo teşhis → güvenlik ağı → uygulama → doğrulama → sonrası düzenindedir; broker'lı (DGMGRL) ve broker'sız (SQL) yolları, tek instance / Oracle Restart / RAC farklarıyla verir.
Yapı: Primary (tek instance / Oracle Restart / RAC) + physical standby (tek instance / Oracle Restart / RAC) + isteğe bağlı observer
Senaryolar
- Durum ve gecikme kontrolü (her şey yolunda mı?) — Salt-okur: yapılandırma, transport/apply lag, arşiv boşluğu, süreçler ve alert log; hiçbir şey değişmez. Ne yapacağınızdan emin değilseniz buradan başlayın: son adım çıktıya göre doğru senaryoyu söyler.
- Planlı switchover (rolleri değiştir) — Primary ve standby sağlıklı, rolleri planlı olarak değiştirmek istiyorsunuz (bakım, DR tatbikatı, rolleri geri alma); veri kaybı olmaz, uygulama birkaç dakika kesilir. Primary'ye erişebildiğiniz sürece rol değişimi için her zaman bunu seçin.
- Primary kayıp: standby'a failover — Primary'ye erişilemiyor ve geri gelmeyecek (sunucu, depolama, site kaybı); standby primary olur. Geri alınamaz: MaxPerformance'ta son saniyelerin verisi kaybolabilir, eski primary sonra reinstate ya da yeniden kurulum ister. Primary'ye hâlâ erişiyorsanız switchover seçin.
- Failover sonrası eski primary'yi standby olarak geri al (reinstate) — Failover yapıldı, eski primary sunucusu geri geldi; Flashback Database açıksa yeniden kurmadan yeni primary'nin standby'ı yapılır. Yeni primary açık kalır. Flashback kapalıysa ya da pencere yetmezse teşhis adımı yeniden kuruluma yönlendirir.
- Arşiv boşluğu (gap): standby eksik arşiv log bekliyor — v$archive_gap satır dönüyor ya da alert log'da FAL/gap mesajı var; apply bir sequence'ta takıldı. Veritabanları açık kalır. Eksik arşivler hiçbir yerde yoksa formdaki seçimle ileri sarma yoluna geçilir.
- Standby çok geride ya da arşivler yok: ileri sar (RECOVER FROM SERVICE) — Gap'teki arşivler hiçbir yerde yok, NOLOGGING işlemler standby'ı bozdu ya da standby günlerce geride; standby yeniden kurulmadan primary'den artımlı olarak eşitlenir (18c+).
- Standby'ı sıfırdan yeniden kur — Reinstate (flashback yok) ve ileri sarma mümkün değil ya da standby'ın dosyaları/kontrol dosyası kayıp; standby silinip yeniden DUPLICATE edilir. Primary açık kalır ama kurulum bitene kadar korumasızdır (başka standby yoksa).
- Snapshot standby'a çevir / geri al (test için yazılabilir kopya) — Standby'ı geçici olarak okuma-yazma açıp test yapmak, sonra değişiklikleri atıp physical standby'a dönmek istiyorsunuz; primary etkilenmez, redo alınmaya devam eder ama snapshot süresince bu standby failover'a hazır değildir.
- Redo Apply'ı durdur / başlat, apply instance değiştir, read-only aç — MRP'yi bakım için durdurmak ya da yeniden başlatmak, RAC standby'da apply'ı başka instance'a almak veya standby'ı rapor için açmak istiyorsunuz (Active Data Guard lisans uyarısı).
- Koruma modu, Fast-Start Failover ve observer — MaxPerformance / MaxAvailability / MaxProtection arasında geçmek, FSFO'yu açıp kapatmak ya da observer'ı yönetmek istiyorsunuz.
- Datafile, redo log ve standby redo log ekleme / UNNAMED dosya — Primary'ye datafile ya da redo log eklenecek, standby'da UNNAMED dosya oluştu (ORA-01111/ORA-01274) ya da standby redo log eksik.
- Standby'dan RMAN yedeği al — Yedek yükünü primary'den almak için RMAN yedeğini standby'da çalıştırmak ve arşiv silme politikasını buna göre ayarlamak istiyorsunuz.
Başlamadan önce
- Tüm sunucularda oracle kullanıcısının profilinde ORACLE_HOME=…, ORACLE_SID (…RAC'te node'a göre …1, …2 …………) ve PATH tanımlı; sqlplus, rman…, dgmgrl… çalışıyor. Yapılandırma Data Guard kurulum rehberi ile kurulmuş ya da eşdeğer (TNS alias'ları …, …, statik _DGMGRL listener kayıtları, aynı parola dosyası).
- Rollerin girdilerle aynı olduğu doğrulandı: şu an … primary, … physical standby. Değilse (ör. daha önce switchover yapıldıysa) girdilerdeki adları yer değiştirin.
- SYS parolası biliniyor (rol değişimi, uzak instance'ın yeniden başlatılması ve RMAN FROM SERVICE parolalı bağlantı ister). Parolada @, /, " ve boşluk yok.
- Lisans: Data Guard Enterprise Edition'a dahildir. Standby'ı apply sürerken açık kullanmak, standby'da block change tracking ve Far Sync Active Data Guard lisansı ister. Snapshot standby ve apply kapalıyken read-only açma lisans gerektirmez.
- Değişiklik onaylı bir bakım penceresinde; uygulama ve izleme ekipleri haberdar… (bağlantılar birkaç dakika kesilir)….
- Failover kararı yetkili kişi tarafından verildi; eski primary'nin yeniden açılmayacağı (split-brain) garanti altında (sunucu kapalı, ağdan ayrık ya da instance MOUNT'ta tutuluyor).
Rehberin aşamaları
- Durum: yapılandırma, gecikme ve süreçler (salt-okur) — Broker yapılandırmasını ve rol değişimine hazırlığı göster · Primary tarafını SQL ile kontrol et · Standby tarafını SQL ile kontrol et · Alert log'larda Data Guard hatalarını tara · Sonucu yorumla ve doğru senaryoyu seç
- 1. Teşhis: switchover'a hazır mı? — Hazırlığı doğrula (VALIDATE) · Hazırlığı doğrula (SWITCHOVER … VERIFY) · Standby'ın gecikmesini kontrol et
- 2. Güvenlik ağı — Mevcut yapılandırmayı kaydet (primary) · Mevcut yapılandırmayı kaydet (standby)
- 3. Uygulama: switchover — Switchover: … primary olsun (broker) · Switchover'ı başlat (primary → standby) · Yeni primary'yi aç (…) · Clusterware rolünü güncelle (yeni primary) · Diğer instance'ı aç (yeni primary node …: …) · Eski primary'yi standby olarak MOUNT'ta aç (…) …
- 4. Doğrulama — Yeni rolleri ve yapılandırmayı doğrula · Yeni standby'da apply ve gecikmeyi kontrol et
- 5. Sonrası — Uygulama, iş ve izleme kontrolleri
- 1. Teşhis: failover gerçekten gerekli mi? — Primary'ye erişimi son kez dene (standby'dan) · Standby'ın durumunu ve olası veri kaybını değerlendir · Broker'ın gördüğü durumu göster (standby'dan)
- 2. Güvenlik ağı ve kalan redo — Standby'ın mevcut ayarlarını kaydet · Eski primary'yi MOUNT'ta aç ve kalan redo'yu gönder (FLUSH REDO) · Eksik arşivleri elle kopyalayın (broker'sız, mümkünse)
- 3. Uygulama: failover — Failover: … primary olsun (broker) · Redo Apply'ı durdur ve failover'ı yap (SQL) · Yeni primary'yi aç (SQL) · Clusterware rolünü güncelle (yeni primary) · Diğer instance'ı aç (yeni primary node …: …)
- 4. Doğrulama — Yeni primary'yi doğrula
- 5. Sonrası — Yeni primary'nin tam yedeğini al · Eski primary geri gelirse: AÇMAYIN
- Uygulama servisi (rol tabanlı) — Servisi … tarafında tanımla ve başlat (Clusterware) · Servisi … tarafında tanımla (Clusterware) · Servisi ve rol trigger'ını tanımla (Grid yok) · İstemci bağlantı tanımını iki adresle kur
- 1. Teşhis: reinstate mümkün mü? — Yeni primary'yi ve rol değişim SCN'ini kontrol et · Broker durumunu göster (yeni primary) · Eski primary'yi MOUNT'ta aç ve flashback penceresini denetle
- 2. Güvenlik ağı — Eski primary'nin kontrol dosyasını ve parametrelerini kaydet
- 3. Uygulama: reinstate — Eski primary'yi reinstate et (broker) · Diğer instance'ları başlat (eski primary, RAC) · Flashback ile geri sar ve physical standby'a çevir (SQL) · Yeni primary'de … hedefini etkinleştir (SQL) · Redo Apply'ı başlat ve rol değişim kayıtlarını aş (SQL)
- 4. Doğrulama — Yapılandırmayı doğrula · Eski primary'de (yeni standby) apply'ı doğrula
- 5. Sonrası — Rolleri eski haline getirin (isteğe bağlı) ve kök nedeni kapatın
- 1. Teşhis: boşluk nerede, arşivler var mı? — Standby'da boşluğu ve süreçleri göster · FAL bağlantısını ve alert log'u kontrol et (standby) · Eksik arşivler primary'de duruyor mu? · Eksik arşivler RMAN yedeğinde var mı?
- 2. Güvenlik ağı — Standby FRA'sında yer olduğunu doğrula
- 3. Uygulama: eksik arşivleri getir ve kaydet — Arşivler yalnız yedekteyse: primary'ye geri yükle · Eksik arşivleri dosya sistemine kopyala ve standby'a gönder (primary) · Arşivleri standby'da kaydet · Redo Apply'ı yeniden başlat (standby)
- 4. Doğrulama — Boşluğun kapandığını izle (standby)
- 5. Sonrası — Geçici kopyaları sil · Kök nedeni kapatın
- 1. Teşhis: standby ne kadar geride? — Standby'ın SCN'ini ve durumunu göster · Primary'de NOLOGGING işlemleri ve COMPATIBLE değerini kontrol et
- 2. Güvenlik ağı — Standby kontrol dosyasının ve spfile'ın yedeğini al
- 3. Uygulama: standby'ı ileri sar — Redo Apply'ı durdur (standby) · Standby'ı MOUNT'a al… (yalnız 1. instance)… · Standby'ı primary'den ileri sar (RECOVER STANDBY DATABASE FROM SERVICE) · Diğer standby instance'larını başlat · Standby redo log ve flashback durumunu kontrol et · Redo Apply'ı başlat (standby)
- 4. Doğrulama — Gecikmenin kapandığını doğrula
- 5. Sonrası — Kök nedeni kapatın
- 1. Teşhis: yeniden kurmak gerçekten gerekli mi? — Yapılandırmanın ve primary'nin durumunu göster
- 2. Güvenlik ağı — Standby'ın yapılandırma dosyalarını sakla
- 3. Uygulama: sil ve yeniden kur — Standby'ı broker yapılandırmasından çıkar · Primary'de standby hedefini beklet (DEFER) · Eski standby veritabanını sil · Kalan broker, init ve parola dosyalarını temizle · Eski init dosyasını kenara al (standby node …: …) · Standby'ı kurulum rehberiyle yeniden oluştur …