Arşiv

Archive for the ‘RMAN Backup and Recovery’ Category

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

Primary/Standby Log GAP Oluştuğunda ve Primary Üzerinde Arşivler Silinmişse Ne Yapılmalı?

11/04/2012 4 yorum

Merhaba Arkadaşlar,

Primary/Standby arasında log aralığı (GAP) oluştuğunda ve Primary veritabanı üzerinde arşiv log dosyalarının bir bölümünü yanlışlıkla sildiğimiz bir durumda ne yapmamız gerektiğini yazacağım. Elimizde silinen arşiv dosyalarının yedeğinin olmadığını düşünelim. Normalde biz dba ler böyle bir duruma müsaade etmemeliyiz ama böyle bir durum başımıza gelebilir. Bu durumda yapmamız gereken primary ve standby veritabanlarının şu anki SCN numaralarını öğrenmektir. Hadi adım adım birlikte yapalım.

1- Primary üzerinde aşağıdaki sorgu ile o anki SCN numarasını öğrenelim.

SQL> select current_scn from v$database;

CURRENT_SCN

———–

1289504966

2- Standby üzerinde aşağıdaki sorgu ile o anki SCN numarasını öğrenelim.

SQL> select current_scn from v$database;

CURRENT_SCN

———–

1289359962

scn_to_timestamp(SCN_NUMBER) fonksiyonunu kullanarak Primary/Standby arasında ne kadarlık bir zaman farkı olduğunuda öğrenebilmekteyiz.

3- Standby veritabanında apply işlemi durdurulur.

SQL> alter database recover managed standby database cancel;

4– Standby veritabanı kapatılır.

SQL> shutdown immediate;

5- Primary veritabanı üzerinde standby veritabanının son SCN numarasından itibaren incremental yedek alalım. Ve aldığımız yedeği standby sunucusuna kopyalayalım.

RMAN> backup incremental from scn 1289359962 database;

# scp /backup_ISTANBUL/dun52q66_1_1 oracle@192.168.2.3:/oracle/ora11g

6- Primary veritabanında yeni bir standby control dosyası oluşturalım. Ve bu dosyası standby veritabanımızın bulunduğu sunucuya kopyalayalım.

SQL> alter database create standby controlfile as ‘/oracle/ora11g/standby.ctl’;

# scp /oracle/ora11g/standby.ctl oracle@192.168.2.3:/oracle/ora11g

7- Standby veritabanımızı NOMOUNT durumunda açıp, control dosyalarımızın yerini öğrenelim.

SQL> startup nomount

SQL> show parameter control_files

8- Control dosyalarını primary sunucudan kopyaladığımız standby control dosyası ile ezelim.

# cp /oracle/ora11g/standby.ctl /oracle/ora11g/ISTANBUL/data1/control01.ctl

# cp /oracle/ora11g/standby.ctl /oracle/ora11g/ISTANBUL/data2/control02.ctl

9- Standby veritabanımızı MOUNT durumuna getirelim.

SQL> alter database mount standby database;

10- Standby sunucuda RMAN ‘e bağlanalım. Ve primary üzerinden aldığımız incremental yedeği catalog komutuyla RMAN ‘e register edelim.

# rman target /

RMAN> catalog start with ‘/oracle/ora11g’;

Emin olup olmadığımzı soracaktır. Yes diyerek devam edebiliriz.

11- Artık standby veritabanımızı kurtarabiliriz. Incremental yedek olduğu için recover işlemini başlatalım.

RMAN> recover database;

Incremental yedek recover işlemi tamamlandığında veritabanı bir sonraki arşiv dosyasını arayacaktır. Ve kurtarma işlemi gerekli arşiv dosyasını bulamadığını belirten ORA-00334 hatası ile sonlanır. Bu durumda endişeye kapılmamıza gerek yoktur. ORA-00334  hatası ile belirtilen arşiv primary veritabanında biz incremental yedek aldıktan sonra oluşturulan veya oluşacak olan arşiv dosyasıdır. Artık standby veritabanımızda RMAN den çıkıp apply işlemini başlatabiliriz.

SQL> alter database recover managed standby database disconnect from session;

Primary/Standby arasındaki log aralığını RMAN incremental yedek ile çok rahat çözebildik. Böyle bir durum ile karşılaştığımızda Standby veritabanının yeniden kurulumu en son düşüneceğimiz bir iş olmalı. Çünkü zaman bizim için çok değerli.

