这个错误的核心原因很明确：DBMS_METADATA.GET_DDL函数不支持CHAIN作为有效的对象类型参数，但你的查询结果里偏偏混入了OBJECT_TYPE为CHAIN的对象——哪怕你加了OBJECT_TYPE='TABLE'的过滤条件，大概率是执行时的语法问题或者过滤逻辑没生效导致的。

可能的触发原因 #

• 你把多个SET命令和SELECT语句写在了同一行，SQL*Plus解析时出现异常，导致过滤条件没有正确执行；
• MY_SCHEMA下存在非标准TABLE类型的对象（比如临时表、分区表），或者确实有CHAIN类型的对象没被过滤掉；
• 极少数情况是DBA_OBJECTS视图的对象类型标记异常，但这种情况非常罕见。

具体解决方案 #

1. 拆分SET命令，确保环境参数生效 #

SQL*Plus里的SET命令需要单独成行执行，把你的语句拆成这样，避免解析异常：

-- 先设置环境变量，防止DDL内容被截断、表头干扰输出
set long 90000
set heading off
set lines 100

-- 执行DDL查询，直接指定GET_DDL的对象类型为'TABLE'
select dbms_metadata.GET_DDL('TABLE', u.object_name, 'MY_SCHEMA') 
from dba_objects u 
where owner = 'MY_SCHEMA' 
-- 涵盖所有常见表类型，避免漏掉临时表、分区表
AND OBJECT_TYPE IN ('TABLE', 'GLOBAL TEMPORARY TABLE', 'PARTITIONED TABLE');

这里直接给GET_DDL传入固定的'TABLE'参数是关键——Oracle的GET_DDL函数用'TABLE'就可以获取大多数表类型（包括临时表、分区表）的DDL，不用依赖DBA_OBJECTS里的OBJECT_TYPE字段，从根源避免了类型名称不匹配的问题。

2. 先排查SCHEMA下的对象类型 #

如果想确认MY_SCHEMA下到底有哪些对象类型，可以先执行这个查询：

select distinct object_type 
from dba_objects 
where owner = 'MY_SCHEMA';

这样你就能清楚看到是否存在CHAIN类型的对象，再针对性调整过滤条件。比如如果确实有CHAIN对象，直接在WHERE里排除：

select dbms_metadata.GET_DDL(u.object_type, u.object_name, 'MY_SCHEMA') 
from dba_objects u 
where owner = 'MY_SCHEMA' 
AND OBJECT_TYPE='TABLE'
AND u.object_type != 'CHAIN';

不过还是推荐第一种方案，直接固定GET_DDL的对象类型，更稳妥。

3. 补充说明：为什么CHAIN类型会触发错误？ #

CHAIN是Oracle Scheduler中的链对象，DBMS_METADATA.GET_DDL并不支持直接获取它的DDL。如果需要获取CHAIN的定义，得用专门的调度器函数（比如DBMS_SCHEDULER.GET_CHAIN_DDL），但这是另一个独立需求了。

内容的提问来源于stack exchange，提问作者SocketM