Arşiv

Archive for the ‘RMAN Backup and Recovery’ Category

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;

BMO “Oracle Veritabanı Yedekleme Stratejileri” Eğitiminde Buluşalım!

03/01/2018 2 yorum

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

RMAN Tablespace Restore Esnasında Alınan RMAN-20202 & RMAN-06019 Hataları

Bu hataları, drop edilen bir tablespace’i kurtarmaya çalıştığımızda alırız. Bir tablespace ‘i drop ettiğimizde control dosyası drop edilen tablespace ‘e ait herhangi bir kayıt saklamaz. Bu durumda drop edilen tablespace ‘i RMAN RESTORE veya RECOVER TABLESPACE komutlarıyla kurtarmaya çalıştığımızda RMAN-20202, RMAN-06019 hataları ile karşılaşırız.

Basit bir test yapalım.

# sqlplus / as sysdba

SQL> create tablespace TS_TEST datafile ‘/data/test11g/ts_test.dbf’ size 10M autoextend on;

# rman target /

RMAN> backup tablespace TS_TEST;

Starting backup at 23-AUG-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=144 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00031 name=/data/test11g/ts_test.dbf
channel ORA_DISK_1: starting piece 1 at 23-AUG-12
channel ORA_DISK_1: finished piece 1 at 23-AUG-12
piece handle=/oracle/yedek/bck_test11g/a8njcggd_1_1.bck tag=TAG20120823T153645 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 23-AUG-12
Starting Control File Autobackup at 23-AUG-12
piece handle=/oracle/yedek/bck_test11g/cf_sp_file_c-1532875336-20120823-01 comment=NONE
Finished Control File Autobackup at 23-AUG-12

# sqlplus / as sysdba

SQL> drop tablespace TS_TEST including contents and datafiles;

# rman target /

RMAN> restore tablespace TS_TEST;

Starting restore at 23-AUG-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=136 devtype=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/23/2012 15:38:40
RMAN-20202: tablespace not found in the recovery catalog
RMAN-06019: could not translate tablespace name “TS_TEST”

Drop edilen bir tablespace ‘i kurtarabilmemiz için tablespace drop edilmeden önceki zamana kadar veritabanı PITR (point in time recovery) yapmamız gerekir. Tablespace yedeğinden geri dönme işlemini sadece tablespace ‘e ilişkin bir medya hatası olduğunda gerçekleştirebiliriz.

Basit bir test daha yapalım.

# sqlplus / as sysdba

SQL> create tablespace TS_TEST datafile ‘/data/test11g/ts_test.dbf’ size 10M autoextend on;

# rman target /

RMAN> backup tablespace TS_TEST;

Starting backup at 23-AUG-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=145 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00031 name=/data/test11g/ts_test.dbf
channel ORA_DISK_1: starting piece 1 at 23-AUG-12
channel ORA_DISK_1: finished piece 1 at 23-AUG-12
piece handle=/oracle/yedek/bck_test11g/acnjch45_1_1.bck tag=TAG20120823T154717 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 23-AUG-12
Starting Control File Autobackup at 23-AUG-12
piece handle=/oracle/yedek/bck_test10g/cf_sp_file_c-1532875336-20120823-04 comment=NONE
Finished Control File Autobackup at 23-AUG-12

TS_TEST tablespace ‘ine ait veri dosyasını işletim sistemi üzerinden silelim.

# rm /data/test11g/ts_test.dbf

Şimdi TS_TEST tablespace ‘inde bir tablo oluşturmaya çalışalım.

SQL> create table talip_test (id number) tablespace TS_TEST;
create table talip_test (id number) tablespace TS_TEST
*
ERROR at line 1:
ORA-01116: error in opening database file 31
ORA-01110: data file 31: ‘/data/test10g/ts_test.dbf’
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

Medya hatası olduğunu görüyoruz. Artık tablespace restore&recover yapabiliriz.

# rman target /

RMAN> sql “alter database datafile 31 offline”;

sql statement: alter database datafile 31 offline

RMAN> restore tablespace TS_TEST;

Starting restore at 23-AUG-12
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00031 to /data/test11g/ts_test.dbf
channel ORA_DISK_1: reading from backup piece /oracle/yedek/bck_test11g/acnjch45_1_1.bck
channel ORA_DISK_1: restored backup piece 1
piece handle=/oracle/yedek/bck_test11g/acnjch45_1_1.bck tag=TAG20120823T154717
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 23-AUG-12

RMAN> recover tablespace TS_TEST;

Starting recover at 23-AUG-12
using channel ORA_DISK_1

starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished recover at 23-AUG-12

RMAN> sql “alter database datafile 31 online”;

sql statement: alter database datafile 31 online

Evet! Artık bu tablespace üzerinde tablomuzu oluşturabiliriz.

# sqlplus / as sysdba

SQL> create table talip_test (id number) tablespace TS_TEST;

Table created.

Talip Hakan Öztürk

10g Veritabanı RMAN Yedeğini 11g Veritabanına Nasıl Geri Döneriz?

20/07/2012 5 yorum

