R3 数据库迁移方案

woshiyiziyu · 发表于 2015-12-30 10:38

andzen 发表于 2015-12-29 15:46
直接解析ORACLE dbf文件格式，分析成数据包，通过网络传递到对方，直接加载到11g数据库

方便透露一下产品名字吗？

andzen · 发表于 2015-12-30 16:23

woshiyiziyu 发表于 2015-12-30 10:38
方便透露一下产品名字吗？

DSG 到网上搜一下

woshiyiziyu · 发表于 2015-12-31 11:02

andzen 发表于 2015-12-30 16:23
DSG 到网上搜一下

1、效率高、速度快
　　与其它同类迁移技术相比，无论是采用SnapAssure、XEXP/XIMP还是RealSync等任何一种迁移方式，在效率上和性能上都远远高于其它同类解决方案。例如，在杭州电信采用RealSync方式在2个多小时完成了1.9TB数据的迁移工作。

　1、杭州电信：杭州电信IBSS系统，需要将HP-UX上的Oracle 8i数据库升级到AIX平台的Oracle 8i数据库上。数据量大小约为1.9TB。在杭州电信采用DSG RealSync的迁移工具后，1.9TB的数据能够在2-3小时内将数据导出并装载完成，create index需要的时间约为10个小时左右。

如上图所示，RealSync在Data Source端和Data Target端分别安装Agent进程，Source端的Agent进程对ORACLE日志进行监控，发现改变及时对目标数据库进行更新。

当应用系统在Data Source端向数据库进行任何操作时时，这些信息都将在Redo Log中保存，RealSync Agent通过对实时获取的Log日志进行分析，获得本次操作的交易指令和交易数据，然后将这些交易指令和交易数据经过格式转化生成DXF数据格式，并实时通过网络传送到Data Target系统。

DataTarget系统的RealSyncAgent接收数据库包，经过校验码检查，确认正确的数据库包后，调用Oracle函数按照交易的先后顺序在DataTarget系统中执行该交易。

和爱数、浪擎一样，第一次同步的时候必须全备份然后恢复到目标系统上，之后追加归档日志。

sydongsun · 发表于 2015-12-31 12:48

本帖最后由 sydongsun 于 2016-1-7 09:24 编辑

看看了大家的讨论，我来说说，数据迁移，SAP主流的技术：
1. Client拷贝；（典型应用场景：比如用生产机的client拷贝得到一个测试系统所用的client），虽然不够快，但是简单好用。注意拷贝过程中的数据库日志和空间不要满了。

2. 同构系统的基于数据库的备份恢复的方式，得到一个新的系统。（典型场景: 比如服务器更换为新的更好的，但是操作系统的平台，数据库系统的平台保持不变,或者也使用生产系统，来得到一个新的集成测试系统）。这种方式的要求是平台，数据库版本版本基本保持不变，但是速度是非常快的，比如对Oracle数据来说，对生产系统的停机时间是非常短的，因为我们只需要把生产机停机时的，数据库系统的数据文件，控制文件等拷贝到临时的磁盘上即可。如果是SSD的硬盘，现在的速度都可以达到上百兆每秒了。可以想象10T的数据拷贝下来也用不来多久了，通常企业的几T的数据，30分钟足够。到另外一个新的系统中产生新的系统，也是非常快的。因为没有数据库内容的导入导出，直接是基于数据库文件的数据一致性的恢复过程。这个过程如果需对实例名修改，在完成得到一个新的系统之后，需要对系统做一些配置上的修改。

3. 第三种类的方式，基于SAP的migration向导的数据导出，再在新的系统导入，支持异构系统（不同操作系统平台，不同数据库的版本，甚至不同的数据库）。这种方式虽然稍稍慢一些，但是也操作简单，速度没有方案2那么快，但是自由，没有什么限制。尽管稍稍慢一些，但是异构系统生产系统迁移本身是一个大动作。如果确实需要2-3天，那么就2-3天，和管理层争取时间即可，找一个合适的时间，比如国庆假期，或者周末。如果业务停顿确实损失较大，不太容易，导入新的生产机的所需要的那段，可以让用户继续在原来的系统中做业务，比如关键的生产。至于其他财务，销售，采购等业务可以暂时先不做进系统，等新的生产系统导入好了。让用户再在新的系统手工补上同样的业务即可。
还有一种我想象的方式，就是方式2和方式3的结合，先用方式2而得到一个系统，然后再基于该系统导出数据，生产最终的目标的异构系统。

我的建议。如果是采用的其他的方法。还需要花费很多的时间验证可行性。关键这个东西还不是那么方便做测试

w39 · 发表于 2015-12-31 20:36

直接导出数据库，风险很大吧？

wuhanmajie · 发表于 2016-1-4 08:59

本帖最后由 wuhanmajie 于 2016-1-4 09:05 编辑

sydongsun 发表于 2015-12-31 12:48
看看了大家的讨论，我来说说，数据迁移，SAP主流的技术：
1. Client拷贝；（典型应用场景：比如用生产机的 ...

我也觉得sap的migration最靠谱，几乎不需要进行数据验证。
另外，client copy似乎对表有求，如果表数目或字段不同，是无法copy的，所以只能适用于同一个系统内的copy

wuhanmajie · 发表于 2016-1-4 09:00

w39 发表于 2015-12-31 20:36
直接导出数据库，风险很大吧？

确实，在数据库层面搞是有快的办法，但验证花的时间恐怕更长，不大敢用！

wuhanmajie · 发表于 2016-1-4 09:20

本帖最后由 wuhanmajie 于 2016-1-4 10:21 编辑

sydongsun 发表于 2015-12-31 12:48
看看了大家的讨论，我来说说，数据迁移，SAP主流的技术：
1. Client拷贝；（典型应用场景：比如用生产机的 ...

SAP迁移.pdf (526.06 KB, 下载次数: 64)

这个是在网上搜索的一篇文章，貌似迁移成功了，也是因为SAP MIGRATION时间太长，用了别的办法，大家再看看可行吗？

woshiyiziyu · 发表于 2016-1-4 09:50

wuhanmajie 发表于 2016-1-4 09:20
这个是在网上搜索的一篇文章，貌似迁移成功了，也是因为SAP MIGRATION时间太长，用了别的办法，大家再 ...

文档已经损坏，无法打开，如果是纯粹as abap系统，直接导出数据库没有问题，如果带as java的话，还是用sap的迁移方法吧。

wuhanmajie · 发表于 2016-1-4 10:19

woshiyiziyu 发表于 2016-1-4 09:50
文档已经损坏，无法打开，如果是纯粹as abap系统，直接导出数据库没有问题，如果带as java的话，还是用sa ...

已更新文档