为什么Oracle 11g不支持对物化视图进行分区操作？

Oracle 11g不支持对物化视图本身做分区操作，因其本质是逻辑对象而非用户可控的物理表，底层结果表由系统自动管理且不开放DDL权限，既无CREATE MATERIALIZED VIEW PARTITION BY语法，也无法执行ALTER TABLE ... ADD PARTITION等操作。

Oracle 11g 不支持对物化视图本身做分区操作，因为物化视图在 11g 中不是物理存储对象的“表”，而是带查询重写能力的特殊视图 + 底层结果表的组合体；其底层结果表由 Oracle 自动管理，不开放 DDL 控制权。

物化视图在 11g 中没有独立的分区语法

你不能对 MATERIALIZED VIEW 对象执行 ALTER TABLE ... ADD PARTITION 或 CREATE MATERIALIZED VIEW ... PARTITION BY ...。Oracle 11g 的 DDL 语法中根本不存在 PARTITION BY 子句用于物化视图定义——该语法直到 12c 才在部分场景（如基于分区表的物化视图）中通过隐式继承实现，但依然不等于“物化视图可分区”。

1. CREATE MATERIALIZED VIEW 语句在 11g 中只接受 ON PREBUILT TABLE、BUILD IMMEDIATE 等子句，没有 PARTITION 相关关键字
2. 即使底层结果表（如 MVIEW$_xxx）是普通表，它也由 Oracle 内部命名、锁定、维护，用户无法直接 ALTER TABLE 它
3. 尝试对物化视图名执行分区操作会报错：ORA-02518: partitioning type not supported for this object type

11g 的物化视图结果表不可见、不可控

11g 中，物化视图刷新后生成的结果数据，存放在 Oracle 自动生成的内部表（例如 SYS.MLOG$_... 日志表、或以 MVIEW$_... 命名的堆表）中。这些表：

1. 不在 USER_TABLES 中暴露（除非用 DBA_TABLES 并知道确切命名规则）
2. 没有主键、索引、约束等常规元数据保障，也不支持 MOVE、EXCHANGE PARTITION 等操作
3. 若强行用 ALTER TABLE 对其分区，会破坏物化视图与日志、刷新引擎的绑定关系，导致后续 REFRESH 失败或数据错乱

真正能分区的是基表，不是物化视图

11g 支持的是「在分区表上创建物化视图」，而非「把物化视图分区」。关键区别在于：

1. 你可以对基表（比如 sales_part）按时间范围分区，并在其上建物化视图 mv_sales_monthly
2. 物化视图能否利用分区裁剪，取决于查询是否带精确分区键谓词（如 WHERE sale_date BETWEEN ...），以及是否启用 QUERY REWRITE
3. 但 mv_sales_monthly 本身仍是单个逻辑对象，它的数据全存在一张不可分区的内部表里
4. 所谓“分区物化视图”只是社区俗称，实际指「基表分区 + 物化视图定义合理 + 查询能触发分区裁剪」的组合效果

为什么 11g 不提供这个能力？

根本原因不是技术做不到，而是设计取舍：

1. 物化视图核心目标是查询重写和增量刷新，不是大表物理管理；分区功能当时主要服务于 OLTP 和归档场景，与 MV 的定位不重叠
2. 11g 的快速刷新引擎依赖统一日志结构（mlog$），若结果表分区，日志需跨分区同步，会显著增加刷新复杂度和锁冲突风险
3. 直到 19c，Oracle 才通过重构刷新引擎、强制 INCLUDING NEW VALUES + SEQUENCE 组合，为分区感知刷新打下基础——但这仍不等于“物化视图可分区”，只是让 FAST REFRESH 能按分区粒度加锁

真正容易被忽略的一点：即使你在 11g 中用 ON PREBUILT TABLE 把物化视图绑定到一个你自己建的分区表上，Oracle 也不会承认它是“分区物化视图”——DBMS_MVIEW.EXPLAIN_MVIEW 会直接标记 REFRESH_FAST 不可用，因为预建表的分区结构不参与刷新逻辑校验。