oracle 物化视图使用,ORACLE 物化视图使用

当前位置:我的异常网» 数据库 » ORACLE 物化视图使用

ORACLE 物化视图使用

www.myexceptions.net  网友分享于：2013-08-18  浏览：20次

ORACLE 物化视图应用

物化视图是一种特殊的物理表，“物化”(Materialized)视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性大，任何对视图的查询，Oracle都实际上转换为视图SQL语句的查询。这样对整体查询性能的提高，并没有实质上的好处。

1、物化视图的类型：ON DEMAND、ON COMMIT

二者的区别在于刷新方法的不同，ON DEMAND顾名思义，仅在该物化视图“需要”被刷新了，才进行刷新(REFRESH)，即更新物化视图，以保证和基表数据的一致性；而ON COMMIT是说，一旦基表有了COMMIT，即事务提交，则立刻刷新，立刻更新物化视图，使得数据和基表一致。

2、ON DEMAND物化视图

物化视图的创建本身是很复杂和需要优化参数设置的，特别是针对大型生产数据库系统而言。但Oracle允许以这种最简单的，类似于普通视图的方式来做，所以不可避免的会涉及到默认值问题。也就是说Oracle给物化视图的重要定义参数的默认值处理是我们需要特别注意的。

物化视图的特点：

(1) 物化视图在某种意义上说就是一个物理表(而且不仅仅是一个物理表)，这通过其可以被user_tables查询出来，而得到佐证；(2) 物化视图也是一种段(segment)，所以其有自己的物理存储属性；(3) 物化视图会占用数据库磁盘空间，这点从user_segment的查询结果，可以得到佐证；

创建语句：create materialized view mv_name as select * from table_name

默认情况下，如果没指定刷新方法和刷新模式，则Oracle默认为FORCE和DEMAND。

物化视图的数据怎么随着基表而更新？

Oracle提供了两种方式，手工刷新和自动刷新，默认为手工刷新。也就是说，通过我们手工的执行某个Oracle提供的系统级存储过程或包，来保证物化视图与基表数据一致性。这是最基本的刷新办法了。自动刷新，其实也就是Oracle会建立一个job，通过这个job来调用相同的存储过程或包，加以实现。

ON DEMAND物化视图的特性及其和ON COMMIT物化视图的区别，即前者不刷新(手工或自动)就不更新物化视图，而后者不刷新也会更新物化视图，——只要基表发生了COMMIT。

3、ON COMMIT物化视图

ON COMMIT物化视图的创建，和上面创建ON DEMAND的物化视图区别不大。因为ON DEMAND是默认的，所以ON COMMIT物化视图，需要再增加个参数即可。

需要注意的是，无法在定义时仅指定ON COMMIT，还得附带个参数才行。

创建ON COMMIT物化视图：create materialized view mv_name refresh force on commit as select * from table_name

备注：实际创建过程中，基表需要有主键约束，否则会报错(ORA-12014

优点：

1，物化视图的最大的优势是可以提高性能：Oracle的物化视图提供了强大的功能，可以用于预先计算并保存表连接或聚集等耗时较多的操作的结果，这样，在执行查询时，就可以避免进行这些耗时的操作，而从快速的得到结果。

2， 物化视图有很多方面和索引很相似

3，通过预先计算好答案存储起来，可以大大地减少机器的负载

A，更少的物理读--扫描更少的数据

B，更少的写--不用经常排序和聚集

C。减少CPU的消耗--不用对数据进行聚集计算和函数调用

D，显著地加快响应时间--在使用物化视图查询数据时(与主表相反)，将会很快的返回查询结果

缺点：

1，物化视图用于只读或者“精读”环境下工作最好 ，不用于联机事务处理系统(OLTP)环境，　在事实表等更新时会导致物化视图行锁，从而影响系统并发性。

2，物化视图有出现无法快速刷新，导致查询数据不准确的现象

3，Rowid物化视图(创建的物化视图通常情况下有主键，rowid,和子查询视图)只有一个单一的主表，不能包括下面任何一项:

A，Distinct 或者聚合函数.

B，Group by，子查询，连接和SET操作

4，物化视图会增加对磁盘资源的需求，即需要永久分配的硬盘空间给物化视图来存储数据

5，物化视图的工作原理受一些可能的约束，比如主键，外键等等

实验：

1，创建物化视图：

/* Formatted on 2010-7-1 10:46:08 (QP5 v5.115.810.9015) */

CREATE MATERIALIZED VIEW Contract REFRESH FORCE ON DEMAND AS SELECT "Contract_ID","Contract_ProjectID","Contract_TableID","Contract_NO" FROM "Comm_Contract" WHERE "Contract_TableID"

IN(SELECT "AppTab_ID" FROM "Base_AppTableInfo" WHERE "AppTab_TableCode"='SaleContractP_Base' )

2，查询

----从基表中查询：

SELECT    "Contract_ID"

FROM   "Comm_Contract"

WHERE   "Contract_NO" LIKE '%2009011%'

A，单用户查询响应时间：206ms

B，50并发查询响应时间：1670ms

-----从物化视图查询：

select "Contract_ID"

from "Contract"

where "Contract_NO" like '%2009011%'

A，单用户查询响应时间：23ms

B，50并发查询响应时间：48ms

总结：目前项目中的应用目的，主要原表字段越来越多，随着数据量增长，查询效率，并发效率降低，从表提取主要几个字段建成物化视图，应用在关联查询，子查询，查询性能和并发性能都有显著提升，问题：貌似不能建跨表物化视图，类似一般视图一样的效果，几年前做的实验，有兴趣同学可以实验一下物化视图限制

文章评论