关于最小停机时间的oracle迁移想法，请大家指正~

jieyancai

做dataguard也是有风险的。楼主的办法也是可行的。
但步骤需要修改一下：
1.生产环境为归档模式，我用rman做好full backup，包括控制文件和pfile，传递到目标机器
2.目标机器上搭建相同的目录结构，装好oracle软件，用生产环境的pfile文件启动到nomount，从生产机的full backup里恢复控制文件，然后mount，还原所有数据文件，还原所有归档文件，然后recover。这时虽然可以resetlogs打开，但不要打开.
3.在生产库切换日志归档，将最新产生的归档传到目标机器。
4.在目标机器采用sqlplus 启动到mount状态，然后SQL> recover database using backup controlfile until cancel;
根据提示输入归档的文件路径应用归档
5.在生产库最后切换一次日志，然后停库shutdown immediate（只是这边shutdown停库的一个短暂时间）
6.将归档传至目标库，继续4步骤应用完毕后resetlogs打开即可。（这个时间很短）
7.修改客户端的tnsnames连接IP等等。

第6步没有必要将控制文件也传递，如果生产库一直没有发生数据结构变化（比如新建表空间，新加数据文件等），目标库可以自动应用。
如果发生了结构变化，类似下面例子，会报错，但只需create datafile as即可：
SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 492287 (在 03/14/2008 13:46:32 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\JYC\ARCHIVELOG\2008_03_14\O1_MF

1_%U_.ARC
ORA-00280: 更改 492287 (用于线程 1) 在序列 #11 中


指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
D:\oracle\product\10.2.0\flash_recovery_area\JYC\ARCHIVELOG\2008_03_14\O1_MF
1_3XN6GZF5_.ARC
ORA-00283: 恢复会话因错误而取消
ORA-01244: 未命名的数据文件由介质恢复添加至控制文件
ORA-01110: 数据文件 5: 'D:\BAK\TEST.DBF'


ORA-01112: 未启动介质恢复


SQL> select name from v$datafile;

NAME
----------------------------------------------------------------------------

D:\ORACLE\PRODUCT\10.2.0\ORADATA\JYC\SYSTEM01.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\JYC\UNDOTBS01.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\JYC\SYSAUX01.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\JYC\USERS01.DBF
D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00005

SQL> select name from v$tablespace;

NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
TEST

已选择6行。

SQL> alter database create datafile 5 as 'd:\bak\test.dbf';

数据库已更改。

SQL> recover database using backup controlfile until cancel;
然后继续应用归档。
最后SQL> alter database open resetlogs;

打开即可。

jieyancai

原帖由 feng_xin 于 2008-3-14 14:41 发表


这个得看做具体操作的DBA了，如果这个DBA有dataguard的经验，dataguard当然是最好的方案。
如果这个DBA没有dataguard的经验，但是日常经常做backup/recovery，有recovery的经验，recovery就是最好的方案。

迁移在任何一个公司都是大事，要选最稳妥的方案，而不是最优的方案。

严重同意！

brotherxiao

原帖由 feng_xin 于 2008-3-14 14:41 发表


这个得看做具体操作的DBA了，如果这个DBA有dataguard的经验，dataguard当然是最好的方案。
如果这个DBA没有dataguard的经验，但是日常经常做backup/recovery，有recovery的经验，recovery就是最好的方案。

迁移在任何一个公司都是大事，要选最稳妥的方案，而不是最优的方案。

其实是一样的，Dataguard本身就是recover，switch over已经是计较成熟稳定的方案了。

wobenkl

楼主的方法也不错，用自己熟悉的技术更安全

feng_xin

原帖由 brotherxiao 于 2008-3-14 14:48 发表



其实是一样的，Dataguard本身就是recover，switch over已经是计较成熟稳定的方案了。

从技术上来说，是的。
从管理上来说，不是。

方案=技术+人

kangaroo76

1. 可能的话用BCV会更加方便快捷
2. 如果只是服务器的迁移而存储不变的话，底层存储连接上，把VG或DG导入到新系统不就好了吗

苗条胖男孩

呵呵，多谢大家关注我的问题！！！
这个方法我已经实验过了，是没有问题的，feng_xin 说的是，我对DG还是不够熟练，相对来说这个方法更熟练，而且对生产环境不需要修改任何参数，感觉上比较安全；
并且由于实施的计划问题，这个动作需要重复做几次，所以我觉得这种实施更方便吧。
DG应该是个好方案，可惜不熟，要抓紧搞一搞了。
再次感谢各位！