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<PRODDB_8059:747799121:1>.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<PRODDB_8060:747799122:1>.dbf
[Normal] From: OB2BAR_Oracle8@hpkrttst “PRODDB” Time: 04/12/11 17:26:06
Starting OB2BAR Restore: hpintdb:PRODDB_HP_Database_rman<PRODDB_8061:747799122:1>.dbf
channel dev_0: restored backup piece 1
piece handle=PRODDB_HP_Database_rman<PRODDB_8059:747799121:1>.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<PRODDB_8060:747799122:1>.dbf
channel dev_1: restored backup piece 1
piece handle=PRODDB_HP_Database_rman<PRODDB_8060:747799122:1>.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<PRODDB_8061:747799122:1>.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<PRODDB_8077:747879513:1>.dbf
[Normal] From: OB2BAR_Oracle8@hpkrttst “PRODDB” Time: 04/12/11 20:17:26
Completed OB2BAR Restore: hpintdb:PRODDB_HP_Archive_rman<PRODDB_8077:747879513:1>.dbf
channel dev_0: restored backup piece 1
piece handle=PRODDB_HP_Archive_rman<PRODDB_8077:747879513:1>.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.