问题：因为电力问题，一台Oracle 19.3 standby没有正常shutdown immediate关机。来电 后standby机器开启startup DB时发现要做media介质恢复，且archive log seq号要从 512号开始找，512号seq是几个月前一次正常关机时的archive log，alertlog如下：2021-05-17T15:23:14.172329+08:00 PR00 (PID:25418): Managed Standby Recovery starting Real Time Apply2021-05-17T15:23:14.254023+08:00Parallel Media Recovery started with 4 slaves2021-05-17T15:23:14.276650+08:00stopping change tracking PR00 (PID:25418): Media Recovery Waiting for T-1.S-512PR00 (PID:25418): Fetching gap from T-1.S-512 to T-1.S-5432021-05-17T15:23:15.134844+08:00Completed: alter database recover managed standby database using current logfile disconnect from session2021-05-17T15:25:06.572517+08:00PR00 (PID:25418): FAL: Failed to request gap sequence PR00 (PID:25418): GAP - thread 1 sequence 512-543PR00 (PID:25418): DBID 837094307 branch 1058193251PR00 (PID:25418): FAL: All defined FAL servers have been attemptedPR00 (PID:25418): -------------------------------------------------------------------------PR00 (PID:25418): Check that the CONTROL_FILE_RECORD_KEEP_TIME initializationPR00 (PID:25418): parameter is defined to a value that's sufficiently largePR00 (PID:25418): enough to maintain adequate log switch information to resolvePR00 (PID:25418): archived redo log gaps.PR00 (PID:25418): ------------------------------------------------------------------------- 分析：
为什么异常关机后要，从上一次正常shutdown时的archive log scn 开始找进行recovery 呢？
查询恢复时相关SCN值均是几个月前的时间
--数据文件头SCN select CHECKPOINT_CHANGE#,CHECKPOINT_TIME from v$datafile_header --控制文件的 select CHECKPOINT_CHANGE#,CHECKPOINT_TIME from v$datafile 查询了其它几台Oracle19.3版本 standby发现全部存在scn 不更新的问题，但是数据却是实时和主库同步的， 模拟shutdown abort，发现确实存在需要到上一次正常shutdown时的archive log scn开始找进行recovery。难道是BUG？查询MOS确实存在这样BUG： 问题发生在18.1及以上版本，备库MRP恢复时，数据文件的checkpoint scn and time没有被更新，在19.4, 18.8, 20.1版本中修复Bug 29056767 STANDBY: Datafiles Checkpoint not Updated at Standby Database when Media Recover is running This note gives a brief overview of bug 29056767. The content was last updated on: 15-OCT-2019 Click here for details of each of the sections below.Affects:Product (Component) Oracle Server (Rdbms)Range of versions believed to be affected (Not specified)Versions confirmed as being affected • 18.1.0 Platforms affected Generic (all / most platforms affected)Fixed:The fix for 29056767 is first included in • 20.1.0• 19.4.0.0.190716 (Jul 2019) Database Release Update (DB RU)• 18.8.0.0.191015 (Oct 2019) Database Release Update (DB RU)Interim patches may be available for earlier versions - click here to check.Symptoms: Related To:• Code Improvement• Recovery• Physical Standby Database / Dataguard• "_time_based_rcv_ckpt_target"DescriptionOn a Physical Standby database, media recovery not regularly updating the checkpoint scn and time stored in each datafile header. This problem only happens in oracle version 18.1 onwards. Standby media recovery is running, and it's applying successive log seq#'s,but the checkpoint scn and time stored each datafile header doesn't change. NOTE: the checkpoint in the datafile headers can be monitored by: select to_char(sysdate,'HH24:MI:SS'), file#, checkpoint_change#, to_char(checkpoint_time,'HH24:MI:SS') from v$datafile_header; A level 1 incremental backup on the standby may skip all the datafiles. Another impact of this bug is that if media recovery suddenly aborts for some other reason (eg due to a "shutdown abort" of the instance)then the next media recovery session may try to start scanning redo from much further back in time than necessary, and if that redo is unavailable, V$MANAGED_STANDBY would show MRP0 status is WAIT_FOR_GAP, alert log file will show 'FAL: Failed to request gap sequence' WorkaroundOn the standby, set: alter system set "_time_based_rcv_ckpt_target"=0; NOTE: restart media recovery for it to pick up the new parameter value.NOTE: this parameter can also be proactively set on the primary, so it is ready in case it becomes the standby in the future Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.ReferencesBug:29056767 (This link will only work for PUBLISHED bugs)Note:245840.1 Information on the sections in this article________________________________________________________________________________REFERENCESBUG:29056767 - DATAFILES CHECKPOINT NOT UPDATED AT STANDBY DATABASE WHEN MRP IS ENABLED 解决： 方法1. 在备库设置_time_based_rcv_ckpt_target参数并重启恢复进程MRP: alter system set "_time_based_rcv_ckpt_target"=0 scope=both;修改重启后，在主库使用alter system switch logfile模拟触发checkpoint发现 CHECKPOINT_CHANGE#已可以正常被更新 方法2. DB升级版本 以上，发现相关版本普遍 存在此BUG问题，希望能帮到大家~
