RMAN恢复实验(1)- SPFILE恢复触发的BUG

最近在复习RMAN的恢复相关主题知识,做了一些RMAN相关恢复的实验,在多套库成功还原多次SPFILE后,再一次测试库中执行恢复时,突然触发了Oracle Bug ,详情如下:

模拟场景:

(1)数据库close并且参数文件丢失:

SPFILE-1无法启动数据库,缺失参数文件,数据库实例无法Nomount

本实验还有一点特殊的地方在于“存在备份且没有配置Catalog”情况,目前的状态是我们有备份,但是无法mount数据库,也就是无法读取controlfile中的备份元数据,无法从备份中恢复SPFILE。但是,RMAN 在设计时已想到了此问题,所以在使用RMAN 备份数据库时RMAN有一项配置:CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default,当数据库备份丢失控制文件与SPFILE时,可借助此特性进行相关数据库启动必须文件“重要文件”的恢复。需要特别说明的是,使用RMAN备份时,即使CONFIGURE BACKUP OPTIMIZATION 设置为OFF,如果备份涉及backup datafile 1也就是system datafile时,会自动强制including current control file in backup set与including current SPFILE in backup set(存放于备份集中,不以操作系统文件的形式存放)

恢复步骤:

(1)数据库缺失参数文件后,可在RMAN中将数据库启动至nomount状态,但是此数据库非我们要恢复的数据库,我们会连接到一个叫做“DUMMY”的数据库,以便我们可以进行特殊恢复。

spfile-2-2

(2)设置DBID开始进行SPFILE文件恢复:

首先我们需要设置DBID,因为要告诉RMAN我们要恢复的数据库标识后,RMAN才会根据此标识去验证我们之前的备份集;备份的控制文件中可以帮我们明确DBID,在默认情况下,控制文件auotobackup存放于$ORACLE_HOME/dbs目录下,如下图所示,这个c-3229794102-20190801-00便是我们需要的控制文件自动备份,其中c-后面的第一占位数字为数据库DBID,也就是3229794102,后面为日期与文件版本信息

spfile-3

(3)设定DBID,指定autobackup contriolfile,restore spfile from autobackup(数据库使用catalog时,可直接restore spfile)

spfile-5

确认恢复的参数文件,发现了奇怪的现象:参数文件被恢复到了+DG_DATA/DB_UNKNOWN/PARAMETERFILE目录中

SPFILE-6

查阅了MOS后发现,有一篇文章提到了此问题(393932.1),

SPFILE-7

我们看到,Oracle 发布了此文提的Bug号:5370663,同时给予了非常有效的解决方式:

SPFILE-8

 

创建PFILE:

 

SPFILE-9

MOUNT DATABASE:

spfile-10

 

RESTORE SPFILE:

spfile-11

可以看到DB_UNKNOWN目录已不存在,参数文件恢复至正确位置。

spfile-13