直接使用FTP在原有DG的情况下克隆或迁移DG

直接使用FTP在原有DG的情况下克隆或迁移DG

本章讲的是利用ftp直接传输DG进行DG的克隆或迁移
在备库DG数据文件放在文件系统的情况下，ftp来直接传输可以简化重新搭建DG的过程，尤其是当主库使用ASM存储的情况。
如果是克隆，需要注意的有监听和LOG_ARCHIVE_DEST_3的参数的添加
如果是迁移，需要注意监听ip的设置
以下是具体步骤：
参数注意db_file_name_convert的修改。可以存在与原备库db_file_name_convert参数不同的情况。
参数修改和文件拷贝，监听，tnsnames，密码文件就不详细说了
备机数据库关闭，监听停掉
ftp将数据文件传到另一台备机，注意权限
主库创建个standby controlfile传到备库，备库控制文件改名覆盖(可选)
备库起到nomount状态
再起到mount状态alter database mount standby database
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
在实际处理中，发现日志传过来了但是没有应用，手工进行恢复报以下错误
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel;
SQL> recover standby database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 29: ‘/oradata/samp/app/logmnr02.dbf’
ORA-01157: cannot identify/lock data file 29 – see DBWR trace file
ORA-01110: data file 29: ‘/oradata/samp/app/logmnr02.dbf’
而现在这台DG数据文件的目录应该在/Tbackup下，而/oradata/samp/app/是生产库和备库的数据文件存放的位置
从v$datafile里查看得到信息：
NAME CREATION_TIME
—————————————- ——————-
……
/Tbackup/samp/oradata/undotbs02.dbf 07/22/2008 17:53:00
/oradata/samp/app/logmnr02.dbf 07/10/2011 13:35:10
原备库的DG在11年7月初左右就搭建好了，可以分析如下：
如果用备库传来的控制文件mount的话，此时建议在v$datafile里检查下文件的路径是否对应，可能存在不一致的问题。从文件创建时间上来看，是DG搭建完成后新创建的datafile。但是写到控制文件里的路径和生产库是一样的，实际路径倒是没问题。由于原备库和生产库数据文件存放的位置，可能与db_file_convert参数以及备库的standby控制文件属性有关
重新rename就可以了
alter database rename file ‘/oradata/samp/app/logmnr02.dbf’ to ‘/Tbackup/nbgs/oradata/app/logmnr02.dbf’
//SQL> alter system set standby_file_management=manual scope=memory;
//SQL> alter database rename file …
//SQL> alter system set standby_file_management=auto scope=both;

之后手工进行恢复
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
SQL> recover standby database;
select SEQUENCE#,applied from v$archived_log;

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24005010/viewspace-710280/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24005010/viewspace-710280/