物化视图刷新失败导致日志表异常增大

简介: 整理自:http://blog.itpub.net/231499/viewspace-63714/今天在检查时,发现某个物化视图日志占用的空间超过150M,再检查看,该物化视图日志表的记录数有150W,由于其对应的物化视图没有会刷新一次,结合业务量分析可知:物化视图日志不能正常清除。

整理自:http://blog.itpub.net/231499/viewspace-63714/

今天在检查时,发现某个物化视图日志占用的空间超过150M,再检查看,该物化视图日志表的记录数有150W,由于其对应的物化视图没有会刷新一次,结合业务量分析可知:物化视图日志不能正常清除。

下面的解决步骤


--在源库查询物化视图对应日志条目个数
SQL> select count(1) from MLOG$_ITEM_TAG;

COUNT(1)
----------
532515

--在物化视图端刷新物化视图 
SQL> exec dbms_snapshot.refresh('item_tag');

PL/SQL procedure successfully completed

--返回源库查询物化视图对应日志条目个数,发现日志并没有被清除
SQL> select count(1) from MLOG$_ITEM_TAG;

COUNT(1)
----------
532515

--在源库查询ITEM_TAG对应的注册信息,发现有两个库的物化视图是基于ITEM_TAG建立的 
SQL> select * from USER_REGISTERED_MVIEWS where name='ITEM_TAG';

OWNER NAME MVIEW_SITE CAN_USE_LOG UPDATABLE REFRESH_METHOD MVIEW_ID VERSION QUERY_TXT
------------------------------ ------------------------------ -------------------------------------------------------------------------------- ----------- --------- -------------- --------------------------------------- -------------------------- --------------------------------------------------------------------------------
TEST ITEM_TAG SC1.SOUCHANG.COM YES YES PRIMARY KEY 54 ORACLE 8 MATERIALIZED VIEW SELECT "ITEM_TAG"."ITEM_TAG_ID" "ITEM_TAG_ID","ITEM_TAG"."ITEM_TAG_SEQ_NUMBER" "
TEST ITEM_TAG SC2TEST.SOUCHANG.COM YES YES PRIMARY KEY 86 ORACLE 8 MATERIALIZED VIEW SELECT "ITEM_TAG"."ITEM_TAG_ID" "ITEM_TAG_ID","ITEM_TAG"."ITEM_TAG_SEQ_NUMBER" "

SQL> select * from DBA_BASE_TABLE_MVIEWS where master='ITEM_TAG';

OWNER MASTER MVIEW_LAST_REFRESH_TIME MVIEW_ID
------------------------------ ------------------------------ ----------------------- ----------
SOUCHANG2 ITEM_TAG 2006-06-22 上午 08:54:0 54
SOUCHANG2 ITEM_TAG 2006-07-17 上午 10:47:5 86

/*原因找出来了,是因为其中一个库的物化视图没有刷新,所以导致物化视图日志没有被删除(物化视图日志必须在所有基于该表的物化视图都刷新后才会被删除)
遇到这种情况可以有两种解决方法:删除无法刷新的物化视图 删除无法刷新的物化视图注册信息
在本案例中,由于无法刷新物化视图的库是一个老库,已经被移除了,所以只能通过在源库删除这些物化视图的注册信息
*/
SQL> exec DBMS_MVIEW.unregister_mview('TEST','ITEM_TAG','SC1.SOUCHANG.COM');

PL/SQL procedure successfully completed

--删除的MVIEW_ID应该是不需要的MVIEW对应的ID
SQL> EXEC DBMS_MVIEW.PURGE_MVIEW_FROM_LOG(54);

PL/SQL procedure successfully completed

/*
--注意:千万不能把MVIEW_ID=86的MVIEW LOG删除了;如果删除的是MVIEW_ID=86的物化视图注册信息的话,在物化视图端刷新会报错,此时只能重建物化视图
SQL> exec dbms_snapshot.refresh('item_tag');

begin dbms_snapshot.refresh('item_tag'); end;

ORA-12034: materialized view log on "SOUCHANG2"."ITEM_TAG" younger than last refresh
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 794
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 851
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 832
ORA-06512: at line 1
*/

--此时在可刷新端刷新物化视图
SQL> exec dbms_snapshot.refresh('item_tag');

PL/SQL procedure successfully completed

--此时源库上ITEM_TAG对应的物化视图日志被清除
SQL> SELECT COUNT(1) FROM MLOG$_ITEM_TAG;

COUNT(1)
----------
0

/* 
如果废弃的物化视图端的数据库仍然可用,且有相关的数据库链接,则更简单的办法是在废弃物化视图的数据库中把物化视图删除,此时如果数据库链接可用,oracle会把源数据库端的物化视图注册信息一并删除,如:
*/
--首先在源数据库中查询名称为BRAND的物化视图注册信息
SQL> select * from DBA_REGISTERED_MVIEWS where name='BRAND';

