今天开发同事碰到一个有些复杂的数据复制需求，想让我帮忙看看能否实现，当然猛一听需求是不可能实现的。不过还是耐着性子和他们讨论了一下，不过我想了下，似乎还是有改进的余地，也算是拨云见雾吧。
目前有一个表做了拆分，即分库分表。在统计业务中还是需要把数据整合起来查询。大体就是下面的架构方式。
源端是一些分库，存在一些不同的用户，里面存放着相同结构的表。数据根据拆分规则进入不同的分库。
目标端是统计业务所用，没有使用OGG,而直接使用物化视图的方式做了数据刷新复制，当然目标端由此就有了相同数量的物化视图，为了让应用端查取方便，于是建立了一个同名的视图，这样就达到了一个基本的数据拆分到整合的过程。
但是数据有一些问题。假设表中存在下面的字段，那么其中一个字段modify_date就是数据记录的修改时间戳。
应用端可以根据这个时间戳来进行数据的统计分析，而且目前来看只有增加和部分修改，没有删除操作，但是恰恰不如意的是，这个字段因为不同产品的期望，目前是可为空的，而对于统计业务来说又是必须的。
对于统计业务来说，不会可以关注精确的时分秒，精确到日即可。于是我们就有了一些讨论。
开发同学
有个疑惑，BI这边是今天取昨天的增量数据，假设今天取数据的时候出错了，过了几天我想修复历史数据，还能知道前天增加了哪些数据吗？
goldengate也是使用主键吗
DBA:
这是两个问题，如果取数的时候出错了，按照目前的数据一致性，那么剩下没有应用到的数据是肯定不会应用到目标库的，所以数据层面的修复是平滑的。
第二个是查看之前增加的历史数据，Oracle有些辅助功能可以实现，不过得看你的需求，不一定能完全实现。
开发同学：
就像现在这个数据，很多modify_date是空的，我们就很想知道2008年01月01日的增量数据
就是每一天的增量，好实现吗？
DBA：
你说的增量是新增的还是修改的也算，新增的那就简单了，可以用分区，如果是修改的，这个还比较麻烦。
那样得确认一点
比如1月1日 新增了100条数据
1月5日，新增了200条数据，
同是修改了1月1日的2条数据。
那这两条数据是算在1月1日还是算在1月5日。
开发同学：
恩·是这个问题，算1月5日的
因为BI这边会按这个时间建分区，虽然1月1日的分区里也有这条数据，但是不会导致丢失，这边可以取最新的使用
DBA:
对，按照时间建分区，分区设置上做一些特定的设置，可以的。(其实就是开启row movement,可以跨分区更新)
但是想起来思路是通，但是这就有两个大问题需要解决了。目标是物化视图刷新，因为物化视图是只读的，如何修改modify_date的值就是个大问题。
如何得到这些增量变化的数据，目前来看，时间的部分只能依赖于系统时间了。但是增量的数据如何鉴别，我一个设想就是根据modify_date来分区。
这样一来，架构方式就是如下的形式：
根据分区的方式，数据就能够区分开来了。但是增量的数据如何鉴别，这是个很实际的问题，这个时候我们就可以联系一些更具体的信息了，那就是物化视图日志，在源端，每个表开启增量刷新，必然要创建一个物化视图日志，这个物化视图日志里面的数据说不上完整，但是有主键ID和基本的时间戳，这就够了。我们可以在增量刷新之前得到一个基本的id列表，然后关联分区的方式修改数据为系统时间，这样一来，数据就会从默认分区流动到指定的分区中。后续供统计分析所用。
看起来不大可能的需求还是有一些的应用场景，估且算是一个特殊的刷新场景吧。
个人微信公众号如下，欢迎扫描关注。