Oracle 物化视图和物化视图日志

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 物化视图是将查询预先定义在结构中,并手动或者定期刷新将结果存储在物化视图段中,也就是说跟普通视图不同,它是需要存储空间的,从而不需要重新或者反复的执行sql语句,支持增量刷新,快速获取结果,提高数据获取的效率。
一、相关概念
物化视图是将查询预先定义在结构中,并手动或者定期刷新将结果存储在物化视图段中,也就是说跟普通视图不同,它是需要存储空间的,从而不需要重新或者反复的执行sql语句,支持增量刷新,快速获取结果,提高数据获取的效率。
物化视图类型根据刷新模式,可分为on demand、on commit 。on demand 是需要刷新时才进行刷新,可以通过job或者手动进行刷新;on commit 是DML型的刷新,一旦事务commit立即刷新。
物化视图的刷新方式有四种:fast、complete、force、never。
--fast 刷新采用增量刷新,只刷新上次刷新以来的修改。
--complete 刷新针对整个物化视图刷新。
--force 在刷新时oracle自动选择刷新方式,满足fast就增量刷新,不满足则选择complete。
--never 不进行任何刷新

二、管理视图
在源数据库端的相关视图   
DBA_BASE_TABLE_MVIEWS   
DBA_REGISTERED_MVIEWS   
DBA_MVIEW_LOGS
在MView数据库端的相关视图    
DBA_MVIEWS    
DBA_MVIEW_REFRESH_TIMES   
DBA_REFRESH和DBA_REFRESH_CHILDREN

源端可以理解为基表所在的库,数据库端是视图存放的位置,基表和视图可以在同一个库中,也可以通过dblink创建分布式的远程的物化视图。

三、问题处理
客户环境Goldengate目标库发现有大表持续增长,表空间占用紧张。
首先根据段空间管理查看近期增长频繁的段,发现是MLOG$命名的表增长很快,MLOG$是物化视图基表上的日志表,根据上面的物化视图原理可以确定是有相关的物化视图没有进行快速刷新,因此这些日志表中的数据会一直增长下去。使用easydb可以轻松的获取资源增长情况,Easydb是袋鼠云研发,目前支持了众多云上云下的客户,有关Easydb的详情参考:https:// easydb.dtstack.com


处理步骤:
1、首先查看有多少物化视图注册到了刷新机制中
SQL> select OWNER,NAME,MVIEW_SITE,MVIEW_ID from DBA_REGISTERED_MVIEWS;
OWNER        NAME                   MVIEW_SITE            MVIEW_ID
--------------- ------------------------------ ------------------------------ ----------
SYSMAN        MGMT_ECM_MD_ALL_TBL_COLUMNS    SEEDDATA                    0
USER2   CIPMV_T_REPORT_2           USER1                      44
USER2    CIPMV_T_REPORT_1          USER1                      43
USER2    CIPMV_T_ORDER_2            USER1                     42
USER2    CIPMV_T_ORDER_1            USER1                      41
查看基表上的物化视图刷新依赖
SQL> SELECT * FROM DBA_BASE_TABLE_MVIEWS;
OWNER        MASTER                                               MVIEW_LAST_REFRESH_     MVIEW_ID
--------------- ------------------------------------------------------------------------------------------ ------------------- ----------
USER1        T_PATIENT                                           2017-09-20 20:00:12        1
USER1        T_REPORT                                           2017-09-20 20:00:47           46
USER1        T_ORDER                                            2017-09-20 20:03:02           45
USER1        T_ORDERREPORTLINK                                       2017-09-20 20:03:02           61
USER1        T_ORDER                                            2017-09-26 14:03:21           42
USER1        T_REPORT                                           2017-09-26 14:03:21           44
USER1        T_ORDER                                            2017-09-26 14:03:22           41
USER1        T_REPORT                                           2017-09-26 14:03:22           43
发现mvid是1、45、46、61四个视图没有注册到刷新中。

2、查找近期进行刷新的物化视图,确定哪些物化视图没有进行刷新,发现有几个MVID对应的物化视图是不存在的,有可能这些物化视图是远程数据库上的。
SQL> SELECT * FROM DBA_BASE_TABLE_MVIEWS;
OWNER        MASTER                                               MVIEW_LAST_REFRESH_     MVIEW_ID
--------------- --------------------------------------------------------------------------------
USER1        T_ORDER                                            2017-09-26 14:03:21           42
USER1        T_REPORT                                           2017-09-26 14:03:21           44
USER1        T_ORDER                                            2017-09-26 14:03:22           41
USER1        T_REPORT                                           2017-09-26 14:03:22           43
1、45、46、61四个视图没有刷新

