Birden fazla MRP?

Merhaba,

Geçtiğimiz günlerde şu şekilde bir soru ile karşılaşmıştım;

"Data Guard replikasyonu ve senkronizasyonu için birden fazla MRP görevi çalıştırılabilir mi?"

Kişisel yorumum hayır, çalıştırılamaz. Açıkçası ben hiç MRP1, MRP2 gibi görevlere rastlamadım. Bir veritabanını açarken, media recovery sırasında parallel işlem yaptırabilirsiniz;

SQL> RECOVER DATABASE PARALLEL X;

Parallel işlemler devreye girerek, media recovery yapacaktır ancak bu işlemler sırasında göreceğiniz Oracle görevi muhtemelen P001 gibi bir isimle yer alacaktır, MRP1.. değil.

Hatta bu konunun tartışıldığı bir forum bulunmakta ve ben de birkaç cümle yazmıştım. Umarım okuyanlar için faydalı olur;

ora_p000_process

Recovery_parallelism parametresi ile MRP arasında hiçbir ilişki bulunmuyor, MRP görevlerinin sayısını da arttırmıyor. P ile başlayan görevler parallel işlem yapmakta olan görevlerdir. data guard replikasyonu için kullanılan görev MRP'dir, P ile başlayan parallel görevler değildir.

Media Recovery Process (MRP) bir komut ile devreye alınıp, yine bir komut ile devreden çıkarılabilir;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; --> MRP görevi sonlandırılır ve media recovery devam etmez.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE [USING CURRENT LOGFILE] DISCONNECT FROM SESSION; --> Eğer bir standby redo log grubunuz varsa using current logfile diyerek, MRP görevini bu komut ile yeniden başlatabilirsiniz.

Dip not: Fiziksel beklemede bulunan bir veritabanını "read only", yani sadece okuma modunda açabilmek için MRP görevini öncelikle sonlandırmanız gerekmektedir. 11g'de bile bunu yapmadan read only olarak veritabanını açamazsınız, sorgu koşamazsınız ve raporlama yapamazsınız.

İyi geceler.

Ogan

Media Recovery Çeşitleri Nelerdir?

Selamlar,

Bir önceki yazımda bir tablespace'i nasıl offline konumuna getirebileceğimizi anlatmıştım. Dikkate alınması gereken bir konu diyebilirim. Bu konunun içerisinde de sıklıkla media recovery'den bahsetmiştim. Peki bu meşhur media recovery nedir?

Media recovery Oracle'ın online dokümantasyonlarında "Backup & Recovery" başlığı altında bulunmaktadır. Bu recovery tipinde Oracle yedeği alır ve redo'ları işler. Bu redo işleme işine media recovery denir. Media recovery aslında datafile'ların recover edilmesi işlemidir de diyebiliriz.

4 çeşit media recovery bulunmaktadır.

* Complete Recovery
* Incomplete Recovery
* Datafile Media Recovery
* Block Media Recovery

COMPLETE RECOVERY

Complete Recovery online redolog'ları ya da bir incremental yedek ile birlikte full veritabanı yedeğini kullanarak datafile'ların recover edilmesi işlemidir. Bunun adına complete (bütün, tamam) denmesinin nedeni ise online redolog'ların da recover işleminde kullanılması. Online redolog'lar dışında tabii ki archivelog'lardan da yararlanılmaktadır. Complete media recovery işlemini genelde datafile hatalarında ya da controlfile problemlerinde kullanılmaktadır.

Eğer complete media recovery'i veritabanı seviyesinde yapmak istiyorsanız;

1) Veritabanı mount modda olmalı.
2) Recover etmek istediğiniz bütün datafile'ların online konumda bulunması gerekiyor.
3) Bütün bir veritabanı yedeğiniz restore ediyorsunuz.
4) Online redolog'ları ve / veya archivelog'ları işliyorsunuz.

Yukarıdaki işleme kısaca restore / recover diyebiliriz. Backup / recover genelde geçen isimlerdir ancak bir yedeği recover etmeden önce restore etmeniz gerekmektedir. Recover komutu ile online redolog veya archivelog'lar işlenerek media recovery tamamlanır ve veritabanı ya da ilgili obje yeniden kullanıma alınır.

Eğer complete media recovery'i tablespace ya da bir datafile'a uygulamak istiyorsanız;

