其实帮助很多朋友解决了Oracle数据库数据不同步的问题，看似简单的问题原因也是五花八门。例如：Oracle数据库问题总结。在查看一些不是由专业DBA维护的数据库时，你会发现很多潜在的问题。这个问题会让人感到不寒而栗。就像歌词说的，一旦错过就停不下来。我这里说的是数据，希望大家能从一些案例中得到启发和借鉴，避免在自己的系统中重蹈覆辙。让我从一个长词开始。虽然我在Oracle命令行敲过命令，但是完整的命令和思路还是很清楚的，所以大家在平时的工作中还是要打好基础，不要被图形化工具和高端工具绑架，出问题。到时候，能把瑞士军刀拿在手里就是这个道理。这次帮朋友看问题，现象还是和老三一样，数据不同步，无法登录，无法启动数据不同步。对于这种问题确实有很多意愿，可能是系统层面的空间不足，或者是闪回区空间不足，表空间不足等等。当然，单纯的确认问题只是说数据同步有问题。面对各种可能，只能让日志指明方向。这是一主一备的环境。11gR2版本开启了ADG，快速查看主库发现业务处理正常，数据库日志中也没有发现与空间相关的错误信息。所以很快主库的系统级别，表空间的可能性就被排除了。那么可能是备库上的空间或者逻辑空间溢出了，于是登录从库确认，发现是闪回溢出了。Oracle的闪回区其实有点纠结。很多时候备库的闪回区没有自动回收，结果慢慢溢出，造成很多严重的问题。这个库就是这种情况。问题拖了一段时间，导致已经超过了控制文件的保留期限。而且奇怪的是，主备数据库的网络好像也发生了一点变化，这让这个问题更加严重了。面对这种情况，该如何应对？直接的解决办法是删除闪回区中多余的归档文件，或者增大闪回区的大小。为了保险起见，如果空间足够的话，建议增加闪回区的大小是的，如果有些数据还没有同步，我们删除之后，会很被动。当然，我把闪退区扩大后，又发现了新的问题。原始存档已损坏。例如，存档的序列号是从7000-10000。如果7213存档丢失了，那么7213后续的存档文件就不能直接套用了，如果我们在上面添加并删除未应用的存档文件，那将很麻烦。于是我抱着侥幸的心态对比了断点时间范围内的主库和备库的归档日志，发现主库上有这些归档文件，直接copy到备库，但是这个过程不能触发自动申请，因为主备数据库的归档日志命名格式不同。例如主库为1_7213_8980808sa.dbf，备库为1_7213_20180308_89131231.dbf，我们需要手动申请日志。alterdatabaseregisterlogfile'xxxxx/xxx.dbf';正当我暗喜的时候，我发现问题比我想象的还要严重。虽然修复了断点问题，但后来发现了一系列问题，包括大量存档文件仍然丢失。这个时候找出存档丢失的原因比修复问题优先级高很多，所以我简单的评估了一下这个问题。目前少了好几千个归档文件，除非我写一个自动化脚本自动复制并自动套用归档日志文件，这样这个脚本看起来足够强大，调试起来至少要1个小时。而如果做减法，直接重建备库，整个过程会更顺畅。我根据数据量做了一个评估。如果带宽有保证的话，一个小时内应该就可以搞定了，于是在确认了实施步骤后，我就开始操作了。首先是停止备用数据库。这个简单的操作居然导致备份数据库挂掉了。当然，我提前看了一下保护模式。这里是最大高可用模式，也就是你可以在最大保护模式和最大性能之间进行权衡。如果是最大保护模式，我会溴太大，因为这个操作会直接杀掉主库。因为不断确认角色和状态，这些也算是心知肚明，因为数据需要重做，所以直接shutdownabort也是可以的。建立备份数据库，使用duplicate的方式简直酸溜溜的。rmantargetsys/xxxx@test01auxiliarysys/xxx@test02nocatalogduplicatetargetdatabaseforstandbyfromactivedatabasenofilenamecheck;整个过程很顺利，在配置主备关系的时候，我还是用了我的老朋友DGBroker，几个简单的One命令就可以让DataGuard正常运行。看时间，从确认开始到完成，只用了不到一个小时，任务按预期完成。做了一些补充检查，修复了一些潜在问题后，心里踏实多了。本案例看似思路简单，但在实际运行过程中，面对的是一个事务系统，更多的是考虑如果尽快修复数据，不能影响现有的业务流程，或者倒霉的triggerbug导致如果数据库出现故障，得不偿失。处理问题的时候，也是求稳的问题。比如我面对丢失和归档的数据库恢复，其实可以考虑使用增量备份恢复等方案，但是从一个简单明了的思路开始，重建是最稳定的，思路也是最清晰的。如果增量恢复出现问题，或者增量备份出现问题，承受的压力是相当大的。总之，快点解决问题，你就是专家，否则再解释也没用。
