ORA-01346: LogMiner processed redo beyond specified reset log scn

最新推荐文章于 2021-04-11 21:21:10 发布

cuixie2370

最新推荐文章于 2021-04-11 21:21:10 发布

阅读量98

点赞数

先介绍一下标题中的错误是怎么发生的。因为一个BUG，ORACLE提供了一个更新数据字典的解决方案，但是需要更新后ABORT数据库并重启。不能确定ORACLE提供的方案是否靠谱，ORACLE也推荐先使用现有的备份恢复一个库出来进行测试，我这里也正好有一个物理的DATAGUARD（下面简称 DG），那就准备拿这个物理的DG开刀了。

首先介绍下环境：LINUX REDHAT AS4平台上的ORACLE 10.2.0.2，主库单节点，后面拖了一个物理的DG用来做切换，同时也拖了一个逻辑的DG用来做读写分离。先把物理的DG宕下来，然后进行一个冷备，然后把物理DG START到MOUNT状态，然后直接ACTIVE STANDBY来激活，然后把库OPEN，准备开始做ORACLE提供的测试。结果还没来得及做，逻辑DG那里已经开始报错了，错误信息如下：
Sun Sep 27 15:37:50 2009
krvxvurle: Logifle /u01/stdlog/vposdb/ArcDgl_1_2_698686462.arc registered after reset scn already processed.
Sun Sep 27 15:37:50 2009
RFS LogMiner: Registered logfile [/u01/stdlog/vposdb/ArcDgl_1_2_698686462.arc] to LogMiner session id [1]
Sun Sep 27 15:37:51 2009
RFS LogMiner: Client enabled and ready for notification
Sun Sep 27 15:37:51 2009
RFS LogMiner: Registered logfile [/u01/stdlog/vposdb/ArcDgl_1_1_698686462.arc] to LogMiner session id [1]
Sun Sep 27 15:37:52 2009
RFS LogMiner: RFS id [6480] assigned as thread [1] PING handler
Sun Sep 27 15:37:56 2009
Fatal Error: LogMiner processed beyond new branch scn.
Sun Sep 27 15:37:56 2009
krvxerpt: Errors detected in process 45, role builder.
Sun Sep 27 15:37:56 2009
krvxmrs: Leaving by exception: 1346
Sun Sep 27 15:37:56 2009
Errors in file /u01/app/oracle/admin/vposdb/bdump/vposdb_p001_25268.trc:
ORA-01346: LogMiner processed redo beyond specified reset log scn
LOGSTDBY status: ORA-01346: LogMiner processed redo beyond specified reset log scn
Sun Sep 27 15:37:57 2009
Errors in file /u01/app/oracle/admin/vposdb/bdump/vposdb_lsp0_5307.trc:
ORA-12801: error signaled in parallel query server P001
ORA-01346: LogMiner processed redo beyond specified reset log scn
Sun Sep 27 15:37:57 2009
TLCR process death detected. Shutting down TLCR
logminer process death detected, exiting logical standby

逻辑DG的APPLY进程碰到错误停了，于是手工启动APPLY进程，报错如下：
Fatal Error: LogMiner processed beyond new branch scn.
LOGSTDBY status: ORA-01346: LogMiner processed redo beyond specified reset log scn

看来麻烦来了，仔细看了看物理DG的参数，发现了问题。原先是为了主库切到物理库的时候，逻辑DG能够自动从新的主库应用日志，所以物理DG上的LOG参数设置为VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，也就是说，当这个物理DG切换为主库的时候，会把自己的在线日志传递到现在的逻辑DG。而当我激活物理DG的时候，他就把日志传到了逻辑的DG，而且逻辑DG居然也应用了一些东西，然后碰到了错误，就停在那里了。

RFS LogMiner: Registered logfile [/u01/stdlog/vposdb/ArcDgl_1_1_698686462.arc] to LogMiner session id [1]，从这行日志可以看到切换后的第一个日志已经被逻辑DG接收，而且磁盘上也确实看到了这个日志文件，同样第二个日志也传过来被接收到了。
Fatal Error: LogMiner processed beyond new branch scn，这行日志看到在对日志进行挖掘的时候，发现SCN对不上号了，因为逻辑DG在物理DG折腾的过程中是一直在同步APPLY的，当物理DG日志传过来后，逻辑DG的SCN已经跑到物理DG很前面了，所以导致SCN对不上了，然后就碰见一堆错，导致APPLY停掉。

