Oracle 压缩包 5GB 数据库，定期需要导入另外的系统，有什么优化方案。

[Oysmart]

Oracle 压缩包 5GB 数据库，这 5GB 压缩包全量数据库 DB1，为上级单位下发数据。
最头疼的是每半个月需要定期将数据库 DB1 导入下级机构另一个系统 DB2，求个优化的方案？
定期将 DB1 导入到下级机构的数据库 DB3，然后通过物化视图增量刷新 DB3 到 DB2 ？

[yeqizhang]

你是不是描述重复了好几次？
你的全量数据同步，我不知道是不是所有表需要同步，会不会增表这种情况。
之前我们做的，只是同步几十个表，另外两个系统那边只做查询，所以不关心序列的问题，
采用的方式时，每天凌晨两点全量导出，然后其它两个系统定时在凌晨三点 ftp 下载这

[yeqizhang]

额，没打完，就按到了回复，我继续说说

[yeqizhang]

之前我们做的，只是同步几十个表，表的结构不能变（上游的结构变了，下游也要跟着设置就好）。另外一个系统那边只做查询，所以不关心数据库序列的问题，采用的方式时，每天凌晨两点定时跑脚本全量导出，然后其它一个系统的数据库服务器定时跑脚本在凌晨三点 ftp 下载这个导出文件，然后导入到一个临时用户中（导入这个临时用户前会清空所有表数据），然后用 merge 临时库表中增量的数据到正式库表中。
（我把两个系统改成一个了，这样会描述会清晰点）

[Oysmart]

@yeqizhang 上级单位数据是打包 FTP 形式下发，这个没办法控制。
现在就是要将上级下发的全量数据导入到本地系统。表变动不大。

[Oysmart]

@Oysmart 有时候会卡壳，悲催，估计是硬件不行。

[yeqizhang]

@Oysmart 这个看你们其它两个系统是怎样的了，因为之前我们上游数据库老是加字段，导致经常会有表同步失败。我这种做法是之前的人写的，我后面接手维护了。感觉也是不太好的，不过根据业务还是可以的。毕竟直接用户的所有东西全删再导入风险很大

[yeqizhang]

@Oysmart 用的 exp 还是 expdp ？

[xcstream]

看上去没多少数据 比手机的内存还小

[dog82]

5G 数据对 oracle 来说毛毛雨啦

[dog82]

oracle 迁移有种类似嫁接的方式，移花接木。具体叫啥名字忘记了。
说白了就是把数据割下来传过去然后再接上去