Dataguard Tarafındaki Datafile ler Nasıl Rename Edilir

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.

http://www.kamilturkyilmaz.com/2010/10/03/datafile-%E2%80%98-in-adini-rename-etme-pathini-degistirme/

Kamil TÜRKYILMAZ 

http://www.kamilturkyilmaz.com/

CRONTAB: You are not Authorized to Use Cron. Sorry.

Crontab dba’ lerin kimi zaman eli ayağı olmaktadır. Crontab, windows’ daki schedule task gibi düşünülebilir, OS seviyesinde, bir takım işlerimizi joblara bağlamak istersek crontab’ dan faydalanırız. Crontab ile ilgili sık kullanılan komutların bazıları ve açıklamaları aşağıdaki gibidir;

crontab -e         = Crontab dosyasını editlemenizi yani joblarınızı tanımlamanızı sağlar,  Eğer daha önce hiç tanımlanmamışsa bu bu komutla create edebilirsiniz.

crontab -l          = Crontab içerisine tanımlanmış olan tüm jobları görüntüleminizi sağlar.
crontab -r         = Crontab dosyasını tamamiyle siler.
crontab -v         = Crontab dosyasını en son hangi userın editlediğini gösterir.

Crontab –e  dediğinizde aşağıdaki bir hata mesajı alırsanız, bu bulunduğunuz userın crontab’ ı editlemesine yetkisi olmadığı anlamına gelir.

”crontab: you are not authorized to use cron.  Sorry.”

Hangi user için crontab’ a yetki vermek istiyorsanız, yapmanız gerekenler;

Root userı ile sisteme bağlanıyoruz,

vi komutu ile /usr/lib/cron/cron.allow dosyasını editleyip içerisine istediğimiz kullanıcı adını yazıp kaydedip çıkıyoruz.

Dosya yok ise create edilmelidir. Sonrasında ilgili user ile sisteme giriş yapıp crontab’ ı kullanabilirsiniz.  Bu aşamadan sonra crontab –l ile crontabı görüntülemeye çalışmak istediğinizde aşağıdaki gibi bir mesaj alırsanız ;

crontab: can’t open your crontab file

Henüz oluşturulmuş bir crontabınız olmadığı anlamına gelirki crontab –e ile dosyayı  editleyebilirsiniz.

Kimi sistemler de

/etc/cron.allow

Dosyasına ilgili userı eklemeniz gerekebilir bilginiz olsun.

Kamil TÜRKYILMAZ 

http://www.kamilturkyilmaz.com/