ORA-31500错误，换源字符串不是ManualLog类型，远程帮忙修复故障过程分享

开始）

我之前在网上一个技术论坛上，看到一位网名叫“数据库老船长”的工程师分享过他处理一次ORA-31500错误的经历，我觉得他这个经历特别典型，而且他讲得很直白，没有用一大堆吓人的专业名词，所以我就根据他的帖子,把整个过程用我的话再转述一遍。

“数据库老船长”说，他那次接到一个紧急电话，说公司的核心数据库在做一个叫“数据泵导出”的操作时（就是一种把大量数据从数据库里打包导出来的工具），突然就失败了，屏幕上蹦出来一个他以前没怎么见过的错误代码：ORA-31500，错误信息大概意思是“换源字符串不是ManualLog类型”，他当时第一反应也是有点懵，因为平时常见的错误代码都记得差不多，这个ORA-31500确实不常碰到。

他首先做的，就是让自己别慌，然后仔细看了看完整的错误信息，他发现这个错误是在执行一个叫“传输表空间”的步骤时发生的，他打了个比方，说“传输表空间”有点像搬家的时候，不是把家具一件件拆了搬走，而是直接把整个房间（表空间）的结构和数据一起打包搬走，这样效率非常高，而这个操作需要一个前提，就是被搬走的这个“房间”必须处于一种叫做“只读”的状态，就像把房间门锁上，贴上封条,保证在搬家过程中里面的东西一动不动。

怎么告诉数据库这个“房间”已经贴好封条了呢？这里就涉及到错误信息里提到的“ManualLog”了，他解释说，在Oracle数据库里，有一种记录数据变化的方式，当表空间被设置为只读后，数据库需要一种机制来记录这之后可能发生的、极少量的特殊数据变化（比如一些内部管理操作），这个记录过程就是“日志”，而“ManualLog”是一种手动管理日志的模式，他猜测，问题就出在这里：数据库期望这个要搬家的表空间是“ManualLog”模式,但实际检查后发现它不是。

想到这儿，他立刻登录到数据库服务器，用了一个简单的查询命令，去检查那个出问题的表空间的状态，果然，查询结果明确显示，这个表空间的日志模式是“AUTO”，也就是自动管理，而不是错误信息所要求的“MANUAL”。

原因找到了，就像医生确诊了病情，接下来就是开药方，解决办法很简单，就是把表空间的日志模式从“自动”改成“手动”，他使用了一条SQL命令，大致是ALTER TABLESPACE 表空间名字 LOGGING MANUAL;，执行这条命令非常快，几乎是一瞬间就完成了，他为了保险起见，又再次运行了之前那个查询命令，确认了一下，现在表空间的日志模式已经成功地变成了“MANUAL”。

改完之后，就是最紧张的测试环节，他重新启动了之前失败的那个数据泵导出作业，这一次，他紧盯着屏幕上的滚动日志，心里还是有点打鼓，当作业顺利通过了之前报错的那个节点，并且最终显示“成功完成”时，他总算松了一口气,故障就这样被修复了。

在分享的最后，“数据库老船长”总结了几点心得，第一，遇到不熟悉的错误代码，不要害怕，最重要的是仔细阅读错误信息本身，它往往已经给出了非常明确的线索，这次错误直接指出了“不是ManualLog类型”，就是最直接的指引，第二，要理解操作背后的原理，如果他不知道“传输表空间”需要表空间处于“只读”状态，以及“ManualLog”在这个场景下的作用，他可能就无法快速定位问题，第三，操作要谨慎，在修改生产数据库的参数前，哪怕是一个看似简单的修改，他都会反复确认表空间的名字和当前状态，避免操作错误对象，他说，这次故障从分析到解决，前后也就花了不到半小时，关键就在于读懂了错误提示并且知道其背后的逻辑。 结束）