oracle10g新特性——物化视图

核心提示： 重写还是报错现在你可能已经认识到了查询重写特性是多么有用和重要，它能大大降低I/O和处理过程、返回结果更快，oracle10g新特性——物化视图(5)，还是假定以上的例子，用户执行一个下面的查询：1 SQL> Select city, sum(actual_rate)2 from h

重写还是报错

现在你可能已经认识到了查询重写特性是多么有用和重要。它能大大降低I/O和处理过程、返回结果更快。

还是假定以上的例子，用户执行一个下面的查询：

1 SQL> Select city, sum(actual_rate)
2 from hotels h, reservations r, trans t
3 where t.resv_id = r.resv_id
4 and h.hotel_id = r.hotel_id
5 group by city;
0 recursive calls
0 db block gets
6 consistent gets
0 physical reads
0 redo size
478 bytes sent via SQL*Net to client
496 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)

请注意consistent gets的值是6——一个非常低的值。这一结果是基于这个查询已经基于从3张表创建的2个视图的查询重写。不是从表查询，而是从MV查询，一次消耗了更少的如磁盘IO和CPU的资源。

但是如果查询重写失败了会怎么样呢？可能会以为几个原因失败：如果初始化参数query_rewrite_integrity被设置为TRUSTED并且MV的状态为STALE，查询就不会被重写。你可以通过设置会话的参数来模拟这一过程。

SQL> alter session set query_rewrite_enabled = false;

执行这一命令后，查询计划显示是从3张表查询数据，而不是从MV：

0 recursive calls
0 db block gets
16 consistent gets
0 physical reads
0 redo size
478 bytes sent via SQL*Net to client
496 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)

请注意consistent gets的值：从6上升到了16。在真实环境中，这一结果恐怕是无法接受的。因为多出来的资源请求可能无法获得，而你就必须自己重写这一查询了。在那样的情况下，你就必须确保查询一定能被重写。