迁移需求:
1、两边数据保持一致
2、停机时间很短
3、不借助移动硬盘之类的设备
4、nocatelog
背景:
1、两边数据库和OS版本一致
2、DML操作比较频繁
3、原数据库数据量很大
分析:
1、实现方式有多种,如prebuild MV、RMAN、DG、host cp等
Prebuild MV需要做的后续工作太多;DG配置复杂
用rman的话,因为库比较大,如果本地空间不足,备份就可能失败。另外,就算空间足够,因为在传送过程也会耗时不少,这段时间会产生很多的归档,要应该这些归档也会很慢,不满足停机时间很短的需求。
用host cp的方式,通过一些取巧的办法可以满足需求。
步骤:
1、将表空间置于begin backup状态
2、用ftp或者scp等传送数据文件到目标服务器对应目录上
3、将表空间置于end backup状态
4、将归档日志拷贝到目标服务器,并将最后几个归档改名或者移到其他路径
加入主库有N组联机日志,则把最后N个归档改名(可以不改名或移动,但以防万一最好这样做,否则恢复可能有问题)
5、拷贝密码文件和联机日志到目标库上
之所以要拷贝联机日志是因为在目标库recover database的时候会检查日志头,如果发现日志大小或日志组信息不吻合,recover将会失败。
6、在源库alter system backup constrolfile to trace;
然后打开这个trace文件,选择noresetlogs这部分内容
7、在目标库startup nomount,然后重建控制文件(如果两边路径不一致,需要编辑trace的内容)
8、在目标库recover database
9、recover database完成后关闭目标库
10、停止源库,拷贝密码文件和联机日志到目标库上
11、把新产生的归档拷贝到目标库上
12、在目标库上把第4步改名的归档名字改回来
13、重复7、8步
14、alter database open
这里主要是利用重建控制文件的方式先应用在传输数据文件期间产生的归档,使得最后一次recover只需要应用在第一次recover期间产生的新归档,那样,最后一次recover的时间大大减少,停机时间也大大减少。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/231499/viewspace-63814/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/231499/viewspace-63814/