物化视图不是数据搬运工，而是迁移期数据一致性锚点；它需配合kdts等工具实现可控同步，而非直接导入金仓，因语法、函数、调度机制均不兼容，且金仓不支持oracle原生fast刷新，仅支持on commit语义及自有增量逻辑。
materialized view 不是 oracle 迁移的“搬运工”，而是历史系统过渡期的数据一致性锚点。它本身不迁移数据，但能让你在新旧库并行运行时，把 oracle 侧的实时业务数据，按需、可控、可验证地同步到目标库（比如金仓），从而支撑“双轨运行→灰度切流→最终割接”的平滑路径。
物化视图刷新策略选 ON COMMIT 还是 FAST？
这取决于你是否已启用 Oracle 的物化视图日志（MATERIALIZED VIEW LOG）以及源表是否有主键或唯一约束：
-
ON COMMIT刷新最简单：只要事务提交，视图就更新，适合小表或低频写入场景；但它会拖慢主事务，且无法跨库直接生效——必须配合数据库链路（DB Link）或中间同步工具才能落地到金仓； -
FAST刷新依赖日志，性能好、延迟低，但要求严格：源表必须有MATERIALIZED VIEW LOG ON table_name，且日志里要包含ROWID或主键字段；实测中，约 30% 的遗留系统因缺少日志或无主键，导致FAST刷新自动退化为COMPLETE，反而加剧锁表风险； - 金仓数据库支持
ON COMMIT刷新语义，且行为与 Oracle 一致；但不支持 Oracle 风格的FAST刷新机制——它用的是自己的增量捕获逻辑，需通过 KDTS 工具或 CDC 组件对接 Oracle 日志源。
为什么不能直接把 Oracle 的 MATERIALIZED VIEW 导入金仓？
因为物化视图本质是“带存储的查询结果”，不是独立对象。它的定义依赖于源表结构、权限、函数、甚至 NLS 设置：
- Oracle 中用
TO_DATE('2024-01-01', 'YYYY-MM-DD')，金仓默认解析可能失败，除非开启oracle_compatibility = on参数； - 如果视图里调用了
DBMS_LOB或UTL_HTTP等 Oracle 私有包，金仓即使有同名系统包（如DBMS_LOB），参数签名或返回类型也可能不一致； - 更关键的是：Oracle 物化视图的刷新调度（如
DBMS_SCHEDULER）无法被金仓识别，直接导入只会留下一个静态快照表，失去“视图”意义。
如何让物化视图真正服务于迁移过程？
把它当作一个“数据契约”来用，而不是一个自动同步开关：
- 先在 Oracle 侧建好带日志、可
FAST刷新的物化视图，确认它能稳定产出符合业务口径的结果集； - 用 KDTS 工具扫描该视图，自动生成金仓端等效的
CREATE MATERIALIZED VIEW ... REFRESH ON COMMIT语句，并提示不兼容项（比如SYSDATE需替换为CURRENT_TIMESTAMP）； - 在金仓侧部署后，不依赖其自动刷新，而是用定时任务拉取 Oracle 视图的当前快照（
SELECT * FROM mv_name），再通过COPY或INSERT INTO ... SELECT写入本地表——这样既可控，又能绕过函数/类型兼容性问题； - 每日比对两边的
COUNT(*)和校验和（如MD5(STRING_AGG(...))），形成迁移质量报告。
真正难的从来不是语法转换，而是搞清哪些字段在 Oracle 里是隐式 TO_CHAR 转换、哪些索引在物化视图刷新时被悄悄禁用、以及 DBA 是否真的清楚那个“每小时刷新一次”的物化视图，底层到底走的是 FAST 还是 COMPLETE。这些细节，往往在割接前 48 小时才暴露。