OWNER NAME MVIEW_SITE CAN_USE_LOG UPDATABLE REFRESH_METHOD MVIEW_ID VERSION QUERY_TXT
------------------------------ ------------------------------ -------------------------------------------------------------------------------- ----------- --------- -------------- --------------------------------------- -------------------------- --------------------------------------------------------------------------------
FIREDRAKE BRAND NEI.SOUCHANG.COM YES YES PRIMARY KEY 1 ORACLE 8 MATERIALIZED VIEW SELECT "BRAND"."BRAND_ID" "BRAND_ID","BRAND"."ORGANIZATION_ID" "ORGANIZATION_ID"

SQL> select * from DBA_BASE_TABLE_MVIEWS where master='BRAND';

OWNER MASTER MVIEW_LAST_REFRESH_TIME MVIEW_ID
------------------------------ ------------------------------ ----------------------- ----------
FIREDRAKE BRAND 2006-07-17 上午 08:31:2 1

--然后在物化视图端执行:
SQL> DROP MATERIALIZED VIEW BRAND;

Materialized view dropped

--此时源数据库端BRAND对应的物化视图注册信息已经被删除了
SQL> select * from DBA_BASE_TABLE_MVIEWS where master='BRAND';

OWNER MASTER MVIEW_LAST_REFRESH_TIME MVIEW_ID
------------------------------ ------------------------------ ----------------------- ----------

SQL> select * from DBA_REGISTERED_MVIEWS where name='BRAND';

OWNER NAME MVIEW_SITE CAN_USE_LOG UPDATABLE REFRESH_METHOD MVIEW_ID VERSION QUERY_TXT
------------------------------ ------------------------------ -------------------------------------------------------------------------------- ----------- --------- -------------- --------------------------------------- -------------------------- --------------------------------------------------------------------------------

/*
当然,这种做法要符合三个前提条件
1、废弃的物化视图端数据库仍然可用
2、网络正常,在物化视图端能用dblink能访问源数据库
3、在业务上物化视图可以被删除
*/

最后,在数据库空闲的时候对物化视图日志表执行move操作,降低HWM

alter table mlog$_item_tag move;



相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
|
6月前
|
运维 监控 安全
Syslog 日志分析与异常检测技巧
系统日志蕴含设备运行关键信息,但分析提取颇具挑战。本文详解从命令行工具(如 Grep、Tail、Awk)到专业软件(如 EventLog Analyzer)的全流程日志分析技巧,助你高效挖掘 Syslog 价值,提升运维与安全响应能力。
415 4
|
9月前
|
SQL druid Oracle
【YashanDB知识库】yasdb jdbc驱动集成druid连接池,业务(java)日志中有token IDENTIFIER start异常
客户Java日志中出现异常,影响Druid的merge SQL功能(将SQL字面量替换为绑定变量以统计性能),但不影响正常业务流程。原因是Druid在merge SQL时传入null作为dbType,导致无法解析递归查询中的`start`关键字。
|
测试技术 开发工具 git
写了BUG还想跑——闲鱼异常日志问题自动追踪-定位-分发机制
为了高效地发现、定位和解决预发问题,闲鱼团队研发了一套异常日志问题自动追踪-定位-分发机制。这套机制通过自动化手段,实现了异常日志的定时扫描、精准定位和自动分发,显著降低了开发和测试的成本,提高了问题解决的效率。
562 15
写了BUG还想跑——闲鱼异常日志问题自动追踪-定位-分发机制
|
人工智能 Oracle Java
解决 Java 打印日志吞异常堆栈的问题
前几天有同学找我查一个空指针问题,Java 打印日志时,异常堆栈信息被吞了,导致定位不到出问题的地方。
307 2
日志框架log4j打印异常堆栈信息携带traceId,方便接口异常排查
日常项目运行日志,异常栈打印是不带traceId,导致排查问题查找异常栈很麻烦。
|
JSON 缓存 fastjson
一行日志引发的系统异常
本文记录了一行日志引发的系统异常以及作者解决问题的思路。
236 11
|
Java 应用服务中间件 HSF
Java应用结构规范问题之AllLoggers接口获取异常日志的Logger实例的问题如何解决
Java应用结构规范问题之AllLoggers接口获取异常日志的Logger实例的问题如何解决
132 3
|
安全 Java API
为什么捕获异常后不要使用e.printStackTrace()打印日志
为什么捕获异常后不要使用e.printStackTrace()打印日志
系统日志使用问题之如何防止在打印参数时遇到NPE(空指针异常)
系统日志使用问题之如何防止在打印参数时遇到NPE(空指针异常)
|
运维 关系型数据库 分布式数据库
PolarDB产品使用问题之表更新频繁,读取频繁,导致有很多慢日志,时间还很高,该怎么办
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
233 2