记一次数据同步需求的改进(三)

在之前的博文中分享过两篇关于数据同步的问题，链接如下：
http://blog.itpub.net/23718752/viewspace-1817817/
http://blog.itpub.net/23718752/viewspace-1819981/
最开始开发的同事也是提出想让我做一个数据的增量同步，起初他们是希望能够根据时间戳来得到增量的数据，这种方案有一个缺点就是对于update,delete的操作，这种数据变更就很难从源库中去甄别。所以最后我还是建议他们通过物化视图的增量刷新来实现这个需求，对于dml的操作情况得到的增量数据都可以很轻松同步。
下面的图是在改进前和改进后数据库层面归档日志的切换频率，可以看到使用物化视图的增量刷新之后，redo生成量大大降低，已经从统计图中看不到日志切换的影响了。

那么这种方案是不是一定是最好的呢。实践和时间真是检验这些的一把标尺。
首先修改前和修改后这个同事进行了确认，一切都在计划之中，数据刷新速度很快，而且他们这边也没有任何的影响，但是当天下午又有几个部门的同事就开始主动找我了，一部分说他们的程序端开始报错了。另一部分说他们访问不到这个表了，希望我来看看。所以问题看似解决了，还是需要一步一步来，我们来总结一下。
第一个问题是程序端开始报错，是因为在重建表的过程中，我也不知道会影响到他们的部分，所以这个时候会有一个改进之处就是在做这类变更的时候还是需要发一个公告，或者维护声明，这样可以提前安排，提前告知，不过因为是统计业务，简单沟通之后，他们重新查看，程序里就恢复正常了。
接着第二个问题，是另外的同事说程序里提示表找不到了。
我再简单说说问题背景，这个表做了分库分表，所以目前存在12个用户，4个数据库中存在同样名字的表，但是里面的数据是不同的。在统计库1中是目前是创建了物化视图，然后对外显示是一个视图，其实这个视图就是包含了这十二个物化视图的数据。结构如下所示。

而目前的情况是现在存在一个统计库2需要访问统计库1中这个表的数据。这个时候情况就是下面的样子。
统计库2是通过db link来访问统计库1中的这个”表“的，为什么一定需要在统计库2中也要这个表呢，为什么不能放在统计库1里直接查呢，我也带着这个疑问和开发同事进行 了确认，得到的反馈是因为统计库2中也存在一个表，假设为表2,表2和统计库1中的这个”表“需要关联。

如果按照这样的情况，为什么在统计库2中访问不了了，关键的原因还是在于这个视图，在统计库2中是无法直接访问统计库1中这个视图的。尽管创建了同义词，存在db link，但是统计库1中的基表没有相应的db link在统计库2中。
所以一种思路就是在统计库2中也创建12个db link的同义词，然后在统计库2中也创建出一个视图来。所以实现方式如下图所示。

这种方式这是解决了这种访问的问题，而且看起来确实还比较繁琐。统计库1要做的事情，统计库2也需要再做一遍，统计2中需要基于统计库1中的12个物化视图在统计库2中也创建出12个同义词来，然后在统计库2本地创建出一个视图。
那么还有什么改进思路呢，而且还需要保证性能和可用性。
其实还有一种思路，那就是统计库2中也使用物化视图来增量刷新，但是这个增量刷新不是取四个分库的数据，而是直接从统计库1中增量刷新即可。每次统计库1刷新之后，统计库2再刷新一次，得到的就是增量的数据了。采用下面的方式即可。

这种方式能够保证在本地的方式，所以说其实本地的才是最好的。当然也需要一定的空间，而且这个空间需要应该还是需要的，而且也算是合理的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1875693/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-1875693/