物化视图引起的性能问题

年初的时候发生了一次系统性能的问题，每天到固定的时间发现系统就会变得很慢，慢到一次提交需要半分钟。后来发现在系统慢的时间段oracle上有很多job在运行，正是这些在运行的Job导致数据库资源紧张，从而引发整个应用系统变满。为了让系统变快可以临时杀掉会话，方法如下：
--查询当前哪些job在运行
SELECT   SID,JOB   FROM   DBA_JOBS_RUNNING;
--查看会话详细信息
SELECT  a.sid,serial#   FROM   V$SESSION a where a.SID='xx';
--杀掉会话
ALTER   SYSTEM   KILL   SESSION   'sid,serial#';


杀掉会话是很危险的，因为任何一个job都是有作用的，所以只能作为临时处理方案。后来仔细分析发现这些job都是物化视图对应的JOB，那么问题来了，物化视图创建的时候都是指定晚上才运行的，怎么现在都跑到下午去运行了呢？原来的物化视图大概是用如下方式创建的：
create materialized view XXXX
refresh force on demand
start with to_date('17-07-2017 18:00:00', 'dd-mm-yyyy hh24:mi:ss') next sysdate+1 
as........
我们本来的目标是希望每天的18点刷新物化视图，但实际上物化视图每次执行完成之后才会更新下次物化视图任务的触发时间，也就是说第一次是18点执行，如果假设任务执行耗费1个小时，那么下次触发的时间就变成19点了(实际上真正的时间还是有分有秒的,其实就是sysdate+1的运算结果)，所以这样到最后有些任务就变成白天运行导致影响到了系统的性能。解决方法是使用指定下次触发时间时使用trunc函数。
create materialized view XXXX
refresh force on demand
start with trunc(sysdate)+18/24 next trunc(sysdate)+1+18/24 
as........


使用trunc函数每次执行完任务后以 “trunc(sysdate)+1+18/24 ”的结果来作为下次的触发时间，这样就确保每次触发都是18点。
另外，应该充分估计每个物化视图的刷新时间，从整个系统的角度来统一规划一下各个物化视图的刷新时间，不要全部集中在一起运行。