Oracle数据不同步的问题分析和解决思路

其实帮助很多的朋友解决过Oracle数据库数据不同步的问题，看似简单的问题分析出来的原因也是五花八门。比如：

成都创新互联公司长期为上千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为青羊企业提供专业的成都网站制作、成都做网站、外贸营销网站建设，青羊网站改版等技术服务。拥有十年丰富建站经验和众多成功案例,为您定制开发。

Oracle数据库问题的一点总结 在查看一些没有专业DBA维护的数据库的时候，会发现很多的潜在问题，有些可能无伤大雅，看起来是不规范不标准的问题，倒不会直接造成问题，而有些问题会让人后背发凉，正如同歌词里唱的，一旦错过就不再，这里说的就是数据，所以也希望大家能够在一些案例中得到启发和参考，避免在自己的系统中重演。

先啰嗦一句，尽管在Oracle命令行下敲过命令了，但是完整的命令和思路还算清晰，所以大家在平时的工作里面要打好基础，别被图形工具和高大上的工具绑架，出问题的时候，能够拿起手里的瑞士军刀才是真道理。

这次帮朋友看的问题，现象还是老三样，数据不同步，无法登陆，无法启动中的数据不同步。这类问题的愿意确实很多，可能是系统级的空间不足，或者是闪回区的空间不足，表空间不足等等。

当然简单确认问题，只是说数据同步有问题，面对各种可能性，只能让日志告诉方向了。

这是一个一主一备的环境，11gR2的版本，开启了ADG，快速查看了主库，发现业务处理是正常的，而且查看数据库日志也没有发现什么和空间相关的错误信息。所以很快主库的系统级，表空间的可能性排除了。

那么可能是备库端的空间或者逻辑空间溢出，所以登录到从库确认，发现是闪回去溢出了。

Oracle的闪回区其实有些纠结，在很多情况下，备库的闪回区没有自动回收，结果就慢慢溢出，导致了很多的严重问题，这个库就是如此，问题拖了一段时间，导致已经超出了控制文件的保留周期。

而且诡异的是似乎主备库的网络也有了一点变动，让这个问题更加雪上加霜。

面对这种情况，该如何处理呢，一种直接的方案就是删除闪回区中的冗余归档文件，或者调大闪回区，保险起见，如果空间还足够，是建议调大闪回区的，如果有些数据还没有同步过去，我们删除了之后，就很被动了。

当然我调大了闪回区之后，发现出现了新的问题，原来归档断了，比如归档的序列号是从7000-10000，如果归档好7213丢失了，那么7213后续的归档文件都无法直接应用，而如果我们更是雪上加上删除了没有应用的归档文件，就麻烦了。

所以我带着侥幸的心理对比了主库和备库的在断点时间范围的归档日志情况，发现主库上竟然有这几个归档文件，那么我就可以直接拷贝到备库端了，但是这个过程是无法触发自动应用的，因为主备库的归档日志命名格式不同。

比如主库是1_7213_8980808sa.dbf 而备库是 1_7213_20180308_89131231.dbf这种情况下，我们就需要手工应用日志了。

alter database register logfile 'xxxxx/xxx.dbf' ;

正让我窃喜的时候，我发现问题原来比我想的还要糟糕，尽管这个断点问题修复了，但是后续又发现了一系列问题，有大量的归档文件依旧丢失。

这个时候查明白归档为什么会丢失相比修复问题，修复当前问题的优先级要高得多，所以我简单评估了这个问题。

目前遗漏的归档文件有上千个，除非我写一个自动化脚本来自动拷贝，自动化应用归档日志文件，让这个脚本看起来足够强大，加上调试少说也有1个小时。

而如果做一个减法，我们直接重新搭建备库，整个过程就更加平滑了。

我根据数据量做了一个评估，保证带宽的情况下，在一个小时内应该可以搞定，所以确认好实施步骤，就开始操作了。

首先是停掉备库。

这个简单的操作，竟然备库hang住了，当然我提前看了下保护模式，这里是最大高可用模式，即可以在最大保护模式和最大性能之间来权衡，如果是最大保护模式，我就溴大了，因为这个操作会直接把主库也干掉。

因为不断的确认角色和状态，所以这些也算是心中有数，因为要重做数据，所以直接shutdown abort也是可以的。

搭建备库，用了duplicate的方式简直就是酸爽。

rman target sys/xxxx@test01auxiliary sys/xxx@test02 nocatalog

duplicate target database for standby from active database nofilenamecheck;

整个过程还算顺利，在配置主备关系的时候，我依旧适用了我的老朋友DG Broker,简单的几个命令就可以让Data Guard正常跑起来。

看了下时间，从确认要开始这么做到完成，还不到一个小时，也算是按照预期完成了任务。

后面做了一些补充的检查，把一些潜在的问题都修复了下，心里才算是踏实了一些。

这个案例看起来思路也很简单，但是实际操作的过程中，面对的是一个交易系统，更多的是考虑如果尽快修复数据，不能对已有的业务流程造成影响，或者倒霉的触发bug导致数据库故障，就得不偿失了。

而处理问题的时候，也是稳中求稳，比如如果我面对丢失归档的数据库回复，其实也可以考虑使用增量备份来恢复等方案，但是从简单清晰的思路来入手，重新搭建是最稳定，思路也是最清晰的，如果增量恢复出现问题，或者增量备份有任何问题，要承受的压力都是相当大的。

总之，快速解决了问题，你就是专家，否则，任何解释都没有用。