恢复数据文件到文件系统却到了asm

有一套系统,是dataguard,primary是使用asm,standby是使用文件系统,通过db_file_name_convert来转换数据文件的路径,平时的备份是放在standby主机上做,即备份standby上的文件,备份信息是放在catalog库。

有一次做恢复,在恢复主机上,运行了rman target / catalog user/passwd@catalog,连接之后,先restore了控制文件,在sqlplus中发现控制文件中指向datafile的路径是asm上的路径(即primary上的路径),通过rename之后,修改成了文件系统的路径。但是当再次rman target / catalog user/passwd@catalog连接上去,运行restore database时,发起的恢复通道看到,竟然是恢复到asm路径上的。

为什么备份standby上的文件,做restore时,会恢复到asm路径上?

这里就涉及到dataguard中一个很重要的概念,db_unique_name。在默认情况下,db_unique_name等于db_name,即如果不显式设置db_unique_name,则db_unique_name=db_name。dataguard环境中,经常设置这个参数为不同的值,如primary中设置db_unique_name为和db_name一样的值,在standby中设置db_unique_name为sty_db_name。

那么,我们在恢复主机,如果不显式设置db_unique_name,那么db_unique_name就为db_name,此时就是primary的库了,所以做restore的时候,去catalog找的就是primary的信息,因此datafile的路径也是asm上的路径。

我们可以在恢复主机运行report schema看到:

RMAN> report schema;

using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name MYDB11 <<<<注意这里,由于用的是primary的unique name,所以下面也是primary的路径。

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    780      SYSTEM               YES     +DATA/small_diskgroup/mydb/mydb11/dfile/SYSTEM01.DBF
2    710      SYSAUX               NO      +DATA/small_diskgroup/mydb/mydb11/dfile/SYSAUX01.DBF
3    1040     UNDOTBS1             YES     +DATA/small_diskgroup/mydb/mydb11/dfile/UNDOTBS01.DBF
4    5        USERS                NO      +DATA/small_diskgroup/mydb/mydb11/dfile/USERS01.DBF

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    67       TEMP                 32767       +DATA/small_diskgroup/mydb/mydb11/tfile/TEMP01.DBF

RMAN>

如果此时在恢复主机,需要恢复到文件系统,那么在pfile或者spfile中,必须加上db_unique_name,才能恢复成在standby一样的文件系统路径。

设置db_unique_name=sty_mydb11,那么重新启动之后,还是rman连接到catalog库,report schema就会显示不同的内容:

RMAN> report schema;

using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name STY_MYDB11 <<<<加上standby的db unique name,那么恢复出来的就是文件系统的路径了。

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    780      SYSTEM               YES     /u01/MYDB11/APP/ORACLEUSER/ORADATA/MYDB11/SYSTEM01.DBF
2    710      SYSAUX               NO      /u01/MYDB11/APP/ORACLEUSER/ORADATA/MYDB11/SYSAUX01.DBF
3    1040     UNDOTBS1             YES     /u01/MYDB11/APP/ORACLEUSER/ORADATA/MYDB11/UNDOTBS01.DBF
4    5        USERS                NO      /u01/MYDB11/APP/ORACLEUSER/ORADATA/MYDB11/USERS01.DBF

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    67       TEMP                 32767       /u01/MYDB11/APP/ORACLEUSER/ORADATA/MYDB11/TEMP01.DBF

RMAN>

这个问题,本来客户primary和standby使用文件系统,且都是相同路径,问题没那么容易暴露,但是随着客户越来越多的系统迁移到asm上,问题就暴露出来了。

相关文章

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据