1) Eğer veritabanı açıksa tablespace ya da ilgili datafile'ı offline konumuna getiriniz.
2) Bir yedeği restore ederek datafile'ı recover ediniz.
3) Online redolog'ları ve / veya archivelog'ları işliyorsunuz.

INCOMPLETE RECOVERY

Bir diğer ad olarak "point-in-time recovery" de diyebiliriz. Bu tarz bir media recovery'de elimizdeki yedeğin güncelleği ne yazık ki güncel olmayacaktır. Bir diğer anlamıyla en güncel ancak veritabanı ile birlikte bütün archivelog'ları ya da online log'ların işlenemiyor olması.

Incomplete media recovery'i genelde şu durumlarda kullıyoruz;

1) Bir media hatasından dolayı online redolog'ların tamamen silinmesi ya da bozulması.
2) Kullanıcı hatasına bağlı olarak düşürülmüş ve geri dönülemeyen (bkz. flashback table) hatası.
3) Kaybolan archivelog'lardan dolayı yapılamayan complete media recovery.
4) Control dosyasının kaybolması ya da bozulmasına bağlı olarak yedekle birlikte alınmış control file'dan dönülmesi.

Sonuç olarak redo, archivelog ya da control file'dan herhangi birinin uçması sonucu complete recovery yapma şansınız kalmıyor.

Incomplete recovery ile veritabanını "ALTER DATABASE OPEN" diyerek açamıyoruz çünkü bir complete media recovery gerçekleştirmedik. Bu komut yerine "ALTER DATABASE OPEN RESETLOGS" komutunu göndermemiz gerekmekte. RESETLOGS komutu redolog sıralamasına yeni bir başlangıç vermesi ve sayacını 1 olarak sıfırdan başlatması. OPEN RESETLOGS komutundan önce veritabanını READ ONLY olarak açarak, veritabanının doğru noktada olduğunu kontrol etmemizde fayda olacaktır "ALTER DATABASE OPEN READ ONLY".

Incomplete media recovery başlığı altındaki bir alt başlık;

Tablespace PITR (Point-in-time Recovery)

Bu tipteki bir media recovery'da geçmişteki bir zamana dönerek, tablespace'i kurtarma işlemini gerçekleştiriyoruz.

1) Hatalı bir drop ya da truncate işlemi gerçekleşmiş ise.
2) Bir tablo mantıksal olarak bozulmuş ise.
3) Bir şemanın fiziksel veritabanı ile tutarsız bir zamana döndürülmesinden sonra.
4) Bütün bir veritabanının restore edilmesindense tek bir tablespace'in restore/recover edildiği durumlarda.

TSPITR seçeneğini aşağıdaki durumlarda kullanamayız;

1) SYSTEM ya da UNDO tablespace'ini recover ederken.
2) Herhangi bir şekilde rollback segment içeren tablespace'leri.

Incomplete media recovery seçenekleri arasında;

1) Time-Based Recovery: İlgili veriyi herhangi belirlenen bir zamana döndürerek.
2) Cancel-Based Recovery: Cancel komutunu verdiğiniz zamana kadar döndürerek (Recovery manager ile kullanılmıyor).
3) Change-Based Recovery: Belirlenen bir SCN (System Change Number) döndürerek.
4) Log Sequence Recovery: Verilen bir log sıra numarasına döndürerek (Recovery manager ile kullanılmıyor).

DATAFILE MEDIA RECOVERY

Bu tip media recovery'de datafile ya da controlfile'ın kurtarılması hedeflenmektedir. Bunun dışında bir önceki tablespace konusunda belirttiğim offline methodlarından immediate methodunun kullanımasından sonra shutdown abort gönderilirse datafile media recovery kullanılabilir.

Online redolog'lar dışında archivelog'lar da kullanılabilmektedir. Bu tipte media recovery'de herhangi bir media hatası taranmamaktadır.

BLOCK MEDIA RECOVERY

Block media recovery'nın özelliği veritabanı online ve işlem görmekte iken data bloklarının restore ve recover edilmesidir. Eğer bir datafile'ın sadece birkaç bloğunda hata varsa datafile media recovery yerine block media recovery tercih edilebilir.

Blocke media recovery kullanımı RMAN (Recovery Manager) ile mümkündür.

Media recovery tiplerinden sonra gelen konu ise Recovery Manager ile yedekleme ve yedekten dönme olabilir.

İyi çalışmalar.

Ogan