第 4 部分 数据仓库和集成特性

第4 部分：数据仓库和集成特性用于更高效管理物化视图、查询重写、可传输表空间以及表分区的新特性使数据仓库变得更加强大且占用资源更少。

这一部分涉及：·在没有MV 日志的情况下进行分区更改跟踪·使用多个MV 进行查询重写·通过备份实现可传输表空间·对已分区的按索引组织的表进行快速的分区分割·通过联机重新定义进行LONG 到LOB 的转换·联机重新组织单个分区·逐个分区地删除表分区更改跟踪：不需要MV 日志要了解此增强功能，首先必须了解物化视图(MV) 刷新过程中的分区修整概念。

假设基于列ACC_MGR_ID 对表ACCOUNTS 进行了分区，每个ACC_MGR_ID 值一个分区。

您根据ACCOUNTS 创建了一个名为ACC_VIEW 的MV，该MV 也根据列ACC_MGR_ID 进行了分区，每个ACC_MGR_ID 一个分区，如下图所示：假设已经更新了表ACCOUNTS 中的记录，但只在分区P1 中进行了此更新。

要快速刷新此MV，您只需刷新分区P1 而非整个表，这里正是与ACC_MGR_ID 相关的数据所在的分区。

Oracle 自动执行此任务，通过一个名为分区更改跟踪(PCT) 的特性跟踪对分区的更改。

但有一个问题需稍加注意：要在快速刷新的过程中启用PCT，必须创建MV 日志，当表中的行发生变化会填充这些日志。

发出刷新命令后，刷新进程将读取MV 日志以识别这些更改。

不用说，该要求增加了操作的总执行时间。

此外，附加的插入操作将消耗CPU 周期和I/O 带宽。

幸好，在Oracle 数据库10g第2 版中，PCT 不需要MV 日志即可工作。

让我们看一看它的作用方式。

首先，确认表ACCOUNTS 中没有MV 日志。

SQL> select *2 from dba_mview_logs3 where master = 'ACCOUNTS';no rows selected现在，更新该表中的某个记录。

update accounts set last_name = '...'where acc_mgr_id = 3;该记录位于分区P3 中。

现在，您就可以刷新此MV 了。

但首先记录表ACCOUNTS 所有段的段级统计信息。

稍后，您将使用这些统计信息了解使用了哪些段。

select SUBOBJECT_NAME, value from v$segment_statisticswhere owner = 'ARUP'and OBJECT_NAME = 'ACCOUNTS'and STATISTIC_NAME = 'logical reads'order by SUBOBJECT_NAME/SUBOBJECT_NAME VALUE------------------------------ ----------P1 8320P10 8624P2 12112P3 11856P4 8800P5 7904P6 8256P7 8016P8 8272P9 7840PMAX 25611 rows selected.使用快速刷新刷新物化视图ACC_VIEW。

execute dbms_mview.refresh('ACC_VIEW','F')'F'参数指示快速刷新。

但如果表没有MV 日志，它是否可以起作用？刷新完成后，再次检查表ACCOUNTS 的段统计信息。

结果如下所示：SUBOBJECT_NAME VALUE------------------------------ ----------P1 8320P10 8624P2 12112P3 14656P4 8800P5 7904P6 8256P7 8016P8 8272P9 7840PMAX 256这些段统计信息显示了在一个逻辑读取过程中选择的段。

由于这些统计信息是累积的，因此您必须查看值（而非绝对值）中的更改。

如果仔细查看以上值，您便会发现只有分区P3 的值发生了变化。

因此，在刷新过程中只选择了分区P3 而非整个表，确认PCT 能否在表即使没有MV 日志的情况下工作。

即使在基表没有MV 日志的情况下也可以快速刷新MV 的能力是一个强大而有用的特性，从而允许您可以在已分区的MV 中执行快速刷新而不会增加性能开销。

我认为，该特性是Oracle 数据库10g第2 版中最有用的数据仓库增强功能。

使用多个MV 进行查询重写Oracle8i中引入的查询重写特性在数据仓库开发人员和DBA 中轰动一时。

从本质上而言，它将用户查询重写为从MV 而非表中进行选择以利用现成的摘要。

例如，请考虑以下一家大型连锁酒店的数据库中的三个表。

