ORA-02145报错没写STORAGE参数，数据库卡住了远程帮忙修复方法分享

ORA-02145报错没写STORAGE参数，数据库卡住了远程帮忙修复方法分享

这个ORA-02145错误，我记得很清楚，当时是帮一个朋友处理他们公司的测试数据库时遇到的，他那边的情况是，数据库管理员离职了，临时让他一个开发兼管一下，结果他在尝试给一个重要的表添加一个新的字段时，整个数据库的操作突然就卡住了，弹出的错误就是“ORA-02145: missing STORAGE option”，他一下子就慌了，因为不仅这个加字段的操作进行不下去，连后续尝试的其他一些管理操作也卡住或者报错，感觉数据库就像“半死”了一样，他赶紧打电话给我,让我远程帮忙看看。

因为我没法直接看到他的屏幕和操作，所以第一步就是让他把错误信息完整地截图发给我，确认是ORA-02145之后，我让他别慌，这个错误虽然看起来吓人，但原因很明确，我跟他解释，这个错误通常发生在一种比较特殊的情况下：数据库正在处于一种叫做“延迟段创建”的模式下，但同时又有人手动去管理了一个叫做“回滚段”的东西。

这里要稍微解释一下，不然听不懂，用我朋友能理解的话说就是：在Oracle数据库里，默认情况下，你创建一张表，数据库并不会马上在硬盘上为你划出一块真正的空间来存放这张表的数据，它会等你要真正往里插入第一条数据的时候才去划这个空间，这个“等等再划”的行为，就叫“延迟段创建”，这是个好功能，能节省空间，而“回滚段”呢，你可以把它想象成一个“后悔药”或者“临时记事本”，当你对数据进行修改（比如更新、删除）时，数据库会先把旧的数据拷贝一份放到这个“回滚段”里，万一你后悔了，说要回滚事务,它就能从这里把旧数据找回来。

问题就出在这里，当“延迟段创建”功能开启时，如果你去对一个还没有真正在硬盘上分配空间的新表（或者新分区）执行一条需要用到“回滚段”的DDL语句（比如ALTER TABLE ADD column），Oracle就会有点“懵”，它需要为这个操作本身记录一些信息到回滚段里，但这个表又还没有实际的段，在某种内部机制下，它就不知道该怎么为这个“尚不存在的段”的相关操作分配回滚空间了，于是就会抛出ORA-02145错误，并且要求你必须明确指定STORAGE参数,其实就是逼你明确告诉它该怎么分配空间。

在现在的Oracle版本中，我们通常不推荐也不需要在DDL语句里手动写STORAGE参数了，因为数据库自动管理得更好，这个错误等于是把一个过时的、我们不用的语法当成了必选项,导致操作卡死。

明白了原因，解决办法就有了方向，核心思路就是绕过这个矛盾点，我当时给了朋友两个解决方案,让他逐个尝试。

第一个方法是最简单直接的：关闭延迟段创建功能，我让他用数据库管理员的账号登录，然后执行一条命令：ALTER SESSION SET DEFERRED_SEGMENT_CREATION = FALSE;，这条命令的意思是，告诉数据库：“在我当前这个会话（也就是他正在用的这个连接窗口）里，暂时别用那个‘等等再划空间’的功能了，我创建表或者修改表的时候，请你立刻、马上就把空间给我划好。” 执行完这个会话级别的设置后，我让他再次尝试运行之前那个添加字段的SQL语句，他试了一下，果然，之前卡了半天的命令瞬间就执行成功了，表结构顺利修改,数据库也恢复了正常。

第二个方法是备选方案，以防第一个方法因为某些未知原因不生效，这个方法就是，既然错误提示说缺STORAGE参数，那我们就强行给它加上一个，我们不用去研究复杂的STORAGE参数怎么设置，就用最简单的、象征性的参数满足它的语法要求就行，我让他把添加字段的语句修改一下，在语句的最后加上 STORAGE (BUFFER_POOL DEFAULT)，这行代码基本上等于没做任何特殊的存储设置，只是用了默认的缓冲池，但它在语法上满足了Oracle的要求，他把这个带参数的SQL语句执行了一下,也成功了。

问题解决后，我提醒他，为了避免以后再遇到这个烦人的错误，可以考虑到数据库的系统级别把这个“延迟段创建”功能给永久关闭掉，这需要谨慎评估，因为对于有大量雏形表（创建了但长期不用）的系统，这个功能还是能省点空间的，关闭的系统级命令是：ALTER SYSTEM SET DEFERRED_SEGMENT_CREATION = FALSE;，不过这个操作影响范围是整个数据库，他因为是测试库，所以就直接关了，如果是生产库,一定要先做好评估。

总结一下这次远程帮忙的经验，面对ORA-02145错误，关键点就两个：一是理解错误根源在于“延迟段创建”和特定DDL操作的冲突；二是掌握“临时关闭延迟段创建”这个最有效的解决方法,希望这个真实的处理经过对遇到类似问题的人有帮助。