特殊的物化视图刷新 (r4笔记第77天)

时间:2022-05-04
本文章向大家介绍特殊的物化视图刷新 (r4笔记第77天),主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

现在有一个需求,某个环境中存在两个用户,一个用户中存在物化视图,另一个用户中存在源表,根据业务的需要,需要做一种特别的物化视图刷新。

物化视图用户中的物化视图为CORP_NAME 源数据用户中的表为ADD_CORP_NAME 可能数据刷新是没有问题,关键就是在于CORP_NAME中的字段要比ADD_CORP_NAME多一些。 CORP_NAME ADD_CORP_NAME CORP_ID | CORP_ID SYS_CREATION_DATE | SYS_CREATION_DATE SYS_UPDATE_DATE | SYS_UPDATE_DATE OPERATOR_ID | OPERATOR_ID APPLICATION_ID | APPLICATION_ID DL_SERVICE_CODE | DL_SERVICE_CODE DL_UPDATE_STAMP | DL_UPDATE_STAMP CORP_NAME | CORP_NAME FUTURE1 | FUTURE2 | FUTURE3 |

根据开发的反馈,FUTURE1,FUTURE2,FUTURE3这三个字段的值是dummy字段,只是纯粹业务需要,但是没有实际的值。根据业务的需求,这三个字段的数据类型需要为VARCHAR2(10),VARCHAR2(20),VARCHAR2(30) 明白了大体的需求,因为表数据量很小,所以没有做特别的处理,采用全表刷新。 CREATE MATERIALIZED VIEW CORP_NAME AS SELECT CORP_ID , SYS_CREATION_DATE , SYS_UPDATE_DATE , OPERATOR_ID , APPLICATION_ID , DL_SERVICE_CODE , DL_UPDATE_STAMP , CORP_NAME , ' ' FUTURE1 , ' ' FUTURE2 , ' ' FUTURE3 FROM XXXX.ADD_CORP_NAME; 但是创建好之后,查看,FUTURE1,2,3的数据类型为CHAR(1),明显和需求不符。 如果这个时候做全表刷新还可以,但是刷新就会报错,

和开发做了确认,虽然这几个字段是dummy字段,但是可能会从客户端做校验,如果是char(1)很可能会有错误。 最后在查看了一些资料后,发现可以更改物化视图的数据类型。 ALTER MATERIALIZED VIEW CORP_NAME MODIFY(FUTURE1 VARCHAR2(10)); ALTER MATERIALIZED VIEW CORP_NAME MODIFY(FUTURE2 VARCHAR2(20)); ALTER MATERIALIZED VIEW CORP_NAME MODIFY(FUTURE3 VARCHAR2(30)); 自己的固有思维中,物化视图的字段数据类型都是不能手动改变的,这种思维应该是从视图的认知中转移过来的。 从这个角度来看,这也是物化视图和普通视图的一大区别。至少对于视图来说我们如果要实现这种需求真是无能为力了。 最关键的部分就是刷新了,使用如下的语句做全表刷新没有问题,这个问题就告一段落了。 EXEC DBMS_MVIEW.REFRESH('CORP_NAME','C'); 后续的需求就是hi定期刷新,我建议他们使用scheduler来实现,毕竟使用crontab或者外部job,shell脚本也都可以,数据库层面来说还是比较方便的。 这个问题发生在昨天,虽然问题很小,但是从中可以明白对于很多东西都需要打破固有的一些思维,不能想当然的处理问题。