总结1:
使用ASM存储,进行恢复过程中,数据文件的名称,控制文件的名称,重做日志文件的名称会进行改变,如果创建时采用了+oradata2这样的格式创建。如下可以知道控制文件名称就发生了改变。
1 拷贝参数文件并将集群的一些参数进行修改。
2 根据pfile启动到nomount状态。
3 恢复控制文件(查看原来的控制文件名称和新库名称)
[oracle@oggdb1 ~]$ more 123.ora |grep "control_files"
*.control_files='+ORADATA1/ARSYSTEM/CONTROLFILE/current.261.1039973789'
[oracle@oggdb1 ~]$ sqlplus / as sysdbaSQL*Plus: Release 19.0.0.0.0 - Production on Sat Jul 15 11:08:58 2023
Version 19.18.0.0.0Copyright (c) 1982, 2022, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.18.0.0.0
SQL> show parameter controlNAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string +ORADATA1/ARSYSTEM/CONTROLFILE
/current.383.1142247395
4 还原数据库。
5 恢复数据库。
我们发现在还原数据库时,最后报错磁盘组ORADATA1空间不足,就很差异,因为原来欢迎
asmcmd>du arsystem 3T
asmcmd>du arsystem 4.9T
合计大小也就才3T,而新环境的ORADATA1配置的5T为啥还会不足?????
发现大部分的文件原来是ORADATA2也创建在了ORADATA1就很差异。
于是想到的是,在restore过程中还是使用OMF方式,
查看OMF参数
*.db_create_file_dest=‘+ORADATA1’
于是在pfile中将参数修改为空,重启数据库,重新进行restore,正常了。
总结:rman在对ASM存储的文件进行恢复的时,不是按照原来文件的名字进行重新创建的,而是修改了按照对应的磁盘组,修改了数据文件name。
数据文件23号的位置
老库查看23号数据文件位置名称
channel ORA_DISK_1: restoring datafile 00023 to +ORADATA1/ARSYSTEM/DATAFILE/histbs03.281.1040310061
新库查看23号数据文件位置名称
SQL> select name from v$datafile where file#=23;
NAME
--------------------------------------------------------------------------------
+ORADATA1/ARSYSTEM/DATAFILE/histbs03.374.1142247959SQL>
自动调整到了控制文件。
1 使用ASM存储恢复数据文件1
restroe datafile 1;
如果使用了OMF 参数 ,则 文件自动创建到对应的磁盘组。而且数据文件1 的名字也将改变和原来的不一致。