最先想到的就是既然这个日志注册了，但肯定没有应用，那么既然ORACLE提供了注册归档日志，是否有取消注册这样的命令呢？开始翻ORACLE的官方文档，发现没有这样的命令。但是发现一个ALTER DATABASE START LOGICAL STANDBY APPLY INITAL START_SCN的命令，难到这个命令是可以直接从某个SCN开始应用日志吗？翻了翻文档，也没有很详细的解释，于是把START_SCN替换成逻辑DG的RESTART_SCN+1，然后APPLY，总是报错，此路不通。

然后想到了FLASHBACK DATABASE，既然是不小心把日志传过来了，那把整个库FLASH到物理DG切换之前，然后重新开始APPLY，应该可以解决问题。但因为我们的库FLASH DATABASE是没有打开的，这个时候只能做TABLE级别的FLASH，不能做全库级别的，此路也不通。

这个时候同事找到了一遍文档，是关于DOWN STREAM的，怎么手工更新数据字典的方式实现取消已经注册的日志。ML：394575.1，上面这么说：
Given that there is no API to unregister a proposed solution would be to delete from system.logmnr_log$

1. Stop the capture process named PREMT_CAP
2. select max(sequence#) from logmnr_log$ where session#= ;
3. delete from system.logmnr_log$ where session# = (select session#
fromsystem.logmnr_session$ where session_name = 'PREMT_CAP') and
sequence# > 3042;
commit;
4. Start PREMT_CAP

5. Manually register the archived redo logs from new Sequence 3043
alter database register or replace logical logfile
'/oradb1/wareht/strmarc1/premt_62420 2408_3043_1_0.arc' for 'PREMT_CAP';

也就是说，日志的注册是写在system.logmnr_log$里的，可以通过删除这里面的内容来达到取消注册的目的。查看这个视图，发现确实是有物理DG传过来的两个日志，于是直接把这个日志干掉。满怀期望重启APPLY，结果问题依旧。

这时想到了是否是因为物理DG传过来的日志写入了逻辑DG的STANDBY LOG，所以一APPLY他就立马挖掘这个LOG，而这个LOG的SCN比逻辑DG当前APPLY的SCN小，产生的问题。于是把STANDBY LOG重命名（这里导致了另外一个问题，回头再叙），同时把传过来的归档也重命名，然后重启APPLY，这时就应该找不到这些日志，然后就应该正确的去APPLY主库传过来的日志。后来发现也没用，那就应该是某些东西已经写到了数据库中了，于是思路重新回到数据字典中。

既然是挖掘的进程出的问题，就顺着上面的取消注册的思路，开始找挖掘进程相关的视图，最后找到了一个SYSTEM.LOGMNR_SESSION$的视图，而这个视图中有一个字段叫BRANCH_SCN，关联到上面的日志：Fatal Error: LogMiner processed beyond new branch scn，所以估计问题就是出在这里了。这里的值是物理DG切换时候的SCN值，到其他的逻辑DG上查询这个值，发现其他的逻辑DG的值都是0。

于是直接把这个字段UPDATE成0，然后START APPLY，居然就过去了，问题也消失了。

后续：
之前把STANDBY LOG重命名了，然后重启APPLY前，已经把他们的名字又改了回来，所以认为万事大吉了。结果今天发现逻辑DG时不时的会有APPLY延迟，而且主库也时不时的出现在线日志传不到逻辑DG的情况，查询v$logstdby_process视图，发现它总是在等待生产上还没有产生的归档日志，这应该是传归档的时候才会有的问题，传在线日志是没这样的问题的。

找来找去，最后发现STANDBY LOG不知道啥时候变成只有一组了，所以切一次日志，STDLOG能够正常被使用，然后在线日志传的过来；再切一次日志，因为没有在线的STDLOG可用，导致只能等待并应用归档，所以就时不时的产生延迟。

原因找到，解决很简单，直接添加STANDBY LOG上去，问题得到解决。
<!-- comment these out if you want to see an example of custom fields, but remember to name the fields in the same way they are named here: 'imfeeling' (livejournal.com style), 'listening' and 'new_field'

: ?