Tüm Redolog Dosyalarının Kaybolması Durumunda Yapılabilecekler

Redolog dosyalarının yer aldığı dizinin bir şekilde silindiği veya bulunduğu disk’e artık erişim olmadığı durumda neler yapabileceğimizden biraz bahsetmek istiyorum. Bu tarz bir durum yaşandığında database’ e uygulama üzerinde connection kurmaya çalışan userlar aşağıdaki hatayı almaya başlayacaklardır;

ORA-00257: archive error. Connect internal only, until freed.

Sunucu üzerinden database’ e erişim yapılabilmekte ancak alertlogu kontrol ettiğimizde db’ in sürekli olarak aşağıdaki hatayı verdiğini görürüz;

ORA-01624: log 3 needed for crash recovery of instance PROD (thread 1)
ORA-00312: online log 3 thread 1:
‘/u01/app/product/11.2/onlinelog/redo03.log’

Redologlar, database’ in işleyişinde olmazsa olmaz file’ lerden biridir. Dolayısıyla bu dosyaların silinmiş olması database’ i kullanılamaz noktasına getirmiştir. Database open modda iken durum farkedildiğinden dolayı, öncelikle rman üzerinden full bacup alarak sonrasında recover etmeyi deneyelim;

Rman> backup database;

Starting restore at 13-JUL-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /oradata/PROD/system01.dbf
restoring datafile 00002 to /oradata/PROD/undotbs01.dbf
restoring datafile 00003 to /oradata/PROD/sysaux01.dbf
restoring datafile 00004 to /oradata/PROD/users01.dbf
channel ORA_DISK_1: reading from backup piece /backup/PROD/backup_prod_ccmhbth2_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/backup/PROD/backup_prod_ccmhbth2_1_1 tag=TAG20110713T185946
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 13-JUL-11
RMAN>

Backup aldıkdan sonra database zaten mount modda olduğundan dolayı restore database komutunu ardından aşağıdaki komut ile recover işlemini başlatıyoruz (öncesinde redologların bulunduğu dizini işletim sisteminde create ediyoruz) ;

SQL>recover database using backup controlfile until cancel;
Specify log: {=suggested | filename | AUTO | CANCEL}

CANCEL
Media recovery cancelled.

Komutu çalıştırdıkdan sonra sizden recover işlemini nasıl yapmak istediğini soracaktır. AUTO opsiyonunu seçerseniz varolan son archive kadar tüm logları apply edecektir. CANCEL opsiyonunu seçtiğiniz takdirde recover işlemini bulunduğu noktada sonlandıracaktır. Biz backupı zaten yeni aldığımızdan dolayı cancel opsiyonunu seçiyoruz. Sonrasında aşağıdaki mesajı aldıkdan sonra database’i resetlog ile açıyoruz.

Media Recovery Canceled

Sql>Alter database open resetlogs;
Database altered.

Sonrasında redologların bulunduğu dizini kontrol ettiğimizde redologların otomatik olarak oluştuğunu göreceksiniz. Bu tarz kullanıcı hatalarının önüne geçmek kimi zaman çok mümkün olmamaktadır. Sunucu üzerine erişim yetkileri bulunan kullanıcıların eğitilmesi, oracle’ ın kullanmış olduğu dizinlerin kritikliğinin öneminin çok iyi anlatılmış olması gerekmektedir. Database tarafında yapılan işlemler için auditing mekanizması bulunmaktadır. Benzer bir yapının operating sistemi içinde kurgulanıyor olması bu tarz olumsuz durumlarının kaynağının tespiti için ciddi önem taşımaktadır.

Be Sociable, Share!

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir


8 − sekiz =