ORA-12913报错导致字典管理表空间创建失败，远程协助解决故障全过程分享

（引用来源：某金融系统数据库管理员王工的故障处理记录）

那天下午,我正准备下班，突然接到一个电话，是另一个业务部门的同事小李打来的，他听起来很着急，说他们在测试环境尝试创建一个新的表空间时，数据库一直报错，操作无法完成，卡在这里影响了测试进度，他直接把错误信息截图发给了我，上面清晰地显示着“ORA-12913: Cannot create dictionary managed tablespace”。

看到这个错误代码,我第一反应是“这有点年头没见过了”，因为现在Oracle数据库默认创建的表空间都是本地管理的（Local Managed Tablespace, LMT），性能更好，管理更简单，而字典管理表空间（Dictionary Managed Tablespace, DMT）是一种很老的管理方式，依赖于数据字典表来管理空间分配，容易引起性能瓶颈，所以在新版本中已经不推荐使用了，我有点好奇他们为什么要创建这种类型的表空间。

我让小李先别挂电话,通过远程桌面软件连接到了他的电脑，我让他打开SQLPlus，以SYSDBA身份登录到数据库，我要确认一下数据库的基本情况，我让他执行了查询语句 `SELECT FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME = 'DEFAULT_TBS_TYPE';`，结果很快出来了，属性值显示为‘LOCAL’，这说明数据库的默认表空间管理方式确实是本地管理，这没问题。

我让他把创建表空间的那个SQL脚本发给我看,脚本内容大致是这样的： CREATE TABLESPACE old_fashioned_tbs DATAFILE '/u01/app/oracle/oradata/ORCL/old_fashioned_tbs01.dbf' SIZE 100M EXTENT MANAGEMENT DICTIONARY; 问题就出在最后一句“EXTENT MANAGEMENT DICTIONARY”上，他明确指定了要创建字典管理的表空间。

（引用来源：Oracle官方文档对ORA-12913错误的解释摘要）

我回想了一下Oracle的版本特性,从Oracle 9i开始，虽然还支持创建DMT，但通常有一个系统级的参数来控制是否允许创建，如果这个参数被设置为禁止，那么即使你明确指定，也会报ORA-12913错误，这个参数叫做COMPATIBLE。

我让小李执行了 SHOW PARAMETER COMPATIBLE;，参数值显示为‘19.0.0’，这是一个很高的兼容性版本了，理论上应该支持创建DMT才对，看来不是这个原因。

我又仔细想了想,既然兼容性没问题，那很可能是在数据库创建时或之后，被明确禁止了创建DMT的权限，这涉及到另一个隐藏的初始化参数，我让小李尝试查询一个不太常用的视图：SELECT * FROM V$PARAMETER WHERE NAME LIKE '%dictionary%';，但没有找到相关信息。

（引用来源：Oracle Metalink知识库中关于该问题的技术笔记）

这时,我记起来，有一个关键的参数叫做SYSTEM表空间的管理方式，如果SYSTEM表空间是本地管理的，那么整个数据库就不能再创建任何字典管理的表空间了，这是Oracle为了确保系统稳定性和性能而设定的规则，我让小李执行了以下查询来验证： SELECT TABLESPACE_NAME, EXTENT_MANAGEMENT, ALLOCATION_TYPE FROM DBA_TABLESPACES WHERE TABLESPACE_NAME = 'SYSTEM'; 查询结果一目了然：SYSTEM表空间的EXTENT_MANAGEMENT列显示为‘LOCAL’，ALLOCATION_TYPE是‘SYSTEM’，这就对了！根源找到了。

我向小李解释：“你看，我们的SYSTEM表空间是本地管理的，根据Oracle的规矩，一旦‘老大’（SYSTEM表空间）用了本地管理这种新方法，下面就不能再出现用老方法（字典管理）的表空间了，所以你的创建语句才会失败。”

小李恍然大悟,接着问：“那现在怎么办？我们这个脚本是很多年前遗留下来的，必须用这种方式吗？”

我告诉他,强烈不建议使用字典管理，我问他这个表空间的用途，他说只是用来测试一些历史遗留功能的兼容性，我建议他直接去掉EXTENT MANAGEMENT DICTIONARY这句，让表空间使用默认的本地管理方式创建，这样既简单又高效，如果测试场景确实必须模拟古老的DMT环境（这种情况极少），那可能需要在数据库创建之初就将SYSTEM表空间设置为字典管理，但这对于现有数据库来说是不可行的，需要重建整个库，代价太大。

小李和他的团队沟通后,确认可以改用本地管理表空间，我指导他将创建语句修改为： CREATE TABLESPACE old_fashioned_tbs DATAFILE '/u01/app/oracle/oradata/ORCL/old_fashioned_tbs01.dbf' SIZE 100M AUTOALLOCATE; （AUTOALLOCATE是本地管理表空间的一种扩展分配方式，也可以不写，使用默认的UNIFORM大小）。

他执行了修改后的语句,这次非常顺利，表空间瞬间就创建成功了，小李连连道谢，说终于可以继续他们的测试了。

通过这次远程协助,我总结的经验是：遇到ORA-12913这类看似“古老”的错误，不要慌，首先要理解新旧版本特性的差异，然后沿着“默认设置 -> 显式指定 -> 系统级限制”这条线索去排查，最关键的一点，就是要检查SYSTEM表空间的管理方式，这往往是解决问题的钥匙，虽然这次问题本身不复杂，但清晰地理解其背后的原理，能帮助我们快速定位并解决故障。