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

沙龙晃荡 | 3月31日京东、微博拭魅战专家与你合营商量容器技巧实践！

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

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

在查看一些没有专业DBA保护的数据库的时刻，会发明很多的潜在问题，有些可能无伤大年夜雅，看起来是不规范不标准的问题，倒不会直接造盘考题，而有些问题会让人后背发凉，正如同溉ナ里唱的，一旦错过就不再，这里说的就是数据，所以也欲望大年夜家可以或许在一些案例中获得启发和参考，避免在本身的体系中重演。

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

先烦琐一句，尽管在Oracle敕令行下敲过敕令了，然则完全的敕令和思路还算清楚，所以大年夜家在日常平凡的工作琅绫擎要打好基本，别被图形对象和高大年夜上的对象绑架，出问题的时刻，可以或许拿起手里的瑞士军刀才是真事理。

此次帮同伙看的问题，现象照样老三样，数据不合步，无法上岸，无法启动中的数据不合步。这类问题的愿意确切很多，可能是体系级的空间不足，或者是闪回区的空间不足，表空间不足等等。

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

这是一个一主一备的情况，11gR2的版本，开启了ADG，快速查看了主库，发明营业处理是正常的，并且查看数据库日记也没有发明什么和空间相干的缺点信息。所以很快主库的体系级，表空间的可能性清除了。

那么可能是备库端的空间或者逻辑空间溢出，所以登录到大年夜库确认，发明是闪归去溢出了。

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

并且诡异的是似乎主备库的收集也有了一点更改，让这个问题加倍落井下石。

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

当然我调大年夜了闪回区之后，发明出现了新的问题，本来归档断了，比如归档的序列号是大年夜7000-10000，如不雅归档好7213损掉了，那么7213后续的归档文件都无法直策应用，而如不雅我们更是雪上加上删除了没有应用的归档文件，就麻烦了。

所以我带着侥幸的心理比较了主库和备库的在断点时光范围的归档日记情况，发明主库上竟然有这几个归档文件，那么我就可以直接拷贝到备库端了，然则这个过程是无法触发主动应用的，因为主备库的归档日记定名格局不合。

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

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

正让我窃喜的时刻，我发明问题本来比我想的还要糟糕，尽管这个断点问题修复了，然则后续又发清楚明了一系列问题，有大年夜量的归档文件依旧损掉。

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

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

今朝漏掉的归档文件有上千个，除非我写一个主动化脚本来主动拷贝，主动化应用归档日记文件，让这个脚本看起来足够强大年夜，加上调试少说也有1个小时。

而如不雅做一个减法，我们直接从新搭建备库，全部过程就加倍腻滑了。

我根据数据量做了一个评估，包管带宽的情况下，在一个小时内应当可以搞定，所以确认好实施步调，就开端操作了。

Oracle数据库问题的一点总结

起首是停掉落备库。

因为赓续切实其实认角色和状况，所以这些也算是心中稀有，因为要重做数据，所以直接shutdown abort也是可以的。

搭建备库，用了duplicate的方法的确就是酸爽。

duplicate target database for standby from active database nofilenamecheck;

全部过程还算顺利，在设备主备关系的时刻，我依旧实用了我的老同伙DG Broker,简单的几个敕令就可以让Data Guard正常跑起来。

看了下时光，大年夜确认要开端这么做到完成，还不到一个小时，也算是按照预期完成了义务。

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

这个案例看起来思路也很简单，然则实际操作的过程中，面对的是一个交易体系，更多的是推敲如不雅尽快修复数据，不克不及对已有的营业流程造成影响，或者不利的触发bug导致数据库故障，就得不偿掉了。

而处理问题的时刻，也是稳中求稳，比如如不雅我面对损掉归档的数据库答复，其实也可以推敲应用增量备份来恢复等筹划，然则大年夜简单清楚的思路来入手，从新搭建是最稳定，思路也是最清楚的，如不雅增量恢复竽暌箍现问题，或者增量备份有任何问题，要遭受的压力都是相昔时夜的。

总之，快速解决了问题，你就是专家，不然，任何解释都没有效。

【编辑推荐】

【义务编辑：庞桂玉 TEL：（010）68476606】

　　推荐阅读

　　申请美国高中留学你可以选择这几个院校看看

　很多用户在困扰申请美国高中留学的一些问题今天我们简单来回答下，在申请美国高中留学你会遇到的问题。　　1、选择学校类型　　2、应该学习什么和未来就业方向　　3、美国高中院校的排名情况　　4、平均SAT考试的>>>详细阅读

地址：http://www.17bianji.com/lsqh/40564.html