RMAN Restore Esnasında Karşılaşılan ORA-01180 ve ORA-01110 Hataları

Merhaba,

Canlı veritabanından alınan full veritabanı yedeğini test veritabanına geri dönerken system datafile ‘ı ile ilgili aşağıdaki hata ile karşılaştık. Son control dosyasının restore edildiğinden ve elimizdeki yedeklerin catalog edildiğini kontrol ettikten sonra iki kere daha denedim. Fakat aynı hatayı aldık.

Starting restore at 10-OCT-17
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4
using channel ORA_DISK_5
using channel ORA_DISK_6
using channel ORA_DISK_7
using channel ORA_DISK_8

creating datafile file number=1 name=/DATA/alfa/datafile/system01.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 10/10/2017 01:08:29
ORA-01180: can not create datafile 1
ORA-01110: data file 1: ‘+DATAC1/ALFA/DATAFILE/system.319.922730217’

Oracle Metalink üzerinde hataları arattığınızda aşağıdaki 2 döküman işinizi çözecektir.

RMAN restore fails with ORA-01180: can not create datafile 1 (Doc ID 1265151.1)
RMAN restore of database fails with ORA-01180: Cannot create datafile 1 (Doc ID 1573040.1)

Bir önceki incarnation numarasına reset yapıp, tekrar restore işlemini deneyelim.

SQL> select INCARNATION#, RESETLOGS_TIME from v$database_incarnation order by RESETLOGS_TIME desc;

INCARNATION# RESETLOGS
———— ———
2 22-MAY-17
1 16-SEP-16

rman target /

RMAN> reset database to incarnation 1;

RMAN> restore database;

FRA alanı ile birlikte backup controlfile kullanılırsa, FRA alanı için implicit crosscheck  işlemi yapılır ve controlfile dosyasındaki tüm bilgiler kataloglanır. Resetlogs işlemi sonrasında oluşan arşiv dosyaları yeni bir incarnation oluşturur. Yeni bir incarnation oluşmasından dolayı önceki incarnation ‘a ait yedekleri yeni incarnation üzerinde dönemezsiniz.

 

Reset işlemi sonrası veritabanımızı başarılı bir şekilde geri dönebildik.

Reset ve restore işlemleri öncesi spfile veya pfile dosyasından FRA parametrelerini silerekte sorunu çözebilirdik. FRA parametreleri yerine  log_archive_dest_1 parametresini arşiv lokasyonu olarak set etmemiz yeterli olacaktır.

Reklamlar

RMAN Block Change Tracking ve “_bct_public_dba_buffer_size” Hidden Parametresi

10g ile gelen önemli özelliklerden biri olan “block change tracking”, alınan son yedekten itibaren değişen bloklar hakkında log tutar. Bir sonraki yedek esnasında değişen blokları tespit etmek için bütün veri dosyalarını taramak yerine “block change tracking” log dosyasını kullanır. Değişen blokların tespit edilmesi ve ilgili log dosyasına yazılması CTWR prosesi tarafından yapılmaktadır. Block change tracking aktif edilmesiyle RMAN daha performanslı çalışır.

Block Change Tracking aşağıdaki gibi aktif veya iptal edilir.

SQL>alter database enable block change tracking using file '/rman_bkups/change.log';

SQL>alter database disable block change tracking;

RMAN ile incremental yedek alma esnasında veritabanı performansına doğrudan etki eden ‘block change tracking buffer space’ beklemelerinin (wait event) olduğunu gözlemleyebilirsiniz. Bu bekleme özellikle büyük hacimli veritabanlarında gözlemlenmiştir. 10.2 ile 11.2 verisyonları arasındaki veritabanlarını etkilemektedir.

Bu problemin çözümü için metalinkde yayınlanan [ID 1311518.1] nolu dökümana göre aşağıdaki işlemler yapılmalıdır.

1- Block Change Tracking log dosyası çok fazla I/O gören verilerin bulunduğu diskde olmamalıdır.

2- Large_pool_size değeri gözden geçirilmeli, düşük ise artırılmalıdır.

3- Oracle ın gizli (hidden) parametresi “_bct_public_dba_buffer_size” set edilmeli.

Change tracking için ayrılmış olan memory alanı aşağıdaki sorgu ile bulabilirsiniz.

select dba_buffer_count_public*dba_entry_count_public*dba_entry_size
from  x$krcstat;

Elde edilen değer 2 ile çarpılarak “_bct_public_dba_buffer_size” parametresinin alacağı değer hesaplanabilir.

Obsolete Yedekler Silinirken RMAN-03002 ve RMAN-06091 Hatalarının Alınması

RMAN üzerinden obsolete yedekler silinilirken aşağıdaki hatalar alınabilir. Bunun sebebi disk yedeklerinin yanında tape yedeklerininde olması.

RMAN> delete obsolete;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 02/04/2018 20:28:22
RMAN-06091: no channel allocated for maintenance (of an appropriate type)

Tape üzerindeki yedeklerin silinebilmesi için tape ‘e kanal açamamasından kaynaklı bir problemdir.

Çözüm için aşağıdaki gibi kanal açılması gerekmektedir. Hem tape hem de disk yedeklerini aynı anda silmek istiyorsak, aşağıdaki gibi ayrı ayrı kanal açmamız gerekir.

RMAN> allocate channel for maintenance type disk;
RMAN> allocate channel for maintenance device type ‘sbt_tape’ PARMS ‘…’;
RMAN> delete obsolete;

Sadece disk üzerindeki obsolete yeddekleri silmek istiyorsak, komutumuz aşağıdaki gibi olacaktır.

RMAN> allocate channel for maintenance type disk;
RMAN> delete obsolete device type disk;

TROUG High Availability SIG 2016 – Galatasaray Üniversitesi Etkinliğinde Buluşalım!

he16-1

Detaylı bilgi ve kayıt için ;

High Availability SIG Meeting 2016