Talip Hakan Öztürk

RMAN Yedek Sıkıştırma Seviyelerinin Karşılaştırılması

07/04/2012 1 yorum

Merhaba Arkadaşlar,

Oracle 11g R2 ile birlikte farklı sıkıştırma (compression) seviyelerini kullanabilir durumdayız. BASIC, LOW, MEDIUM ve HIGH olmak üzere 4 farklı sıkıştırma seviyesi vardır. LOW, MEDIUM ve HIGH  sıkıştırma seviyelerini kullanabilmemiz için “Advanced Compression” lisansımız olması gerekmektedir. Bu yazımda, 4 sıkıştırma seviyesinde testler yapacağız. Sıkıştırma seviyelerini zaman ve boyut (size) olarak karşılaştıracağız.

O halde hemen testimize geçelim.

Aşağıdaki gibi bir shell script yazdım. Böylelikle yedek zamanını da izleyebileceğiz.

# vi rman_compression_test.sh

Aşadağıdaki satırları rman_compression_test.sh scriptimize yazıp kaydedelim.

echo  “RMAN Backup Start Date :” `date ‘+%d.%m.%Y %H:%M:%S’`

StartTime=$(date +%s)

export NLS_LANG=AMERICAN export NLS_DATE_FORMAT=’DD-MON-YYYY HH24:MI:SS’

rman target / << EOSQL

backup as compressed backupset database;

EOSQL

EndTime=$(date +%s)

DiffTime=$(( $EndTime – $StartTime ))

echo “RMAN Backup Finished.”

echo “Backup End Date :”  `date ‘+%d.%m.%Y %H:%M:%S’`

echo “RMAN Backup Duration :”  $DiffTime

Yedek dosyalarımızın yerini set edelim.

# rman target /

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/oracle/yedek/bck_test11g/%U’;

1- BASIC sıkıştırma seviyesi testi. Önce varolan sıkıştırma seviyemizi görelim.

# rman target /

RMAN> SHOW COMPRESSION ALGORITHM ;

RMAN configuration parameters for database with db_unique_name DBARGE are:

CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE;

BASIC seviye kullanıyoruz. Şimdi 10GB olan test veritabanımızın sıkıştırılmış yedeğini alalım.

# . rman_compression_test.sh

RMAN Backup Start Date : 13.03.2012 16:19:33

…..

Recovery Manager complete.

RMAN Backup Finished.

Backup End Date : 13.03.2012 16:26:32

RMAN Backup Duration : 419

Yedek esnasında ortalama load aşağıdaki gibiydi.

# top load average: 1.12, 0.82, 0.75

Yedek boyutu: 636M

2- LOW sıkıştırma seviyesi testi.

# rman target /

RMAN> CONFIGURE COMPRESSION ALGORITHM ‘LOW’;

old RMAN configuration parameters:

CONFIGURE COMPRESSION ALGORITHM ‘BASIC’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE;

new RMAN configuration parameters:

CONFIGURE COMPRESSION ALGORITHM ‘LOW’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE;

new RMAN configuration parameters are successfully stored

Şimdi LOW seviye kullanıyoruz. Yedeğimizi başlatalım.

# . rman_compression_test.sh

RMAN Backup Start Date : 13.03.2012 16:30:36

…..

Recovery Manager complete.

RMAN Backup Finished.

Backup End Date : 13.03.2012 16:33:45 RMAN

Backup Duration : 189

Yedek esnasında ortalama load aşağıdaki gibiydi.

# top load average: 1.34, 0.85, 0.74

Yedek boyutu: 797M

3- MEDIUM sıkıştırma seviyesi testi.

# rman target /

RMAN> CONFIGURE COMPRESSION ALGORITHM ‘MEDIUM’;

old RMAN configuration parameters:

CONFIGURE COMPRESSION ALGORITHM ‘LOW’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE;

new RMAN configuration parameters:

CONFIGURE COMPRESSION ALGORITHM ‘MEDIUM’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE;

new RMAN configuration parameters are successfully stored

Şimdi MEDIUM seviye kullanıyoruz. Yedeğimizi başlatalım.

# . rman_compression_test.sh

RMAN Backup Start Date : 13.03.2012 16:36:21

…..

Recovery Manager complete.

RMAN Backup Finished.

Backup End Date : 13.03.2012 16:40:19

RMAN Backup Duration : 238

