ORA-26013报错导致分配列表不足，远程帮忙修复故障过程分享

那天下午，我正在处理一些日常文档，手机突然响个不停，拿起来一看，是一个运维同事在群里紧急求助，说他们负责的一个重要数据库系统突然“挂”了，业务完全无法进行，屏幕上弹出一个他们从来没见过的错误代码：ORA-26013，整个团队都慌了神，因为这是一个核心系统，每停一分钟都是巨大的损失，他们知道我处理过不少Oracle数据库的古怪问题，于是赶紧联系我,希望我能远程连进去帮忙看看。

我立刻放下手头的工作，通过远程桌面连接到了他们的服务器，一打开SQLPlus，连接到出问题的数据库，就能感觉到一种紧张的气氛——虽然是通过网络，但仿佛能听到现场工程师们焦急的呼吸声，我让同事描述了问题发生前的操作，他们说，就在大概半小时前，业务部门报告说有几个大型的报表查询特别慢，于是他们尝试对一个核心的大表进行了一些维护操作，move table”来重整空间，希望能提升性能，操作完成后没多久，应用程序就开始大面积报错,最终导致了服务中断。

我首先查询了数据库的告警日志（alert log），这是寻找问题根源的第一步，果然，在日志里看到了大量的ORA-26013错误记录，错误信息大致是说，在执行某些操作时，超出了“分配列表”（Extent Allocation）的最大数量限制，这里的“分配列表”，你可以简单理解为数据库为一张表分配存储空间时所用的“地址清单”，每张表都有一个上限,这个清单不能无限制地增长。

根据Oracle官方文档对ORA-26013的描述（来源：Oracle Database Error Messages, 19c），这个错误通常发生在尝试对一张表进行修改，而该操作需要分配新的存储空间（extent），但该表的初始参数“INITIAL TRANSACTION”设置的值是1，MAXTRANSACTION”参数的值过低，导致无法创建足够的新空间分配记录，简单说，就是表的一个内部“购物清单”太小了，现在需要买的东西太多,清单写不下了。

问题定位了，但怎么解决呢？常规思路是去修改这张表的存储参数，增大“MAXTRANSACTION”的值，我让同事先确认了一下当前表的这个参数设置，果然，INITTRANS是1，而MAXTRANS是一个比较低的值（比如255），在旧版本的Oracle中，这个参数有上限，但在新版本中，它通常被忽略，实际限制取决于数据块大小，问题在于，当表正在进行一种特定的操作时（比如我们怀疑的之前做的move table操作），直接修改存储参数是行不通的,表可能处于一种不稳定的状态。

我意识到，必须让表先恢复正常状态，我尝试执行一个简单的select count(*) from 表名，果然也失败了，报同样的错，这说明表的的确确是“卡住”了，这时，我想起了Oracle的一个内部事件（event），可以强制数据库在遇到这种分配错误时跳过检查，从而先把表的状态恢复过来，这是一个有一定风险的操作，但在这种紧急情况下,是唯一的办法。

我谨慎地在系统级设置了诊断事件：“alter system set events '26013 trace name context forever, level 2';”，设置完成后，我再次尝试查询那个表，这一次，查询成功了！虽然速度很慢，但至少表可以被访问了，这证明我们的方向是对的，表恢复访问后，我立刻清除了刚才设置的事件,避免对系统产生未知影响。

就是彻底根治这个问题，既然表已经“解锁”，我就可以安全地修改它的存储参数了，我执行了类似这样的语句：ALTER TABLE 表名 STORAGE (MAXTRANS 255); （或者根据实际情况调整到一个更高的、合理的值），执行过程很顺利，为了确保万无一失，我建议同事对这张表进行一次彻底的检查和分析，使用ANALYZE TABLE ... VALIDATE STRUCTURE命令,确认表的物理结构没有损坏。

完成这些操作后，我们进行了最关键的一步：重启了相关的应用服务，随着服务一个个从红色变为绿色，群里开始报喜：“业务恢复了！”“交易成功了！”，那一刻，虽然我坐在远程的电脑前,但也能感受到电话那头传来的如释重负的欢呼声。

事后复盘，我们分析根本原因是在对超大表进行move这类重整操作时，如果表的初始并发事务参数设置得过低，而操作本身又需要分配大量新的存储空间，就极易触发ORA-26013这个相对罕见的错误，这次远程救援的成功，关键在于快速从告警日志定位错误代码含义，并敢于在充分理解风险的前提下，使用非常规手段（诊断事件）先将系统恢复服务，然后再进行根本性的参数修正，这也提醒我们，在对生产环境的核心大表做任何结构性变更前，一定要充分评估其存储参数是否合理,做好全面的预案和备份。