环境:

生产库---> 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=TAG20111108T203307

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/2011 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=TAG20111110T203419 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=TAG20111110T203419 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=TAG20111110T203419 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-20111111-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 (2010010501)

allocated channel: ch01

channel ch01: sid=597 instance=test devtype=SBT_TAPE

channel ch01: Veritas NetBackup for Oracle - Release 7.0 (2010010501)

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)

...............................