Dataguard ortamları çoğu zaman donamım gereksinimleri bakımından production ile birebir olamıyabiliyor (ki uygulamaların birçoğuda bu şekilde) gerek memory gerekse disk kapasiteleri bakımından dataguardın bağlı bulunduğu sunucular productiondan geride oluyor. Durum böyle olunca dataguard tarafını kontrol etmeden production ortamına eklenen datafile’ ler, DG tarafında create edilemediğinden hata alınıyor, sonrasında MRP processesi artık DG tarafında çalışmadığından senkronizasyon duruyor. Bu tarz bir durumla karşılaştığımızda neler yapmamız gerekeceğinden bahsetmek istiyorum.
Öncelikle böyle bir durumla karşılaştığımızda alert logda alacağımız hatayı görelim ;
Thu Jun 16 12:08:18 2011
MRP0: Background Managed Standby Recovery process started (test)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1111
Thu Jun 16 12:08:23 2011
Errors in file /u01/oracle/test/bdump/test_mrp0_8661.trc:
ORA-01111: name for data file 32 is unknown – rename to correct file
ORA-01110: data file 32: /oracle/10g/dbs/UNNAMED00032′
ORA-01157: cannot identify/lock data file 32 – see DBWR trace file
ORA-01111: name for data file 32 is unknown – rename to correct file
ORA-01110: data file 32: /oracle/10g/dbs/UNNAMED00032′
Logdan da görüleceği üzere 32 nolu dbf, prod ortamına create edilmiş ancak ordaki dizin DG tarafında olmadığı için (benim örneğimde dizin var ama klasör yoktu) bu datafile’ i dbf altına UNNAMED olarak atayarak MRP processesini sonlandırmış. Burada yapmamız gereken bu datafile’ leri prod ortamdan bağlı bulunduğu tablespace’ leri backup moda alarak DG tarafına kopyalamak ve rename etmek olacak. Adım adım gidelim ;
Production ortamda ;
Datafile’ in hangi tablespace’ e ait ise o tablespace’ i backup moda alıyorum.
ALTER TABLESPACE deneme BEGIN BACKUP;
Sonra ilgili dbf’ i DG tarafına scp (rcp veya ftp) ile DG tarafına kopyalalıyoruz. Primary tarafındaki işlemlerin aksamaması için kopyalama biter bitmez Production da tablespace’ i backup moddan çıkartıyoruz.
ALTER TABLESPACE deneme END BACKUP;
Primary tarafındaki işimiz bu kadar, sonrasında DG tarafında recover işlemini durduruyoruz;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
DG’ da file management parametresini manual olacak şekilde set ediyoruz.
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
Database mount modda değilse, kapatıp mount modda açıyoruz;
STARTUP MOUNT;
Hatalı olan dbf’i rename ediyoruz;
ALTER DATABASE RENAME FILE ‘/u01/ oradata/test01.dbf’ TO ‘/u01/oradata/standby/test01.dbf’;
Ve apply işlemini başlatabiliriz artık ;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
BU şekilde hatalı olarak oluşturulmuş başka datafile’ ler var ise sırası ile tüm datafile’ ler için aynı işlemler tekrar edilmelidir. Sorunlu datafile’ lerin listesi DG tarafına
Select name from v$datafile ;
Sorgusu ile select edildiğinde ilk hata veren dbf ‘ e ait bilgiler görüntülenecektir. Birini düzelttikden sonra apply başlatıldığında bu sefer diğeri için aynı hatayı verecek dolayısıyla yukarıdaki script artık ikinci hatalı olan datafile’ i gösteriyor olacaktır.
Production tarafında herhangi bir rename işlemi yapmadık , ki bunun nasıl yapılması gerektiğinden daha önce bahsetmiştim.