Yedek esnasında ortalama load aşağıdaki gibiydi.

# top load average: 1.38, 0.93, 0.77

Yedek boyutu: 674M

4- HIGH sıkıştırma seviyesi testi.

# rman target /

RMAN> CONFIGURE COMPRESSION ALGORITHM ‘HIGH’;

old RMAN configuration parameters:

CONFIGURE COMPRESSION ALGORITHM ‘MEDIUM’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE;

new RMAN configuration parameters:

CONFIGURE COMPRESSION ALGORITHM ‘HIGH’ AS OF RELEASE ‘DEFAULT’ OPTIMIZE FOR LOAD TRUE;

new RMAN configuration parameters are successfully stored

Şimdi HIGH seviye kullanıyoruz. Yedeğimizi başlatalım.

# . rman_compression_test.sh

RMAN Backup Start Date : 13.03.2012 16:42:21

…..

Recovery Manager complete.

RMAN Backup Finished.

Backup End Date : 13.03.2012 17:34:30

RMAN Backup Duration : 3129

Yedek esnasında ortalama load aşağıdaki gibiydi.

# top load average: 1.20, 1.07, 0.88

Yedek boyutu: 485M

5- Normal yedek testi. Scriptimizin içeriğini aşağıdaki gibi değiştirelim.

# vi rman_compression_test.sh

echo  “RMAN Backup Start Date :” `date ‘+%d.%m.%Y %H:%M:%S’`

StartTime=$(date +%s)

export NLS_LANG=AMERICAN export NLS_DATE_FORMAT=’DD-MON-YYYY HH24:MI:SS’

rman target / << EOSQL

backup as backupset database;

EOSQL

EndTime=$(date +%s)

DiffTime=$(( $EndTime – $StartTime ))

echo “RMAN Backup Finished.”

echo “Backup End Date :”  `date ‘+%d.%m.%Y %H:%M:%S’`

echo “RMAN Backup Duration :”  $DiffTime

Scriptimizi çalıştıralım.

#. rman_compression_test.sh

RMAN Backup Start Date : 13.03.2012 17:37:51

…..

Recovery Manager complete.

RMAN Backup Finished.

Backup End Date : 13.03.2012 17:42:30

RMAN Backup Duration : 279

Yedek esnasında ortalama load aşağıdaki gibiydi.

# top load average: 2.42, 1.56, 1.17

Yedek boyutu: 4.0G

Sıkıştırma Seviyesi Yedek Boyutu Yedek Süresi
NORMAL 4.0G 279 sn
 BASIC  636M  419 sn
 LOW  797M  189 sn
 MEDIUM  674M  238 sn
HIGH  485M  3129 sn

Veri ve Redo Log Dosyalarının Dosya Sisteminden ASM ‘e RMAN ile Taşınması

27/03/2012 1 yorum

Merhaba Arkadaşlar,

Önceki yazımda bir veri dosyasının, dosya sisteminden ASM disk grubuna RMAN ile taşınmasını yazmıştım. Bu yazımda da tüm veritabanının (veri dosyaları, control file, online redo log dosyaları) dosya sisteminden ASM ‘e RMAN ile nasıl taşıyacağımızı adım adım öğreneceğiz.

1- Block Change Tracking aktif ise disable yapılır.

# sqlplus / as sysdba

SQL> alter database disable block change tracking;

2- Veri dosyalarımızın ve control dosyalarımızın varsayılan yerini aşağıdaki gibi +DATA olarak değiştirelim.

SQL> alter system set db_create_file_dest=’+DATA’ scope=spfile;

Benzer şekilde online redo log dosyalarımızın varsayılan yerini aşağıdaki gibi +RECO olarak değiştirelim.

SQL> alter system set db_create_online_log_dest_1=’+RECO’ scope=spfile;

3- Spfile parametre dosyamızda control_files parametresini sıfırlayalım.

SQL> alter system reset control_files scope=spfile sid=’*’;

4- Artık veri dosyalarımızı RMAN ile ASM ‘e taşıyabiliriz. Önce veritabanımızı NOMOUNT modda açıp control dosyamızı aşağıdaki gibi restore ederek +DATA disk grubuna yazılmasını sağlayalım.

$ rman target /

RMAN> startup nomount

RMAN> restore controlfile from ‘/data_TALIPDB/control01.ctl’;

5- Veritbanımızı MOUNT moduna alalım ve RMAN ile +DATA disk grubuna image copy yedek alalım.

