物化视图异常诊断

OceanBase 数据库的物化视图（Materialized View, MV）可能因增量刷新延迟或卡顿导致数据与基表不同步。

本文档提供诊断流程和关键系统视图，帮助快速定位和解决异常。

异常场景与监控指标

异常场景

物化视图的增量刷新可能因以下原因变慢或卡住：

• 数据量突增：基表更新量远超预期。
• 刷新任务阻塞：SQL 执行性能问题或资源竞争。
• 调度任务失败：如 DBMS_SCHEDULER 调度异常。

关键监控指标

通过系统视图 DBA_MVIEWS 的以下字段监控 MV 数据状态：

• data_sync_delay：物化视图的数据同步延迟，单位秒。

  触发报警条件：当 data_sync_delay 超过业务设定的阈值时，需立即诊断。

• data_sync_scn：物化视图的数据位点。

  说明

  对于 OceanBase 数据库 V4.3.5 版本，系统视图 DBA_MVIEWS 从 V4.3.5 BP2 版本开始引入 data_sync_delay 和 data_sync_scn 字段。

物化视图相关系统视图

物化视图异常诊断流程

流程 1：判断报警的 MV 是否为嵌套物化视图

• 如果是嵌套物化视图，沿着依赖关系找到出现问题的最底层的 MV，将其作为目标 MV。然后跳转至流程 2。

• 如果不是嵌套物化视图，该 MV 即为目标 MV。然后跳转至流程 2。

示例查询：

SELECT * FROM oceanbase.DBA_MVIEW_DEPS;

流程 2：检查当前是否存在目标 MV 的刷新任务

1. 查询运行中任务。

   示例查询：

   查找指定 MV 的运行任务。

   SELECT * FROM oceanbase.DBA_MVIEW_RUNNING_JOBS
   WHERE table_name LIKE '%MVIEW%';
   

2. 判断状态：

   • 如果存在刷新任务，说明此次 MV 刷新耗时过长，迟迟没有完成，导致 data_sync_scn 未能及时更新，需要确定具体原因。然后跳转至流程 4。

   • 如果不存在刷新任务，可能遇到了程序 BUG。然后跳转至流程 3。

流程 3：调度任务故障排查

若 DBMS_SCHEDULER 调度失败（如连续 16 次失败后任务被注销）：

1. 查看调度历史，确认问题。

   示例查询：

   SELECT * FROM oceanbase.DBA_SCHEDULER_JOBS;
   

   可以查询 DBA_SCHEDULER_JOB_RUN_DETAILS 中是否有 16 次 5019 的失败记录，参考语句如下：

   SELECT OWNER, JOB_NAME, count(*) > 16 FROM oceanbase.DBA_SCHEDULER_JOB_RUN_DETAILS WHERE CODE = '-5019';
   

2. 升级版本：若问题由已知 Bug 引起，升级到最新版本修复。

流程 4：判断基表是否发生了超出历史平均水平的更新操作

1. 如果修改数据量增长过多，刷新时间也会相应变长，此时 MV 数据落后可能就是符合预期的。如果据量增长是业务偶尔的抖动，可以适当推高 data_sync_delay 的阈值，避免误报警。如果修改量会继续增长，则需要通过调整物化视图刷新周期、调大物化视图刷新并行度、增加机器资源等方案来解决问题。

2. 如果修改数据量没有明显增长，刷新耗时增加不符合预期：

   1. 如果此次刷新操作结束了，或者之前的刷新任务有相似的行为，可以查询 DBA_MVREF_STATS 等视图分析已结束任务的信息。然后跳转至流程 5。
   2. 如果视图无法提供信息，可以联系技术支持进一步排查。然后跳转至流程 6。

流程 5：实时卡顿任务诊断

1. 查询刷新耗时异常的物化视图最近几次的刷新情况总览。

   SELECT * 
   FROM oceanbase.DBA_MVREF_RUN_STATS run_stats, oceanbase.DBA_MVREF_STATS stats
   WHERE run_stats.refresh_id = stats.refresh_id
   AND run_stats.MVIEWS LIKE '%mv1%'
   ORDER BY run_stats.start_time DESC
   LIMIT 10;
   

   重点关注以下几个信息：

   字段	含义	说明
   REFRESH_ID	此次刷新操作的标识。
   ELAPSED_TIME	此次刷新操作的总耗时，单位秒。
   REFRESH_METHOD	刷新方式。	检查刷新方法是否正确，是否误用了全量刷新。
   PARALLELISM	刷新并行度。	检查并行度是否太小。
   LOG_PURGE_TIME	此次刷新中，花在清理 MLOG 的时间。	检查是否花了大量时间在 Purge 上。
   INITIAL_NUM_ROWS	此物化视图刷新前的行数。
   FINAL_NUM_ROWS	此物化视图刷新后的行数。	检查前后行数变化是否过大。

2. 从上述结果中找到异常刷新操作的 REFRESH_ID，进一步查看其刷新细节。

   SELECT *
   FROM oceanbase.DBA_MVREF_CHANGE_STATS
   WHERE refresh_id = xxx;
   

   查询 oceanbase.DBA_MVREF_CHANGE_STATS 这个视图是为了确认基表的数据变化情况，如果新插入、更新、删除的行数相较于以往的水位有增加，那刷新时间变长就是符合预期的。查询物化视图相关基表的数据变化情况，重点关注以下几个信息：

   字段	含义
   REFRESH_ID	此次刷新操作的标识。
   TBL_NAME	基表表名。
   NUM_ROWS_INS	基表自上一次刷新以来新插入的行数。
   NUM_ROWS_UPD	基表自上一次刷新以来修改的行数。
   NUM_ROWS_DEL	基表自上一次刷新以来删除的行数。
   NUM_ROWS	基表在此次刷新时的总行数。

解决方案与优化建议

• 数据量激增场景：

  • 提升刷新并行度。
  • 切分大基表或优化 MV 架构。

• SQL 性能问题：

  • 优化基表索引或 MV 的查询语句。
  • 使用分区表加速增量数据处理。

• 资源不足：

  增加服务器资源（CPU、内存）或调整任务调度时间窗口。

相关文档

更多关于刷新物化视图的信息，参见 刷新物化视图（MySQL 模式） 或 刷新物化视图（Oracle 模式）。