分区刷新（PCT）能降低系统资源占用，因为它仅刷新源表和物化视图中变更的对应分区数据，避免全表扫描日志和重建整个物化视图段，显著减少I/O与CPU开销。
分区刷新（PCT）为什么能降低系统资源占用
分区刷新不是“换个方式刷”，而是把物化视图和源表都按相同策略分区后，只刷新变更的分区数据。这意味着 fast 刷新不再扫全表日志，也不再重建整个物化视图段；oracle 只读取对应分区的物化视图日志（mlog$）并更新对应分区的数据块。这对大表尤其关键——比如一个 5tb 的销售明细表按月分区，某天只改了 202604 分区的数据，pct 就只处理这个分区，跳过其余 35 个历史分区。
启用 PCT 前必须确认的三件事
很多 DBA 一上来就加 ENABLE QUERY REWRITE 或直接建分区 MV，结果刷新失败或根本不用 PCT。真正起作用的前提是：
- 源表必须是分区表，且分区键字段出现在物化视图的
SELECT列表中（例如sale_date或region_id） - 物化视图本身也必须声明为分区表，并与源表使用相同的分区类型（
RANGE/LIST）、相同分区键、相同分区边界 - 创建物化视图日志时必须显式指定
WITH ROWID, SEQUENCE和所有参与连接/聚合的列，且加上INCLUDING NEW VALUES
刷新时锁表范围缩小，但 DML 开销会上升
PCT 刷新对业务最直观的好处是：刷新期间只锁被修改的分区，而不是整张物化视图表。用户查其他分区数据完全不受影响。但代价是基表每次 INSERT/UPDATE/DELETE 都要写入更细粒度的日志记录——因为 Oracle 要精确标记哪一行属于哪个分区。如果源表 DML 频率极高（比如每秒上千次），MLOG$ 表可能成为瓶颈，表现为 log file sync 等待上升或事务响应变慢。
监控 PCT 是否真正在工作
别光看 DBA_MVIEWS.REFRESH_METHOD = 'FAST' 就以为 PCT 生效了。实际是否走分区级刷新，得查刷新日志或运行时执行计划：
- 查询
V$MVREFRESH视图中的START_TIME和END_TIME，对比单次刷新耗时是否随数据变更量线性增长（PCT 应基本稳定） - 在刷新后立即执行
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id'))，确认执行计划里出现PARTITION RANGE SINGLE或PARTITION LIST ITERATOR - 检查
DBA_MVIEW_LOGS中ROWIDS和SEQUENCE是否为YES，否则 PCT 不可用
最容易被忽略的是：即使启用了 PCT，一旦物化视图定义里用了不支持的函数（如 SYSDATE、ROWNUM）或未包含分区键字段，Oracle 会自动降级为全表 FAST 刷新——表面成功，实则资源没省下来。