RMAN> alter database mount;

RMAN> backup as copy database format ‘+DATA’;

6- Veritabanımızı aşağıdaki gibi +DATA disk grubunda bulunan kopyasına switch edelim.

RMAN> switch database to copy;

7- Veritabanımızı açabiliriz.

RMAN> alter database open;

8- İlk adımda disable ettiğimiz block change tracking ‘i tekrar enable edebiliriz.

SQL> alter database enable block change tracking using file ‘/oracle/ora11g/bct_file.log’;

9- Temp alanın yedeği alınmayacağı için yeni bir temp dosyası ekleyerek işi çözebiliriz. Yeni bir temp dosyası oluşturalım. Varsayılan +DATA disk grubunda oluşturulacaktır. Ve Sonra eskisini silebiliriz.

# sqlplus / as sysdba

SQL> alter tablespace temp add tempfile size 500M;

SQL> alter tablespace temp drop tempfile ‘/data_TALIPDB/temp01.dbf’

10- Şimdide online redo log dosyalarımızı ASM disk grubuna taşıyalım.

# sqlplus / as sysdba

SQL>select b.group# , b.status , a.member from v$logfile a , v$log b where a.group# = b.group# order by 1;

GROUP#           STATUS                 MEMBER

————          ————              —————————

1                            INACTIVE             /data1/redo01.log

2                            INACTIVE            /data1/redo02.log

3                            CURRENT             /data1/redo03.log

Durumu INACTIVE veya UNUSED olan redo log dosyaları drop edilebilmektedir. Ama durumu CURRENT veya ACTIVE ise drop işlemi hemen yapılamamaktadır. Online redo log gruplarımızı tek tek silip, tekrar +RECO disk grubunda oluşturalım.

SQL> alter database drop logfile group 1;

Daha önce db_create_online_log_dest_1 parametresini ‘+RECO’ olarak set ettiğimiz için redo log dosyalarımız varsayılan olarak +RECO disk grubunda oluşturulacaktır.

SQL> alter database add logfile group 1 size 50M;

Aynı şekilde 2. log grubumuzuda drop/create edelim.

SQL> alter database drop logfile group 2;

SQL> alter database add logfile group 2 size 50M;

11- Yukarıdaki sorguyu tekrar çalıştıralım ve redo log dosyalarımızın durumunu kontrol edelim.

SQL> select b.group# , b.status , a.member from v$logfile a , v$log b where a.group# = b.group# order by 1;

GROUP#           STATUS                 MEMBER

————          ————              —————————

1                            INACTIVE            +RECO/talipdb/online log/group_1.257.7782 52603

2                            INACTIVE            +RECO/talipdb/online log/group_2.258.7782 52715

3                            CURRENT             /data1/redo03.log

Sıra geldi 3. redo log grubu drop/create etmeye. Durumu CURRENT olduğu için önce diğer redo log dosyasına switch yapalım.

SQL> alter system switch logfile;

SQL> select b.group# , b.status , a.member from v$logfile a , v$log b where a.group# = b.group# order by 1;

GROUP#           STATUS                 MEMBER

————          ————              —————————

1                            CURRENT             +RECO/talipdb/online log/group_1.257.7782 52603

2                            UNUSED               +RECO/talipdb/online log/group_2.258.7782 52715

3                            ACTIVE                 /data1/redo03.log

Sorgumuzu tekrar çalıştırdığımızda, durumunu ACTIVE olarak görürüz. Durumunun INACTIVE olması için bir süre bekleyebiliriz. Veya aşağıdaki gibi checkpoint atarak redo log dosyamız ile ilgili veritabanı tampon ön belleğinde (database buffer cache) bulunan dirty blokların yazılmasını sağlayabiliriz.

SQL> alter system checkpoint;

SQL> select b.group# , b.status , a.member from v$logfile a , v$log b where a.group# = b.group# order by 1;

GROUP#           STATUS                 MEMBER

————          ————              —————————

1                            CURRENT             +RECO/talipdb/online log/group_1.257.7782 52603

2                            UNUSED               +RECO/talipdb/online log/group_2.258.7782 52715

3                            INACTIVE             /data1/redo03.log

Checkpoint sonrası tekrar kontrol ettiğimizde durumunu INACTIVE olarak görürüz. Şimdi 1. redo log grubumuzu drop/create edebiliriz.

