物化视图是一种特殊的物理表，“物化”(materialized)视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性大，任何对视图的查询，oracle都实际上转换为视图sql语句的查询。这样对整体查询性能的提高，并没有实质上的好处。
oracle最早在olap中 引入了物化视图的概念。但后来很多大型oltp系统中，发现类似统计的查询是无可避免，而这些查询操作如果很频繁，对整体性能是很致命的。于是 oracle开始不断的改进物化视图，使得其也开始合适oltp系统。从oracle 8i到现在，功能已经相对比较完备了。
本文是oracle物化视图系列文章的第一篇，有两个主要目的，来体验一下创建on demand和on commit物化视图的方法。on demand和on commit物化视图的区别在于其刷新方法的不同，on demand顾名思义，仅在该物化视图“需要”被刷新了，才进行刷新(refresh)，即更新物化视图，以保证和基表数据的一致性;而on commit是说，一旦基表有了commit，即事务提交，则立刻刷新，立刻更新物化视图，使得数据和基表一致。
1、第一个on demand物化视图
1.1、创建on demand物化视图
下面创建一个最简单的物化视图，这个物化视图的定义很类似于普通视图的创建语句，只是多了一个materialized，但就是这个单词，造成了物化视图和普通视图(虚拟表)的天壤之别，也引申出后面很多的事情，呵呵。
本例中需要特别注意的是，oracle给物化视图的重要定义参数的默认值处理，在下面的例子中会有特别说明。因为物化视图的创建本身是很复杂和 需要优化参数设置的，特别是针对大型生产数据库系统而言。但oracle允许以这种最简单的，类似于普通视图的办法来做，所以不可避免的会涉及到默认值问 题。
像我们这样，创建物化视图时未作指定，则oracle按on demand模式来创建。
从下例中可以看出：
1) 物化视图在某种意义上说就是一个物理表(而且不仅仅是一个物理表)，这通过其可以被user_tables查询出来，而得到佐证;
2) 物化视图也是一种段(segment)，所以其有自己的物理存储属性;
3) 物化视图会占用数据库磁盘空间，这点从user_segment的查询结果，可以得到佐证。
● 创建物化视图
–获取数据库rdbms版本信息
sql>select*fromv$version;
banner
——————————————————————————–
oracledatabase11genterpriseeditionrelease11.1.0.6.0-production
pl/sqlrelease11.1.0.6.0-production
core11.1.0.6.0production
tnsfor32-bitwindows:version11.1.0.6.0-production
nlsrtlversion11.1.0.6.0–production
–创建物化视图
sql>creatematerializedviewmv_testcf
2as
3select*fromxiaotg.testcf;
materializedviewcreated
–分析物化视图，以获得统计信息
sql>analyzetablexiaotg.mv_testcfcomputestatistics;
tableanalyzed
–查看物化视图的行数，发现和master表(testcf)一样
sql>selecttl.table_name,tl.num_rowsfromuser_tablestlwheretl.table_namein(‘testcf’,’mv_testcf’);
table_namenum_rows
—————————————-
mv_testcf80000
testcf80000
–查看物化视图的存储参数
sql>colsegment_namefora24
sql>selectsg.segment_name,sg.bytes,sg.blocksfromuser_segmentssgwheresg.segment_name=’mv_testcf’;
segment_namebytesblocks
——————————————–
mv_testcf94371841152
● 查看物化视图关键定义
–查看物化视图的定义设置，请关注蓝色字体部分。
–这表明，默认情况下，如果没指定刷新方法和刷新模式，则oracle默认为force和demand。
–其他的集中刷新方法和刷新模式以后将分别予以介绍。
sql> select mv.* from user_mviews mv where mv.mview_name = ‘mv_testcf’;
(为增加查询结果的可读性，下面进行了行列的互转)
ownerxiaotg
mview_namemv_testcf
container_namemv_testcf
query
query_len80
updatablen
update_log
master_rollback_seg
master_link
rewrite_enabledn
rewrite_capabilitygeneral
refresh_modedemand
refresh_methodforce
build_modeimmediate
fast_refreshabledml
last_refresh_typecomplete
last_refresh_date2008-9-915:02
stalenessfresh
after_fast_refreshfresh
unknown_prebuiltn
unknown_plsql_funcn
unknown_external_tablen
unknown_consider_freshn
unknown_importn
unknown_trusted_fdn
compile_statevalid
use_no_indexn
stale_since
num_pct_tables0
num_fresh_pct_regions
num_stale_pct_regions
1.2、测试on demand物化视图的更新特性
物化视图最重要的功能和特性之一，就是其数据会随着基表(或称主表，master表，本例中为testcf)的变化而变，基表数据增了，物化视图数据会变多;基表数据删了，物化视图数据也会变少。
但怎么更新或者说物化视图的数据怎么随着基表而更新oracle提供了两种方式，手工刷新和自动刷新，像我们这种，在物化视图定义时，未作 任何指定，那当然是默认的手工刷新了。也就是说，通过我们手工的执行某个oracle提供的系统级存储过程或包，来保证物化视图与基表数据一致性。
这是最基本的刷新办法了。但所谓的自动刷新，其实也就是oracle会建立一个job，通过这个job来调用相同的存储过程或包，加以实现，这在本系列文章的第2篇会将以详细阐述。
下面将测试insert，update和delete的测试方法类似，大家有兴趣的话，可以自己试一试。
需要注意的是，下面暂不讨论如何刷新on demand物化视图，这是下一篇文章的内容。下面仅仅关注on demand物化视图的特性及其和on commit物化视图的区别，即前者不刷新(手工或自动)就不更新物化视图，而后者不刷新也会更新物化视图，——只要基表发生了commit。
● 在基表插入测试数据
基表数据插入后，会发现，物化视图并不会随之更新。
–检查基表和物化视图是否有80001这一行记录。
sql>colidfora10;
sql>colnamefora30;
sql>select*fromxiaotg.testcftwheret.id=80001;
idname
—————————————-
sql>select*fromxiaotg.mv_testcftwheret.id=80001;
idname
—————————————-
–插入测试数据80001
–这时发现，基表有数据，但物化视图并没有
sql>insertintoxiaotg.testcf
2values(80001,’xiaotghehe’);
1rowinserted
sql>commit;
commitcomplete
1.2.2 测试物化视图数据是否更新
从下面的实验可以看出，物化视图数据不会更新，即使等上1分钟、1小时、或者1天。
关于如何使得on demand物化视图数据被更新，参加本系列的第二篇文章哈：)
sql>select*fromxiaotg.testcftwheret.id=80001;
idname
—————————————-
80001xiaotghehe
sql>select*fromxiaotg.mv_testcftwheret.id=80001;
idname
—————————————-
sql>
2、第一个on commit物化视图
最简单的on commit物化视图的创建，和上面创建on demand的物化视图区别不大。因为on demand是默认的，所以on commit物化视图，需要再增加个参数即可。
2.1 创建on commit物化视图
● 创建物化视图
需要注意的是，无法在定义时仅指定on commit，还得附带个参数才行，本例中附带refresh force，关于这个参数的意思，以后将加以阐述。
–创建on commit物化视图
sql>creatematerializedviewmv_testcf2
2refreshforceoncommit
3as
4select*fromxiaotg.testcf;
materializedviewcreated
sql>
–分析物化视图和基表
sql>analyzetablexiaotg.mv_testcf2computestatistics;
tableanalyzed
sql>analyzetablexiaotg.testcfcomputestatistics;
tableanalyzed
–查看当前基表和物化视图的行数
sql>selecttl.table_name,tl.num_rowsfromuser_tablestlwheretl.table_namein(‘testcf’,’mv_testcf2′);
table_namenum_rows
—————————————-
mv_testcf280000
testcf80000
● 查看物化视图关键定义
可以从dba_mviews中看出，刷新模式为commit，这也是它和上面on demand物化视图的唯一区别。
sql>selectmv.*fromuser_mviewsmvwheremv.mview_name=’mv_testcf’;
(为增加查询结果的可读性，下面进行了行列的互转，且只显示前三个关键列的)
refresh_modecommit
refresh_methodforce
build_modeimmediate
2.2 测试on commit物化视图的更新特性
on commit物化视图会在基表一旦提交时，就会立刻更新物化视图本身，而且一般仅在物化视图数据也被更新后，基表数据才会事实的提交。
这意味着，这种模式可能会导致延迟基表数据的提交。。这点在下面的实验中体现得很清楚。
实验中，对基表testcf，平常的commit在0.01秒内可以完成，但在有了on commit视图mv_testcf2后，居然要6秒。速度减低了很多倍。on commit视图对基表的影响可见一斑。
● 在基表中插入数据
sql>settimingon;
sql>insertintoxiaotg.testcf(id,name)values(80002,’xiaotgagainhehe’);
1rowinserted
executedin0.015seconds
sql>commit;
commitcomplete
executedin6.985seconds
sql>select*fromxiaotg.testcfwhereid=80002;
idname
—————————————————————————————————————–
80002xiaotgagainhehe
executedin0seconds
sql>colidfora10;
sql>colnamefora40;
sql>select*fromxiaotg.testcfwhereid=80002;
idname
————————————————–
80002xiaotgagainhehe
executedin0.016seconds
sql>select*fromxiaotg.mv_testcf2whereid=80002;
idname
————————————————–
80002xiaotgagainhehe
executedin0.031seconds
● 测试基表正常情况下的commit速度
sql>dropmaterializedviewmv_testcf2;
materializedviewdropped
executedin1.984seconds
sql>
sql>
sql>insertintoxiaotg.testcf(id,name)values(80003,’xiaotgagainhehe3′);
1rowinserted
executedin0seconds
sql>commit;
commitcomplete
executedin0seconds