Birkaç gün önce production database’ lerinden birinde
tablonun biri yanlışlıkla silinmişti. Kayıtları farklı bir ortamdan
getirecekleri veya aynı kayıtları bir şekilde tekrar oluşturacakları
düşüncesiyle aksiyon almamıştık. Ancak
bugün, belirttiğim bu işlemlerin yapılamadığı ve ayın 07’ sindeki kayıtlara
mutlaka ulaşılması gerektiği söylenildi. Database’ in protection’ ı 7 gün olduğu
için rman backuplarımız vardı. Yaklaşık 600 gb’ lık bir db için farklı bir
ortam oluşturarak buraya backupı döndük ve verileri kurtardık. Aslında bununla ilgili olarak
geçen sene Aralık ayında bu işlemin nasıl yapılması gerektiği ile ilgili bir
yazı yazmıştım. Dolayısıyla konuya antremanlı olduğumuzdan çok sürpriz
olmadı. (http://www.kamilturkyilmaz.com/2010/12/07/rman-catalog-database%e2%80%99-i-kullanarak-kartusa-alinan-backupi-farkli-bir-sunucuya-donme-1/)
Örnek olması açısından bugün yaptığımız işlemleride
anlatacağım. Başlamadan önce elimizdekilere bir bakalım, 5 gün öncesine ait
kartuşda rman backupımız var, bu backupı döneceğimiz farklı bir sunucumuz var
ve database’ imizin versiyonu 10.1.0.5 , OS hp-ux.
Önce 5 gün önceki backupı kullanacağımız için onun hangisi
olduğunu tespit etmemiz gerekiyor, sonrada restore yaparken tag etiketi ile
birlikte döneceğiz.
ORACLE_SID değerini Production SID ile aynı olacak şekilde set ediyoruz.
export ORACLE_SID=PRODDB
Production database’ inin backuplarını sorgulamak için
caratalog database’ ine bağlanıyoruz.
prd1:RMAN:./home/oracle>rman
catalog rman_cat_user/password@RMAN_CAT_TNS
Recovery Manager:
Release 10.1.0.5.0 - 64bit Production
Copyright (c) 1995,
2004, Oracle. All rights reserved.
connected to recovery
catalog database
RMAN> connect
target ibm_rmanuser/password@PRODDB
connected to target
database: PRODDB (DBID=9999999999)
RMAN> list backup;
……..
……..
……..
S Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- --
---------- ----------- ------------ ---------------
838735 Incr 0
117G SBT_TAPE 03:20:02
07-APR-11
BP Key: 838749 Status: AVAILABLE Compressed: NO Tag: TAG20110407T015841
Handle: PRODDB_HP_Database_rman.dbf Media:
List of Datafiles in backup set 838735
File LV Type Ckp SCN Ckp Time
Name
---- -- ---- ---------- --------- ----
6
0 Incr 3283930085917 07-APR-11 /dizin1/PRODDB/ibank02.dbf
11
0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/ibankidx02.dbf
16
0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/ibankhist03.dbf
18
0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/aurora01.dbf
22
0 Incr 3283930085917 07-APR-11 /dizin1/PRODDB/ibank09.dbf
25
0 Incr 3283930085917 07-APR-11 /dizin1/PRODDB/users02.dbf
26
0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/FOREKS_TS01.dbf
27
0 Incr 3283930085917 07-APR-11 /dizin2/PRODDB/ibank12.dbf
……..
……..
……..
Ayın 07’ sine ait backupı buldum ve etiketini burdan
alıyorum.
Şimdi restore işlemi için test sunucusu üzerinden rman
catalog database’ ine bağlanıp işlemlerime başlıyorum. Öncesinde ufak bir bilgi
ilk denememde hata aldım sebebide profile dosyasında NLS_LANG parametresi set
edilmemiş olmasından dolayı idi. Aldığım hatayı da ekte veriyorumki benzer bir
durumla karşılaşan olabilir.
executing command: SET
NEWNAME
RMAN-00571:
===========================================================
RMAN-00569:
=============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of
set command at 04/12/2011 17:06:47
ORA-06550: line 1,
column 7:
PLS-00553: character
set name is not recognized
ORA-06550: line 0,
column 0:
PL/SQL: Compilation
unit analysis terminated
Profile dosyasına NLS_LANG parametresini ekledikden sonra
problem düzeldi. (mevcut ssh sessionlarınızı restart etmemiz unutmayın)
Adımlarımızdan biri pfile, pwd file, tns.ora gibi
dosyalarımızı test sunucumuz üzerine taşıyoruz. Lokasyonları oracle software
altındaki dizinleri olacak şekilde, pfile’ in içeriği değiştirilmeli tüm
lokasyon, memory parametreleri ….
Sqlplus’ a bağlanıp database’i (instance yok, sadece
software kurulu ancak pfile’ i okuduğu için) nomount modda açıyorum.
SQL> startup nomount
ORACLE instance
started.
Total System Global
Area 629145600 bytes
Fixed Size 1299912 bytes
Variable Size 260844088 bytes
Database Buffers 360710144 bytes
Redo Buffers 6291456 bytes
SQL>
Rma’ bağlanıyoruz;
oracle@hpkrttst:/data2/admin/arch2>
rman target /
Recovery Manager:
Release 10.1.0.5.0 - 64bit Production
Copyright (c) 1995,
2004, Oracle. All rights reserved.
connected to target
database: PRODDB (DBID=9999999999)
RMAN> connect catalog
rman_cat_user/password@RMAN_CAT_TNS
connected to recovery
catalog database
RMAN>
Catalog database’ ine bağlandık. Database hala nomount modda
dbid’ yi set ediyoruz. (production sistemin dbid değeri ile)
RMAN> set dbid=9999999999
executing command: SET
DBID
database name is
"PRODDB" and DBID is 9999999999
Öncelikle Control file’ leri restore ediyoruz;
run {
allocate channel dev_1
type 'sbt_tape';
restore controlfile
from TAG 'TAG20110407T015841';}
(bu kısmın outputunu alamadığım için buraya koyamıyorum)
Bu kısmıda problemsiz geçtikden sonra database’ i artık
mount moda alabiliriz.
SQL> alter database
mount ;
Database altered.
Sıra datafile’ leri restore etmeye geldi,
Benim örneğimde 70 tane dbf olduğu için komutun hepsini
buraya koymayacağım, tek datafile varmış gibi komutu kısaltarak buraya
ekliyorum, sonuçda 1000 tanede olsa komut aynı komut sadece satır sayısı
değişiyor;
run {
allocate channel dev_0
type 'sbt_tape';
allocate channel dev_1
type 'sbt_tape';
set newname for
datafile 1 to '/data2/oradata/system01.dbf';
set newname for
datafile 2 to
'/data2/oradata/undotbs01.dbf';
set until time
"to_date('07-04-2011 06:00:00','dd-mm-yyyy hh24:mi:ss')";
restore database from
TAG 'TAG20110407T015841' ;
switch datafile all;
recover database;
}
Until time benim dönmek istediğim zamanım, tag benim dönmek
istediğim backupımın etiketi ve yaklaşık 4 saat sonra bu kısımda tamamlanmıştı.
Restore-recover operasyonuna ait outputuda sadeleştirerek
ekliyorum ;
allocated channel:
dev_0
channel dev_0: sid=1094
devtype=SBT_TAPE
channel dev_0: Data
Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_
allocated channel:
dev_1
channel dev_1:
sid=1093 devtype=SBT_TAPE
channel dev_1: Data
Protector A.06.00/PHSS_37147/PHSS_37148/DPSOL_00306/DPLNX_
executing command: SET
NEWNAME
executing command: SET
NEWNAME
executing command: SET
until clause
Starting restore at
12-APR-11
channel dev_2:
starting datafile backupset restore
channel dev_2:
specifying datafile(s) to restore from backup set
restoring datafile 00001
to /data2/oradata/system01.dbf
restoring datafile
00002 to /data2/oradata/undotbs01.dbf
[Normal] From:
OB2BAR_Oracle8@hpkrttst "PRODDB"
Time: 04/12/11 17:25:58
Starting OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman.dbf
[Normal] From:
OB2BAR_Oracle8@hpkrttst "PRODDB"
Time: 04/12/11 17:26:06
Starting OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman.dbf
channel dev_0:
restored backup piece 1
piece handle=PRODDB_HP_Database_rman.dbf
tag=TAG20110407T015841
channel dev_0: restore
complete
[Normal] From:
OB2BAR_Oracle8@hpkrttst "PRODDB"
Time: 04/12/11 20:10:59
Completed OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman.dbf
channel dev_1:
restored backup piece 1
piece handle=PRODDB_HP_Database_rman.dbf
tag=TAG20110407T015841
channel dev_1: restore
complete
[Normal] From:
OB2BAR_Oracle8@hpkrttst "PRODDB"
Time: 04/12/11 20:11:44
Completed OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman.dbf
channel dev_3: restore
complete
Finished restore at
12-APR-11
datafile 1 switched to
datafile copy
input datafilecopy
recid=757 stamp=748296730 filename=/data2/oradata/system01.dbf
datafile 2 switched to
datafile copy
input datafilecopy
recid=758 stamp=748296730 filename=/data2/oradata/undotbs01.dbf
Starting recover at
12-APR-11
starting media
recovery
channel dev_0:
starting archive log restore to default destination
channel dev_0:
restoring archive log
archive log thread=1
sequence=6460
channel dev_0:
restoring archive log
archive log thread=1
sequence=6461
channel dev_0:
restoring archive log
archive log thread=1
sequence=6462
channel dev_0:
restoring archive log
archive log thread=1
sequence=6463
channel dev_0:
restoring archive log
archive log thread=1
sequence=6464
[Normal] From:
OB2BAR_Oracle8@hpkrttst "PRODDB"
Time: 04/12/11 20:16:20
Starting OB2BAR Restore: hpintdb:PRODDB_HP_Archive_rman.dbf
[Normal] From:
OB2BAR_Oracle8@hpkrttst "PRODDB"
Time: 04/12/11 20:17:26
Completed OB2BAR Restore: hpintdb:PRODDB_HP_Archive_rman.dbf
channel dev_0:
restored backup piece 1
piece handle=PRODDB_HP_Archive_rman.dbf
tag=TAG20110408T000521
channel dev_0: restore
complete
archive log
filename=/data2/admin/arch2/arch_1_6460_738713429.arc thread=1 sequence=6460
archive log
filename=/data2/admin/arch2/arch_1_6461_738713429.arc thread=1 sequence=6461
archive log filename=/data2/admin/arch2/arch_1_6462_738713429.arc
thread=1 sequence=6462
archive log
filename=/data2/admin/arch2/arch_1_6463_738713429.arc thread=1 sequence=6463
archive log
filename=/data2/admin/arch2/arch_1_6464_738713429.arc thread=1 sequence=6464
media recovery
complete
Finished recover at
12-APR-11
released channel:
dev_0
released channel:
dev_1
RMAN>
Bundan sonraki adımımız redologlarımızında yeni pathlerini
vermek, logların listesini production dan v$log, v$logfile viewlerinden
alabilirsiniz. Ben yine kısaltarak
ekliyorum komutlarımı;
alter database rename
file '/dizin1/PRODDB/redo11m1.log' to '/data2/oradata/redo11m1.log';
Database altered.
alter database rename
file '/dizin2/PRODDB/redo11m2.log' to '/data2/oradata/redo11m2.log';
Database altered.
Resetlog ile database’ imizi açıyoruz;
alter database open
resetlogs ;
Database altered.
Ve sistemiz ayın 07’ sindeki sabah 06:00 daki haline dönmüş
oldu.
Kamil TÜRKYILMAZ
Hiç yorum yok:
Yorum Gönder