SQL> alter database drop logfile group 3;

SQL> alter database add logfile group 3 size 50M;

Son olarak online redo log dosyalarımızı kontrol edelim.

SQL> set lines 50

SQL> select member from v$logfile;

MEMBER

————————————————–

+RECO/talipdb/onlinelog/group_3.259.778253083

+RECO/talipdb/onlinelog/group_2.258.778252715

+RECO/talipdb/onlinelog/group_1.257.778252603

Veridosyalarımızı da kontrol edelim.

SQL> select name from v$datafile;

NAME

——————————————————————————–

+DATA/talipdb/datafile/system.256.778251403

+DATA/talipdb/datafile/sysaux.257.778251487

+DATA/talipdb/datafile/undotbs1.258.778251553

+DATA/talipdb/datafile/users.260.778251563

SQL> select name from v$tempfile;

NAME

——————————————————————————–

+DATA/talipdb/tempfile/temp.262.778252097

Veri dosyalarımızı, control dosyalarımızı ve online redo log dosyalarımızı ASM disk grubuna taşıdık. ASM ile çalışan mutlu veritabanlarınız olması dileğiyle 🙂 …

Talip Hakan Öztürk

Veri Dosyasının Dosya Sisteminden ASM Disk Grubuna RMAN ile Taşınması

Merhaba Arkadaşlar,

Bu yazımda, dosya sistemi üzerinde oluşturulmuş veri dosyasının RMAN ile ASM ‘e nasıl taşıyacağımızı yazacağım.

1- Önce  veri dosyası dosya sistemi üzerinde olan bir tablespace oluşturalım.

SQL> CREATE TABLESPACE TOASM DATAFILE   ‘/data1/toasm01.dbf’ SIZE 100M AUTOEXTEND ON NEXT 1M ;

2- Veri dosyalarımızı listeleyelim. Bakalım nelerimiz var?

SQL> select name from v$datafile;

NAME

——————————————————————————–

+DATA/talipdb/datafile/system.257.778261279

+DATA/talipdb/datafile/sysaux.258.778261375

+DATA/talipdb/datafile/undotbs1.259.778261441

+DATA/talipdb/datafile/users.260.778261447

/data1/toasm01.dbf

3- Şimdi RMAN ‘e bağlanalım.

 [oracle@DBTALIP /oracle/ora11g]# rman target /

Recovery Manager: Release 11.2.0.1.0 – Production on Sun Mar 18 16:05:09 2012

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: TALIPDB (DBID=4043281188)

4- Taşıyacağımız Tablespace ‘i offline yapalım.

RMAN> sql “alter tablespace toasm offline”;

using target database control file instead of recovery catalog

sql statement: alter tablespace toasm offline

5- RMAN copy komutuyla veri dosyasını +DATA disk grubuna kopyalayalım

RMAN> copy datafile ‘/data1/toasm01.dbf’ to ‘+DATA’;

Starting backup at 18-MAR-12

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=58 device type=DISK

channel ORA_DISK_1: starting datafile copy

input datafile file number=00005 name=/data1/toasm01.dbf

output file name=+DATA/talipdb/datafile/toasm.263.778262769 tag=TAG20120318T160609 RECID=13 STAMP=778262779

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15

Finished backup at 18-MAR-12

RMAN> exit

Recovery Manager complete.

6- SQL*Plus a bağlanalım ve veri dosyasının adını değiştirelim.

[oracle@DBTALIP /oracle/ora11g]# sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Sun Mar 18 16:09:12 2012

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options

SQL> alter database rename file ‘/data1/toasm01.dbf’ to ‘+DATA/talipdb/datafile/toasm.263.778262769’;

Database altered.

7- Tablespace ‘i online yapalım.

SQL> alter tablespace toasm online;

Tablespace altered.

8- Veri dosyalarımızı tekrar sorgulayalım. Bakalım son durum nasıl?

SQL> select name from v$datafile;

NAME ——————————————————————————–

+DATA/talipdb/datafile/system.257.778261279

+DATA/talipdb/datafile/sysaux.258.778261375

+DATA/talipdb/datafile/undotbs1.259.778261441

+DATA/talipdb/datafile/users.260.778261447

+DATA/talipdb/datafile/toasm.263.778262769

 

Tablespace ASM disk grubuna taşınmıştır. 🙂

 

Talip Hakan Öztürk

%d blogcu bunu beğendi: