exporttoexcel 刷新后保存的不是新数据_运维日记|我的数据明明就在这，为什么就是查不到？...

各位新朋友～记得先点蓝字关注我哦～

在某个午休时间，小编刚刚带上耳机准备好好休整一番，突然传来了微信语音的铃声。

Emmmmm，好吧。

摘下耳机，带上眼镜，接通电话。

客户：我有张表，里面明明有数据，但是我在收集今年11月份的报表数据的时候，sum(num)求和出来为null，其他月份都能正常执行。

小编我：对于李先生这样的情况呢，我们也感到很抱歉，建议李先生如此如此这般这般呢。

客户：？？？

哈哈哈开个玩笑，作为一个乙方运维肯定要及时尽力地为甲方爸爸排除万难了，小编马上仔细询问了具体的情况，不多时，客户发来了这么一张图片:

根据客户描述，他在对马赛克表做查询时，在monthid为201910时，对num列求和是能够正常求和的；

而在monthid为201911时，对num列求和返回值为null；

而当使用to_number去强制转换该列类型时，求和能返回数值。

另外附上该表的字段信息：

可以确定的是num列的确是个NUMBER类型字段。

听起来的确是个诡异的问题，小编我当时就去查了下在monthid分别为201910、201911时的数据行数，更诡异的事情发生了：

Monthid为201911时，返回的行数居然为0行！

小编我赶紧查了下数据：

可以看到当Monthid为201911时，表中实实在在是存在数据的！

那到底oracle到底是如何瞒天过海，“隐藏”了这些数据呢？

现在让我们直接翻到文章最后一页来看一下正确答案，大家放心，答案不会为略 。

处理过程

小编查看了这条语句的执行计划：

发现他走了一个操作叫做MAT_VIEW REWRITE ACCESS FULL。

顾名思义，就是走了物化视图查询重写来获取数据。

查询重写是指当对物化视图的基表进行查询时，Oracle会自动判断能否通过查询物化视图来得到结果，如果可以，则避免了聚集或连接操作，而直接从已经计算好的物化视图中读取数据。

小编马上对该视图以monthid=’201911’作为条件来查询：

另外，小编获取了该物化视图的ddl语句，发现该物化视图自动刷新方式用的是ON COMMIT。当主表中有数据提交的时候，立即刷新物化视图中的数据。

该自动刷新方式有以下三个特点：

⑴ 仅用于快速刷新的物化视图。

⑵ 需要on commit refresh对象权限。

⑶ 如果刷新失败需要进行手工刷新。

小编查询到该用户是存在on commit refresh对象权限的，客户也是及时提交了，随即小编在数据库日志里发现了以下片段：

说明该物化视图之前曾经刷新失败了，小编进而发现

的确存在该表上的实体化视图日志比上次刷新后的内容新的情况，按照官方文档的建议，小编在知会过客户后，对该物化视图做了完全刷新：

刷新完后，再次查询该语句：

已可以正常查询。

我们再次查询物化视图刷新时间：

知识点总结

1. 物化视图可以用于预先计算并保存表连接或聚集等耗时较多的操作的结果，这样，在执行查询时，就可以避免进行这些耗时的操作，而从快速的得到结果。

2. 查询重写是指当对物化视图的基表进行查询时，Oracle会自动判断能否通过查询物化视图来得到结果，如果可以，则避免了聚集或连接操作，而直接从已经计算好的物化视图中读取数据，从而减少读写。

3. 物化视图的更新有on demand、on commit 两种方式。on demand顾名思义，仅在该物化视图“需要”被刷新了，才进行刷新；而on commit是说，一旦基表有了commit，即事务提交，则立刻刷新。on commit的方式对业务存在一定的影响，建议使用默认的方式，及on demand方式，再设置job任务，定时去刷新物化视图。

参考文献

Master Note for Materialized View (MVIEW) (Doc ID 1353040.1)

美创运维中心数据库服务团队拥有Oracle ACE 1人、OCM 10余人、数十名Oracle OCP、MySQL OCP、红帽RHCA、中间件weblogic、tuxedo认证、达梦工程师 ，著有《Oracle DBA实战攻略》，《Oracle数据库性能优化方法和最佳实践》，《Oracle内核技术揭秘》等多本数据运维优化书籍。目前运维各类数据库合计2000余套，精通Oracle、MySQL、SQLServer、DB2、PostgreSQL、达梦等主流商业和开源数据库。并成为首批国内达梦战略合作伙伴之一，拥有海量经验和完善的人员培养体系。并同时提供超融合，私有云整体解决方案。