SQL> DESC HOTELSName Null?Type----------------------------------------- -------- ------------- HOTEL_ID NOT NULL NUMBER(10)CITY VARCHAR2(20) STATE CHAR(2) MANAGER_NAME VARCHAR2(20) RATE_CLASS CHAR(2)SQL> DESC RESERVATIONSName Null?Type----------------------------------------- -------- ------------- RESV_ID NOT NULL NUMBER(10) HOTEL_ID NUMBER(10)CUST_NAME VARCHAR2(20) START_DATE DATEEND_DATE DATERATE NUMBER(10)SQL> DESC TRANSName Null?Type----------------------------------------- -------- ------------- TRANS_ID NOT NULL NUMBER(10)RESV_ID NOT NULL NUMBER(10) TRANS_DATE DATEACTUAL_RATE NUMBER(10)表HOTELS 保存酒店的相关信息。

当顾客预订酒店时，将在表RESERVATIONS（包含房间价格报价）中创建一个记录。

当顾客在酒店结帐时，将在另一个表TRANS 中记录现金交易。

但在结帐前，酒店可能决定根据订房情况、升级、优惠等因素向顾客提供不同的房价。

因此，最终的房价可能与预订时的报价不同，而且可以每天都各不相同。

为正确记录这些价格变化，表TRANS 有一行专门用来保存每天的房价信息。

为缩短查询响应时间，您可能决定根据用户发出的不同查询构建MV，如：create materialized view mv_hotel_resvrefresh completeenable query rewriteasselect city, resv_id, cust_namefrom hotels h, reservations rwhere r.hotel_id = h.hotel_id;和create materialized view mv_actual_salesrefresh completeenable query rewriteasselect resv_id, sum(actual_rate) from trans group by resv_id;因此，如果设置了某些参数（如query_rewrite_enabled = true），则类似如下所示的查询select city, cust_namefrom hotels h, reservations rwhere r.hotel_id = h.hotel_id;将重写为select city, cust_namefrom mv_hotel_resv;。

您可以通过运行该查询并启用自动跟踪来确认MV。

SQL> set autot traceonly explainSQL> select city, cust_name2> from hotels h, reservations r3> where r.hotel_id = h.hotel_id;Execution Plan----------------------------------------------------------0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=80 Bytes=2480)1 0 MAT_VIEW ACCESS (FULL) OF 'MV_HOTEL_RESV' (MAT_VIEW) (Cost=3 Card=80 Bytes=2480)注意，查询是如何从物化视图MV_HOTEL_RESV 而非表HOTELS 和RESERVATIONS 中进行选择的。

这正是您所需要的。

同样，当您编写一个查询来汇总每个预订编号的实际价格时，将使用物化视图MV_ACTUAL_SALES 而非表TRANS。

我们来采用一个不同的查询。

如果要查明每个城市的实际销售额，则将发出select city, sum(actual_rate)from hotels h, reservations r, trans twhere t.resv_id = r.resv_idand r.hotel_id = h.hotel_idgroup by city;注意此查询结构：从MV_ACTUAL_SALES 中，您可以获得RESV_ID 和预订的总销售额。

从MV_HOTEL_RESV 中，您可以获得CITY 和RESV_ID。

您能将这两个MV 连接在一起吗？当然可以，但在Oracle 数据库10g第2 版之前，查询重写机制只使用两个MV 中的一个（而非两个）自动重写用户查询。

以下是Oracle9i数据库中的执行计划输出。

您可以看到，只使用了MV_HOTEL_RESV 和TRANS 的整表扫描。

Execution Plan----------------------------------------------------------0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=8 Card=6 Bytes=120)1 0 SORT (GROUP BY) (Cost=8 Card=6 Bytes=120)2 1 HASH JOIN (Cost=7 Card=516 Bytes=10320)3 2 MAT_VIEW REWRITE ACCESS (FULL) OF 'MV_HOTEL_RESV' (MAT_VIEW REWRITE)(Cost=3 Card=80 Bytes=1040)4 2 TABLE ACCESS (FULL) OF 'TRANS' (TABLE)(Cost=3 Card=516 Bytes=3612)即使MV 可用，该方法也将生成一个非最优的执行计划。