Bu yazımda ext3 dosya sisteminde bulunan 10g veritabanımızın RMAN ile aldığımız yedeğini, ASM ortamında bulunan 11g veritabanına nasıl geri döneceğimizi yazacağım.

10 veritabanı yedeğini 11g veritabanına geri döndükten sonra “veritabanı upgrade” işlemi yapmalıyız. İşlem adımlarımız aşağıdaki gibi olacaktır.

10g veritabanında işlem adımları:

1- Pre-upgrade scripti çalıştırılır. Bu script, 11g veritabanı yazılımı kurduğumuz sunucuda $ORACLE_HOME/rdbms/admin/ dizini altında bulunan utlu112i.sql isimli scripttir. Dolayısıyla 11g veritabanı yazılımından kopyalanmalıdır.

SQL> @$ORACLE_HOME/rdbms/admin/utlu112i.sql

Bu script, registry$database tablosuna tz_version isimli bir alan ekler ve bu alanın değerini aşağıdaki sorgunun sonucu ile update eder.

SQL> select version from v$timezone_file;

Yani 10g veritabanında yapılan işlem aşağıdaki gibidir.

SQL> ALTER TABLE registry$database ADD (tz_version NUMBER);
SQL> UPDATE registry$database set tz_version =4;

SQL> ALTER  PACKAGE “SYS”.”DBMS_REGISTRY”  COMPILE BODY;
SQL> ALTER VIEW “SYS”.”DBA_REGISTRY_DATABASE”  COMPILE;

2- RMAN ile 10g veritabanının tam yedeği alalım.

#rman target /
RMAN> backup as backupset database;

3- 10g veritabanının RMAN yedeğini ve üretilen arşiv log dosyalarını 11g veritabanı sunucusuna kopyalayalım.

11g veritabanında işlem adımları:

1- $ORACLE_HOME/dbs dizini altında geçici bir pfile oluşturalım.

*.audit_file_dest=’/oracle/admin/TALIPDB/adump’
*.compatible=’11.2.0.0.0′
*.control_files=’+DATA/talipdb/controlfile/current.257.787742981′,’+DATA/talipdb/controlfile/current.258.787742983′
*.db_block_size=8192
*.db_create_file_dest=’+DATA’
*.db_create_online_log_dest_1=’+RECO’
*.db_domain=”
*.db_name=’TALIPDB’
*.diagnostic_dest=’/oracle’
*.job_queue_processes=0
*.open_cursors=300
*.pga_aggregate_target=1G
*.processes=150
*.remote_login_passwordfile=’EXCLUSIVE’
*.sga_target=2G
*.undo_tablespace=’UNDOTBS1′

2- RMAN üzerinde veritabanımızı NOMOUNT adımında açalım.

# rman target /

RMAN> startup nomount;

3- Control dosyasını yedekten geri dönelim.

RMAN> restore controlfile from ‘/oracle/ora11g/talipdb/backup/c-784951186-20120620-02’;

4- Veritabanımızı MOUNT moduna geçirelim.

RMAN> alter database mount;

5- 10g yedeklerimizi ve arşiv log dosyalarımızı kataloglayalım.

RMAN> catalog start with ‘/oracle/ora11g/talipdb/backup’;
RMAN> catalog start with ‘/oracle/ora11g/talipdb/archive’;

6- 10g yedeğimizi +DATA disk grubuna geri dönelim.

RMAN> run
{
allocate channel c1 device type disk;
SET NEWNAME FOR DATAFILE 1 TO ‘+DATA’;
SET NEWNAME FOR DATAFILE 2 TO ‘+DATA’;
SET NEWNAME FOR DATAFILE 3 TO ‘+DATA’;
SET NEWNAME FOR DATAFILE 4 TO ‘+DATA’;
restore database until sequence 4;
switch datafile all;
recover database until sequence 4;
}

7- Veritabanımızı RESETLOGS UPGRADE ile açalım.

# sqlplus / as sysdba
SQL> alter database open resetlogs upgrade;

8- Upgrade scriptini çalıştıralım.

SQL> SPOOL upgrade.log
SQL> @$ORACLE_HOME/rdbms/admin/catupgrd.sql
SQL> SPOOL off

9- 10g veritabanımızla 11g veritabanımızın platformları farklı ise utlmmig.sql scriptini çalıştıralım.

————– 32 bit -64 bit————–
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP UPGRADE
SQL> SPOOL migrate.log
SQL> @$ORACLE_HOME/rdbms/admin/utlmmig.sql
SQL> SPOOL off
——————————————- 

10- Veritabanımızı artık açabiliriz.

SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP

11- Post-Upgrade aracını çalıştıralım ve sorun olup olmadığına bakalım.

SQL> @$ORACLE_HOME/rdbms/admin/utlu112s.sql

12- Invalid objeleri derleyelim.

SQL> @$ORACLE_HOME/rdbms/admin/utlrp.sql

13- Eski temp dosyasını drop edip +DATA disk grubunda yenisini oluşturalım.

SQL> alter tablespace temp drop tempfile ‘/data_TALIPDB/temp01.dbf’;
SQL> alter tablespace temp add tempfile ‘+DATA’ size 1024M;

 

Talip Hakan Öztürk

%d blogcu bunu beğendi: