动将原有SQL统计运算导向到相应的物化视图，一方面大大提高了统计运算速度，另一方面又保证了对应用的透明性。在物化视图上可以创建相应的索引。
以下语句建立物化视图：
CREATEMATERIALIZED VIEW mview_ry_summary
TABLESPACEHZCZRK_DATA
PARALLEL(DEGREE1)
BUILD IMMEDIATE
REFRESH COMPLETEON DEMAND
ENABLE QUERYREWRITE
AS
SELECT JB.RYID,JB.GMSFHM,JB.XM, JB.XB, JB.CSRQ,"TO_LOB"(ZP.ZP)
FROMHZCZRK_JBXXB JB,HZCZRK_ZPXXB ZP
WHERE JB.RYID =ZP.RYID
18. 尝试不合并视图/*+no_merge*/，然后看执行计划及消耗的内存/CPU量
如果在查询中用到多个视图，而组成这些视图的SQL语句都是优化好了的，单独访问任何一个视图，性能都没有问题。如果此时不加NO_MERGE，则ORACLE会自动将若干个视图拆散，重新构造执行计划。而事实证时，重新构造的执行计划往往会比较糟糕，于是，这种情况下就可以利用NO_MERGE（按字面理解就是不把若干个视图的查询条件进行合并），避免ORACLE将视图的查询拆散。
加入后执行计划为：
----------------------------------------------------------
Plan hash value: 993606438
--------------------------------------------------------------------------------
---
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------
---
| 0 | SELECT STATEMENT | | 1 | 49 | 48728 (1)| 00:09:4
5 |
|* 1 | HASH JOIN | | 1 | 49 | 48728 (1)| 00:09:4
5 |
| 2 | TABLE ACCESS FULL|HZCZRK_JBXXB | 1 | 41 | 2 (0)| 00:00:0
1 |
| 3 | TABLE ACCESS FULL|HZCZRK_ZPXXB | 61692 | 481K| 48725 (1)| 00:09:4
5 |
--------------------------------------------------------------------------------
- ---
Predicate Information (identified byoperation id):
---------------------------------------------------
1 -access("JB"."RYID"="ZP"."RYID")
统计信息
----------------------------------------------------------
8 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
830 bytes sent via SQL*Net to client
756 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
工作当中总结出来通过上述18项的若干项优化后确实可以提高Oracle的性能，但是设置各参数的值需要根据服务器实际情况来做调整。