环境:
生产库---> NBU7.0 ,catalog,备份到-->磁带库中,持续运行,备份策略为每周日全备,每天增量,归档随备份一起备份
恢复测试:新的环境连接到同一NBU SERVER以及catalog,恢复生产库数据库环境到尽可能新( 磁带库中最新+生产库上未备份的归档日志)
目前有两个疑问未解决:
1. 恢复控制文件的选择: 我每次选择catalog中记录的最新的进行恢复,此文件中,由于生产库全备份时间比较长,在备份期间会产生新的归档日志,一般在备份时不重备(总会有持续产生的归档)
这样的控制文件中则记录了已经备份的归档日志与未备份的归档日志,位置不同(带库/生产机相应的归档位置)
前面的参数文件,控制文件,restore database ( 未指定时间与SCN)都正常,但是在recover database时,总是执行增量恢复后,找不到新的归档日志,而system表空间报需要继续恢复才能通过open resetlogs打开数据库???,即使我把生产库的归档日志已经FTP拷贝到恢复环境相同的目录中(恢复database时未指定catalog)
..............
channel ch01: restored backup piece 1
piece handle=bk_17819_1_766711056 tag=TAG1108T203307
channel ch01: restore complete, elapsed time: 00:14:30
starting media recovery
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/test/datafile/jf_system_8g.dbf'
released channel: ch00
released channel: ch01
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/09/ 16:44:54
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 2 seq 17052 lowscn 9809890780178 found to restore
RMAN-06025: no backup of log thread 2 seq 17051 lowscn 9809890448972 found to restore
............
控制文件的记录
2 17252 9810030300315 9810030690796
1 38556 9810030599545 9810030690719
1 38557 9810030690719 9810030845873
1 38558 9810030845873 9810030943024
1 38559 9810030943024 9810031102556
2 17253 9810030690796 9810031103082
NAME THREAD#SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------------------------------------- ---------- ---------- --------------------- ---------------------
1 38560 9810031102556 9810031188846
/arch1/1_38561_756831987.dbf 1 38561 9810031188846 9810031282070
/arch1/1_38562_756831987.dbf 1 38562 9810031282070 9810031522291
/arch2/2_17254_756831987.dbf 2 17254 9810031103082 9810031529600
/arch1/1_38563_756831987.dbf 1 38563 9810031522291 9810031615407
/arch1/1_38564_756831987.dbf 1 38564 9810031615407 9810031707058
/arch2/2_17255_756831987.dbf 2 17255 9810031529600 9810031849806
***************
2. 继上面不知道如何继续之后,就指定恢复到哪个SCN值仍旧失败,只好指定catalog进行recover database 到相应的SCN值,则看到NBU把已经备份的归档日志从带库中restore出来,并且完成recover,最后能正常通过open resetlogs打开,(此时没有看到恢复增量,不知道是不是我指定的SCN值不合理,继续测试此部分中)
但是恢复之后,catalog中的关于数据文件的位置与名称按照我恢复环境的设置而改变了,导致在生产库中查询备份记录也是恢复环境的记录(此部分也是之前测试recover database时没有使用catalog的原因),尝试通过resync catalog不能更改,目前只知道通过unregister database/register database来重新注册生产库才可以,而且catalog中的记录会少很多;
以下为生产库备份记录(其中的数据文件/归档日志名称都为恢复环境的名称,生产环境为裸设备名)
..........................
channel ch00: finished piece 1 at 10-NOV-11
piece handle=bk_17939_1_766883855 tag=TAG1110T203419 comment=API Version 2.0,MMS Version 5.0.0.0
channel ch00: backup set complete, elapsed time: 00:41:31
channel ch00: starting incremental level 1 datafile backupset
channel ch00: specifying datafile(s) in backupset
input datafile fno=00009 name=/oradata/test/datafile/jf_data1_20g.dbf
input datafile fno=00037 name=/oradata/test/datafile/jf_index8_20g.dbf
input datafile fno=00046 name=/oradata/test/datafile/jf_index9_20g.dbf
input datafile fno=00061 name=/oradata/test/datafile/jf_index13_20g
input datafile fno=00005 name=/oradata/test/datafile/jf_users_1g.dbf
channel ch00: starting piece 1 at 10-NOV-11
channel ch01: finished piece 1 at 11-NOV-11
piece handle=bk_17940_1_766884861 tag=TAG1110T203419 comment=API Version 2.0,MMS Version 5.0.0.0
channel ch01: backup set complete, elapsed time: 00:35:51
channel ch00: finished piece 1 at 11-NOV-11
piece handle=bk_17941_1_766886346 tag=TAG1110T203419 comment=API Version 2.0,MMS Version 5.0.0.0
channel ch00: backup set complete, elapsed time: 00:23:11
Finished backup at 11-NOV-11
Starting Control File and SPFILE Autobackup at 11-NOV-11
piece handle=c-2310952676-1111-00 comment=API Version 2.0,MMS Version 5.0.0.0
Finished Control File and SPFILE Autobackup at 11-NOV-11
sql statement: alter system archive log current
released channel: ch00
released channel: ch01
allocated channel: ch00
channel ch00: sid=399 instance=test devtype=SBT_TAPE
channel ch00: Veritas NetBackup for Oracle - Release 7.0 (010501)
allocated channel: ch01
channel ch01: sid=597 instance=test devtype=SBT_TAPE
channel ch01: Veritas NetBackup for Oracle - Release 7.0 (010501)
sent command to channel: ch00
sent command to channel: ch01
Starting backup at 11-NOV-11
skipping archive log file /oradata/test/arch/1_37665_756831987.dbf; already backed up 1 time(s)
skipping archive log file /oradata/test/arch/1_37666_756831987.dbf; already backed up 1 time(s)
skipping archive log file /oradata/test/arch/1_37667_756831987.dbf; already backed up 1 time(s)
skipping archive log file /oradata/test/arch/1_37668_756831987.dbf; already backed up 1 time(s)
skipping archive log file /oradata/test/arch/1_37669_756831987.dbf; already backed up 1 time(s)
...............................
