前期的处理方法：
    1、 redo次序颠倒：在update中加入了判断，如果update的rowcount小于1，则直接插入这条记录；这个处理方法，减少了很多的维护量，但是危害也是有的；
    2、 Oracle导入堵塞：人工解决；
    3、 内外网无警示：无协助的人工监视；
    4、 实例过多：暂时放下；
    5、 财政网络不稳定：财政态度爱理不理；
    6、 单主键同步方法的漏洞：没发现；
    7、 内外网数据不一致：知道但没决心解决，也是对内外网的信心不足所致；
    8、 无主键的表的行定位：没发现；
    9、 该有主键却没设主键的表：没发现。
    对于上述的解决方法，只是短暂的压制了这些问题或者用人力来搭救，然而，这些问题的根源？并没有持之以恒地去寻找和尝试解决方案。
    对于redo次序问题，是众多问题中的大头，也是很多问题的起源，这个问题是怎样解决的呢？在这两年，我也断断续续的了解到内外网的一些问题（主要是redo的执行次序问题），也知道这个问题最终没有得到实质性的解决。一个差不多2年了的问题，可以大概估计这个问题给公司多少的人力的花费，而且还没有算上它所附带的其他问题带来的负担。
    让我们一起思考redo的次序问题：此问题只有从外网到内网的过程中才发生过（内网到外网基本没有发生），外网的Oracle数据库是RAC集群，内网是双机热备，任何时候都只有一台Oracle数据库服务器在服务；记得开始的时候，大家都觉得是不是sequence出了问题，在上一年，某人找到了sequence在RAC中的一个顺序问题（其实不是问题，是一些设置相关的东西罢了，不是Oracle的bug），可没发现有人拿去在线测试（这里不得不说：公司内没有搭起相应的测试环境来模拟这些问题，也或者是我不知道）；然而在最后解决的时候，发现根源其实是：1、redo的时候，依赖的次序首先是时间，然后才是ID，这个是设计者的严重错误(我也忘记我当时是这样想的……)；2、外网的ORACLE集群的时间没有同步，相差了几分钟。在把redo的次序改为使用ID便把问题解决了（同时加入了sequence的order参数，强迫按顺序返回sequence但损失了一些性能）。
    在思考了redo次序问题后，紧接着就是需要把现有的所有问题暴露出来，如何暴露？简单的说就是把所有不应该发生的错误都揪出来，即使让内外网不能正常运作，也要把这些问题揪出来。方法就是把所有用于掩盖不该有的问题的代码全部去除（主要是对update/delete语句的rowcount不为1的忽视）。当这步走了后，立刻接着就有不少问题出现了，比如上面列出的6、7、8、9号问题。
    写这些，其实只是想表达对待问题的态度，问题出现了，如果短时间解决不了，是可以想些方法延缓，但问题还在，因此解决问题的步伐绝不能停，因为你仅仅是把问题盖住了，它还在里面捣乱，只不过现在有一块板把它挡住了，你看不到，也没被刺痛，但是当这块板挡不住的时候，你会发现里面的东西已经不再想开始时那么细小，它们已经质变到另一个层次的问题了，你要解决它所需要付出的时间和精力也同样的增大了不知多。
    因此，每个问题都必须记下来，花精力去解决或者弱化它所产生的影响，每个问题都是系统的毒疮，开发人员就是医生，维护人员就是护士，医生不管，护士就累死，每天拼命的用一些不能根治的药去"治疗"这些毒疮（胡扯了一把……）。