veritas netbackup恢复步骤

前段时间，做了一次nbu的同机恢复测试。
环境是这样的：
备份和还原都是在一个机器上，hostname是sg2as059。即备份的client是这个机器。数据库的实例名是test.
无catalog数据库，备份信息保留在控制文件中。
备份的master server和media server是同一台机器，hostname是sg2ts001。

前一天晚上设置nbu的policy进行备份，备份脚本在client上：

从备份脚本得知，备份的log是同目录下的，和备份脚本同名的.out文件。
因此我们可以检查一下备份的log，看看是否备份成功，以及获取其他还原时需要的信息：

在这里面有大量一会我们还原数据库时所需要用到的信息，因此该log非常重要，建议也备份到磁带上。

另外，我们也可以通过bplist来看备份集：

sg2as059:/usr/openv/netbackup/ext/db_ext/oracle/test>/usr/openv/netbackup/bin/bplist -t 4 -l -R /

下面我们开始设计一些场景来进行数据库的还原：

场景一：丢失spfile：
如果我们丢失了spfile，我们可以以下方式还原：
1. 用rman连接数据库，注意由于没有spfile，数据库无法启动，需要现在rman下启动一个dummy数据库。另外，由于数据库还未启动都mount状态，因此无法用rman sys/change_on_install@tnsname的方式连接数据库。只能用os鉴权的方式登录。

2.因为要恢复spfile，我要set dbid，由于没有用catalog，我们无法list incarnation，我们只能从备份的log去找dbid，注意log中的以下信息：

因此我们获得dbid是2051517555。

3.restore spfile，注意我们由于是同机恢复，因此写与不写环境变量都没关系；如果是异机恢复，就必须在rman中写上环境变量。在这个例子中，我们写上环境变量来进行恢复。
另外这里注意需要指明是从那个backupset中恢复。我们需要去查备份的log，确定spfile的备份是在哪个备份集中：

因此，利用上述信息进行spfile的还原：

注，关于上述的client和server的信息，可以根据bp.conf 文件来确定：

在此过程中，可以在nbu的控制台看是否已经restore操作。
也可以另开窗口，看到该rman的等待事件是sbtrestore。
另外，也可以看nbu的log，如果没有新log产生，说明备份还停留在rman部分，没传递给NBU。

还原spfile后，关闭原来的dummy数据库，正常启动数据库。

场景二：丢失控制文件。
丢失控制文件的场景和丢失spfile类似，而且步骤根据简单一些，不需要启动dummy数据库，根据log选择控制文件。

数据库需要启动到nomount状态：

还原控制文件之后，resetlogs启动数据库。

场景三：丢失数据文件

场景四：丢失redo log.
由于redolog不在rman备份范围之内，因此在做恢复的过程不需要nbu的参与，只是常规恢复。
如果丢失的redolog不含active或者current的redo，用recover database until cancel+resetlogs打开；
如果丢失的是active或者current的redo，就需要用_allow_resetlogs_corruption的隐含参数+resetlogs打开。
这里不展开叙述。

场景五：丢失全部文件（控制文件数据文件和日志文件）。
注意会自动restore arch，需要留心arch目录的大小。

【Trouble shooting】
一、恢复时，如果用parms来传递环境变量时会报错sbtinfo2，解决方法是用send，而不是parms：

二、恢复spfile时，如果用from autobackup，会挂死，NBU找磁带会非常慢。该rman的等待事件是sbtinfo2。解决方法是指明from某个备份集文件，这就要到备份的log中去找了。

此时去看等待事件：