DW: Some useful system views when checking Materialized View

本文探讨了Oracle中物化视图(mv)的刷新机制及mv日志的使用方式。介绍了dba_mview_refresh_times视图的作用,mvlog的命名规则及内部触发器的工作原理。同时讲解了创建mvlog时如何指定过滤列,并说明了这些机制在Oracle 11i等版本中的应用。

1. dba_mview_refresh_times/user_mview_refresh_times

This view lists the master table, mv and the last refresh time. When mv are fast refresh mv, the mv log will be purged only when all the mvs are refreshed and those logs are no longer useful.

 

2. mv log naming format

The materialized view log actually is a table , we can find it in sys.obj$, the name format is MLOG$_<TABLE_NAME> , this name can be found in user_snapshot_logs view. in this table, dmltype is recorded as U, I and D. it also has a snapshot timestamp, I believe Oracle refreshes mv by comparing the last_refresh time with the sanpshot timestamp in this log, it picks rows with snapshot timestamp later then the last refresh time. 

 

3. mv log and internal trigger

oracle captures changes in the table by internal trigger, unforutnately, I'm not able to find the trigger and it's source. The only information I can find is DBA_INTERNAL_TRIGGERS view. according to the view source ,the trigflag in sys.tab$ table reveals the type of such trigger.

 

4. filter column when create mv log.

create table mytest (a number, b number,c number);

When we create mv log

CREATE MATERIALIZED VIEW LOG ON mytest
PCTFREE 0
PCTUSED 99
WITH ROWID(A,B);

 

Here we use ROWID(A,B), in the mv log MLOG$_MYTEST, we can see the A, B columns are included. This meaningful columns is useful in system like Oracle 11i in which most tables has no primary key but unique key.

 

 


 

在 Quartz 调度框架中,如果出现 `JobPersistenceException: Failure updating scheduler state when checking-in` 错误,并且日志中提示 MySQL 服务器处于只读模式,这通常意味着 Quartz 无法对数据库执行写操作,从而导致调度状态无法更新。 Quartz 在集群模式下运行时,多个调度实例共享同一个数据库,每个实例会定期“检查”(check-in)以更新其状态和维护租约[^1]。这一过程涉及对数据库的写操作,例如更新 `QRTZ_SCHEDULER_STATE` 表中的调度器状态记录。如果数据库处于只读模式,则这些更新操作将失败,并抛出 `JobPersistenceException` 异常。 此类问题的典型表现包括: - Quartz 实例无法正常注册到集群中。 - 调度器状态无法更新,导致其他节点无法识别当前节点的状态。 - 日志中频繁出现 `Failure updating scheduler state` 错误信息。 ### 解决方案 #### 1. 检查 MySQL 实例是否为只读模式 MySQL 的只读模式可以通过以下方式设置: - **全局只读**:通过 `read_only=1` 配置项设置,适用于所有非特权用户。 - **会话只读**:通过 `SET SESSION read_only=1` 设置,仅影响当前会话。 可以通过以下 SQL 查询确认当前数据库是否为只读模式: ```sql SHOW VARIABLES LIKE 'read_only'; ``` 如果返回值为 `ON`,则表示数据库处于只读模式。要临时关闭只读模式,可以执行: ```sql SET GLOBAL read_only=0; ``` 注意:该操作需要具有 `SUPER` 权限。 #### 2. 检查用户权限 即使数据库不是全局只读,也需确认 Quartz 使用的数据库用户是否具有足够的权限来执行写操作。确保该用户拥有对 Quartz 所需的表结构(如 `QRTZ_SCHEDULER_STATE`、`QRTZ_FIRED_TRIGGERS` 等)的 `UPDATE`、`INSERT` 和 `DELETE` 权限[^2]。 #### 3. 检查数据库连接池配置 某些连接池(如 HikariCP、C3P0)可能配置了连接为只读模式,或者在获取连接时设置了只读标志。检查 Quartz 使用的连接池配置,确保没有启用只读连接。 例如,在 Spring 配置文件中检查类似如下配置: ```xml <property name="connectionInitSqls"> <list> <value>SET SESSION read_only=0</value> </list> </property> ``` #### 4. 检查数据库主从复制配置 如果使用了主从复制架构,确保 Quartz 的写操作指向主库,而不是只读的从库。可以在数据源配置中明确指定主库地址,或使用负载均衡策略将写操作路由到主节点。 #### 5. 检查 Quartz 配置 确保 Quartz 的配置文件中没有启用模拟只读模式或其他限制写操作的参数。例如: ```properties org.quartz.jobStore.isClustered = true org.quartz.scheduler.instanceName = ClusterQuartzScheduler org.quartz.threadPool.threadCount = 10 ``` 确保 `JobStoreTX` 或 `JobStoreCMT` 配置正确,并且未设置只读事务模式。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值