ORA-39297报错改不了物化视图属性，远程帮忙修复问题分享

（引用来源：根据一次真实的远程技术支持会话记录整理）

那天下午,我正处理着其他事情，电脑上的远程协助软件突然弹出了一个连接请求，接受之后，对方是一位看起来有点焦急的运维工程师，我们叫他小张吧，他开门见山地说，遇到了一个奇怪的数据库问题，卡了好几个小时，实在没辙了。

小张遇到的问题核心就是：他想要修改一个物化视图的某个属性，比如刷新时间或者查询语句，但每次执行修改命令时，数据库都会报一个错，错误代码是ORA-39297，数据库明确告诉他：你不能修改这个物化视图，他试了各种方法，甚至用更高权限的账号去操作，结果还是一样，这个物化视图就像被锁死了一样，纹丝不动。

他首先给我分享了他的屏幕,让我看他操作，他连接到数据库，找到那个物化视图，然后尝试执行一条简单的修改语句，ALTER MATERIALIZED VIEW MV_SALES_DATA REFRESH FAST ON DEMAND，命令刚敲下去，SQL执行窗口立刻变红，ORA-39297错误赫然在目，小张嘟囔着：“你看，就是这样，根本改不了，这个视图明明就是我建的，权限肯定是有的，为什么不让改呢？”

我让他先别急,然后把错误的完整信息复制出来看看，ORA-39297的错误描述通常比较直接，大概意思是说，目标表正在进行在线重定义操作，或者依赖于一个正在在线重定义的表，因此不允许执行所请求的DDL操作（比如ALTER），看到“在线重定义”这几个字，我心里大概有谱了。

我问小张：“这个物化视图MV_SALES_DATA，它所基于的那张原始表，或者说它的主表，最近有没有做过什么大的变动？有没有可能其他同事在对那张主表做一个叫做‘在线重定义’的操作？这个操作可以在不长时间锁表的情况下修改表结构。”

小张愣了一下,说不太确定，需要查一下，他连忙去检查数据库中的作业记录和当前会话，过了一会儿，他有点恍然大悟地说：“哎！我想起来了！大概两个小时前，开发团队确实提过一个需求，要对一张核心业务表加几个字段，要求尽量不影响业务，我们就是用DBMS_REDEFINITION这个包做的在线重定义，而你说的这个物化视图MV_SALES_DATA，正好就是基于那张正在被修改的表！”

问题根源一下子就找到了,物化视图的本质是对一个查询结果的快照，它的结构和数据都依赖于底层的基础表，当基础表正在进行在线重定义这种非常精细且复杂的变化时，数据库为了保证数据的一致性和重定义过程的安全，会自动保护所有依赖于该表的对象，防止它们在重定义完成前被意外修改，这种保护机制就体现在了ORA-39297这个错误上，就好像一栋大楼正在做整体结构加固，在施工期间，物业会禁止住户私自改动自己家的承重墙一样，是为了整体的安全。

我向小张解释了这个原理,他明白了，但接着问：“那现在怎么办？开发那边说重定义可能还要跑一阵子，但我这边急着要改物化视图的刷新策略，有个临时的数据分析需求。”

我告诉他,解决方法有两个：

第一,最直接的办法，就是等待，等那个在线重定义作业彻底完成，一旦主表的重定义成功结束，状态恢复正常，对物化视图的锁定自然就会解除，到时候想怎么改就怎么改，这是最安全、最推荐的做法。

第二,如果确实非常紧急，等不及重定义完成，那么就需要先去中断那个在线重定义过程，但这有风险，因为中断一个进行中的在线重定义可能需要回滚大量数据，可能会影响系统性能，甚至可能导致表状态异常，除非万不得已，并且对后果有充分评估和授权，否则不要轻易这么做。

小张听了之后,权衡了一下，决定采用第一个方案，他马上和开发团队沟通，确认了重定义作业预计完成的时间，然后他调整了自己的工作计划，决定先处理其他任务，等重定义完成后再来修改物化视图。

大概过了一个多小时,小张发来消息，说主表的在线重定义已经成功完成了，他再次尝试修改那个物化视图的属性，这次命令顺利执行，再也没有弹出ORA-39297错误，他非常高兴，说终于解决了这个看似诡异的问题。

通过这次远程帮忙,我们总结的经验就是：当遇到ORA-39297这类“不允许修改对象”的错误时，不要只盯着眼前这个对象本身（比如物化视图），一定要把视野放宽，去检查它依赖的底层对象（比如表、视图等）是否正处于某种特殊的状态或操作中，数据库是一个相互关联的整体，很多看似孤立的问题，根源往往在别处，特别是像在线重定义、数据泵导入导出、长时间运行的事务这类操作，都很容易引起连锁反应，以后遇到类似问题，先查依赖关系，再查相关操作记录，能节省大量盲目排查的时间。