oracle恢复数据到asm,恢复数据文件到文件系统却到了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 <<<

如果此时在恢复主机，需要恢复到文件系统，那么在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 <<<

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