Rastgele Yazılar : SAS nedir?
Rastgele Yazılar : OBI 10g'de Secure Socket Layer (SSL)
Rastgele Yazılar : Tablespace Yönetimi - 3
Rastgele Yazılar : ODI da Model Oluşturma(Creating Models)
Rastgele Yazılar : Oracle Pga Yapısı
Rastgele Yazılar : ODI Load Plan Hata Maili - Case When .. Else
Rastgele Yazılar : SQL Nedir, Parse Call ve Plan / Optimizer
Rastgele Yazılar : Analitik fonksiyonlar
Rastgele Yazılar : ODI da Proje Oluşturma(Creating Integration Project)
Rastgele Yazılar : Oracle İnitial Parametreleri
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.