3、跟客户确认环境,这个库是个灾备库,不需要这些视图刷新,此时我们把这些无效的且注册的物化视图信息去掉.
begin
DBMS_MVIEW.UNREGISTER_MVIEW('DBLINK','RIS_T_PATIENT_1', 'ORCL');
end;
/
4、根据刷新情况清空物化视图日志
EXEC DBMS_MVIEW.PURGE_MVIEW_FROM_LOG(46);
EXEC DBMS_MVIEW.PURGE_MVIEW_FROM_LOG(61);
EXEC DBMS_MVIEW.PURGE_MVIEW_FROM_LOG(1);
5、此时本地物化视图刷新后,MLOG$中的数据就会随着刷新而清空了。

6、存在的物化视图进行自动刷新
--快速刷新
begin
     dbms_mview.refresh('USER2.CIPMV_T_REPORT_2','F');
end;
/
begin
     dbms_mview.refresh('USER2.CIPMV_T_REPORT_1','F');
end;
/
begin
     dbms_mview.refresh('USER2.CIPMV_T_ORDER_2','F');
end;
/
begin
     dbms_mview.refresh('USER2.CIPMV_T_ORDER_1','F');
end;
/
--定时刷新
alter materialized view USER2.CIPMV_T_REPORT_2 refresh fast on demand start with sysdate next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 22:00:00'),'dd-mm-yyyy hh24:mi:ss');
alter materialized view USER2.CIPMV_T_REPORT_1 refresh fast on demand start with sysdate next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 22:01:00'),'dd-mm-yyyy hh24:mi:ss');
alter materialized view USER2.CIPMV_T_ORDER_2 refresh fast on demand start with sysdate next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 22:02:00'),'dd-mm-yyyy hh24:mi:ss');
alter materialized view USER2.CIPMV_T_ORDER_1 refresh fast on demand start with sysdate next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 22:03:00'),'dd-mm-yyyy hh24:mi:ss');


总结:本次问题的原因是表被多个物化视图使用,且包含远程物化视图,MLOG物化视图日志如果不被所有已注册的物化视图刷新是不会清空的,保留正常的物化视图即可。
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
2月前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的控制文件与归档日志文件
本文介绍了Oracle数据库中的控制文件和归档日志文件。控制文件记录了数据库的物理结构信息,如数据库名、数据文件和联机日志文件的位置等。为了保护数据库,通常会进行控制文件的多路复用。归档日志文件是联机重做日志文件的副本,用于记录数据库的变更历史。文章还提供了相关SQL语句,帮助查看和设置数据库的日志模式。
【赵渝强老师】Oracle的控制文件与归档日志文件
|
2月前
|
Oracle 关系型数据库 数据库
【赵渝强老师】Oracle的参数文件与告警日志文件
本文介绍了Oracle数据库的参数文件和告警日志文件。参数文件分为初始化参数文件(PFile)和服务器端参数文件(SPFile),在数据库启动时读取并分配资源。告警日志文件记录了数据库的重要活动、错误和警告信息,帮助诊断问题。文中还提供了相关视频讲解和示例代码。
|
2月前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的联机重做日志文件与数据写入过程
在Oracle数据库中,联机重做日志文件记录了数据库的变化,用于实例恢复。每个数据库有多组联机重做日志,每组建议至少有两个成员。通过SQL语句可查看日志文件信息。视频讲解和示意图进一步解释了这一过程。
|
5月前
|
SQL Oracle 关系型数据库
"揭秘!一键解锁Oracle日志清理魔法,让海量归档日志无处遁形,守护数据库健康,告别磁盘空间告急噩梦!"
【8月更文挑战第9天】随着Oracle数据库在企业应用中的普及,归档日志管理对保持数据库健康至关重要。归档日志记录所有更改,对数据恢复极为重要,但也可能迅速占用大量磁盘空间影响性能。利用Oracle提供的RMAN工具,可通过编写Shell脚本来自动清理归档日志。脚本包括设置环境变量、连接数据库、检查和删除指定时间前的日志,并记录执行情况。通过Cron作业定时运行脚本,可有效管理日志文件,确保数据库稳定运行。
136 7
|
5月前
|
SQL 监控 Oracle
Oracle数据误删不用怕,跟我来学日志挖掘
Oracle数据误删不用怕,跟我来学日志挖掘
96 0
|
存储 SQL 运维
Oracle运维笔记之创建物化视图报错ORA-08102
Oracle运维笔记之创建物化视图报错ORA-08102
|
3月前
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
230 64
|
29天前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
93 11
|
2月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
2月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。

推荐镜像

更多