oracle10g新特性——物化视图

核心提示： 在Oracle 9i和以下版本中，可能只有一个方法实现：使查询重写失效而不是使基础表的访问失败，oracle10g新特性——物化视图(6)，在10g中通过一个特殊的提示可以提供这样的机制：REWRITE_OR_ERROR，上面这个查询就可以这样写了：1 SQL> select /*+

在Oracle 9i和以下版本中，可能只有一个方法实现：使查询重写失效而不是使基础表的访问失败。在10g中通过一个特殊的提示可以提供这样的机制：REWRITE_OR_ERROR。上面这个查询就可以这样写了：

1 SQL> select /*+ REWRITE_OR_ERROR */ 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;
from hotels h, reservations r, trans t
*
ERROR at line 2:
ORA-30393: a query block in the statement did not rewrite

这样就会产生一个ora-30393的错误信息。这个信息表示查询不能通过使用MV来重写，因此语句失败。这一错误保护可以防止查询长期运行后系统发生资源缺乏问题。但是还要注意一个潜在问题：如果一个查询成功了，而不是所有都成功了，这些MV就能被用于查询的重写。因此，如果MV_ACTUAL_SALES而不是MV_HOTL_RESV能被使用，查询将会重写，错误也不会产生。这种情况下，查询计划就如以下：

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=11 Card=6 Bytes=156)
1 0 SORT (GROUP BY) (Cost=11 Card=6 Bytes=156)
2 1 HASH JOIN (Cost=10 Card=80 Bytes=2080)
3 2 MERGE JOIN (Cost=6 Card=80 Bytes=1520)
4 3 TABLE ACCESS (BY INDEX ROWID) OF 'HOTELS' (TABLE) (Cost=2 Card=8 Bytes=104)
5 4 INDEX (FULL SCAN) OF 'PK_HOTELS' (INDEX (UNIQUE)) (Cost=1 Card=8)
6 3 SORT (JOIN) (Cost=4 Card=80 Bytes=480)
7 6 TABLE ACCESS (FULL) OF 'RESERVATIONS' (TABLE) (Cost=3 Card=80 Bytes=480)
8 2 MAT_VIEW REWRITE ACCESS (FULL) OF 'MV_ACTUAL_SALES' (MAT_VIEW REWRITE) (Cost=3 Card=80 Bytes=560)

这一查询使用了MV_ACTUAL_SALES而不是MV_HOTEL_RESV，这样，表HOTELS和RESERVATIONS就能够访问。这种情况下，特别使对后面两种表会做全表扫描的情况下，将会消耗更多的资源——在你创建MV和设计查询语句时要特别注意。

尽管你已经通过资源管理器（Resource Manager）控制资源使用，使用这一提示能防止在资源管理器被调用前查询被执行。资源管理器基于优化器的统计数据来降低资源的消耗，因此统计数据的有无将会影响这一过程。而“重写还是报错”这一特性将会不管有误统计数据都会阻值表的访问。

更佳的查询计划

在前面的例子中，请注意在查询计划中有这样一行：

MAT_VIEW REWRITE ACCESS (FULL) OF 'MV_ACTUAL_SALES' (MAT_VIEW REWRITE)

这个访问MAT_VIEW REWRITE的方法是新出现的。它表示已经访问了MV，而不是表或者段。这就可以让你在从名字上无法区分时知道是在使用表还是MV。

总结

在10g中，由于增加了新的Tuning Advisor，它能向你提供很多关于MV设计方面的建议而无需通过猜测方式进行。这使得管理MV容易多了。我特别细化能将建议生成一个完整的脚本使实施更加迅速，能节省很多时间这一特性。强制重写或取消查询这一特性在决策支持系统中非常有用。因为这样的系统不允许一个没有被重写的查询在数据库内疯狂执行。