今天有同事告诉我系统中采用高级复制技术同步的一张表和源表没有同步。
ITPUB个人空间Nwy` M7na&C系统的高级复制采用了只读物化视图复制方案，因此，不会出现冲突的问题。而且，高级复制环境一向运行比较稳定，没有出现什么问题，怎么会突然不同步了？难道高级复制还有bug？
带着这个疑惑，我登陆了Oracle。检查高级复制环境，似乎没有任何问题。于是检查了一下JOB，发现JOB上次执行时间为14:00，而我的设置是半个小时执行一次，难道JOB停掉了？由于已经到了下班的时间，所以负责数据的人员相对比较着急，我也想尽快解决问题，于是没有细看，就继续检查是否是系统的bug引起的JOB停止。
Oracle的9204有一个bug，即系统运行时间一旦超过497天左右，就会使系统的一个变量发生溢出，导致Oracle的job不再自动运行。升级到Oracle9206可以解决这个问题。其实这个问题在一年多前已经碰到过一次了，上次就是通过重启操作系统解决的。难道时间又到了？
记得EYGLE的网站上对这个问题有比较深入的了解，于是上去找了一圈，结果发现EYGLE他们系统居然前一阵又碰到了这个问题，记得上次出现问题的时候就是EYGLE发布这篇文章不久，那么他们的问题重现了，看来我碰到的也是这个问题。http://www.eygle.com/case/Job.Can.Not.Execute.Auto.htm
可是仔细一检查发现，虽然系统已经运行了445天，已经接近了出现bug的时限，但是并没有带到问题出现的时间点。难道这个bug发生的时间还会提前？
带着困惑的心情，我又仔细检查了一下JOB的运行，结果发现不是JOB停止运行了，而是JOB根本没有运行完！由于这个同步的JOB一般仅仅运行3、5分钟，因此我根本就没有想到这个JOB能运行3、4个小时而没有运行完。
看来不是发生了数据量极大的修改，就是JOB运行的进程被锁住了。查询了主库的MLOG，并没有发现多大的修改量，而且从V$LOCK中也看不到谁锁住了JOB的进程。
那么JOB到底在干什么呢？通过DBA_JOBS_RUNNING和V$SESSION_WAIT，发现JOB正在通过数据库链从远端数据库读取数据。
SQL> select sid, seq#, event from v$session_wait where sid = 178;
SID SEQ# EVENTITPUB个人空间-~-~
P,]k
---------- ---------- ----------------------------------------------------
d#t:m2u R|2AYG?0 178 18704 SQL*Net more data from dblink
数据量并不大，那么Oracle在读什么东西居然读了4个多小时还没有读完。突然想起今天下午两点左右，网络并不稳定，似乎到达机房的线路断了一小会，不会是由于这个问题引起的吧？如果是网络造成的问题，那么只需要将当前的操作断开，再次执行就应该没有问题了。杀掉JOB的进程后，重新启动JOB，果然没有问题了。
总结一下：
出了问题不要着急，有时候越着急越适得其反，一定要冷静的一步步来。
检查JOB光看ALERT文件看来是不够的，像我碰到的这种情况，JOB一直在运行，不停止也不会报错，这种情况靠检查ALERT文件是查不出来的。
因祸得福，发现了系统的bug时限又快到了，需要尽快安排操作系统的重启。另外两个解决bug的方法虽然都是一劳永逸——升级Oracle到9206或系统主板打PATCH，但是由于风险相对更大，因此暂时先不考虑了。
