ORA-39058报错导致对象跳过，远程修复思路和故障排查分享

（引用来源：Oracle官方文档关于Data Pump的说明，以及多位Oracle DBA在社区论坛如OTN、Oracle Support上的案例分享）

ORA-39058这个错误在使用Oracle数据泵（Data Pump）进行数据导入或导出时非常常见，它的核心意思很简单：数据泵在处理某个对象（比如一张表、一个索引、一个视图）时遇到了问题，它决定跳过这个有问题的对象，然后继续处理剩下的，报错信息里通常会明确告诉你被跳过的对象叫什么名字。

直接看这个错误可能会觉得没什么,毕竟数据泵还在继续运行，但隐患很大，因为这意味着你的这次数据迁移或备份是不完整的，可能最后日志显示“成功完成”，但数据库里已经少了一些重要的表或数据，一旦看到这个错误，绝对不能忽视。

为什么会出现ORA-39058？

根据大家的经验,原因五花八门，但主要集中在以下几个方面：

1. 对象已经存在：这是最常见的原因之一，特别是在导入时，如果目标数据库里已经存在同名的表、用户等，而你又没有使用TABLE_EXISTS_ACTION参数来告诉数据泵该怎么做（比如替换、追加、跳过），数据泵就可能因为冲突而跳过这个对象，并报出39058警告。
2. 权限不足：执行导入操作的用户（无论是源库导出还是目标库导入）可能没有足够的权限去访问或创建某个对象，要导出的表属于另一个用户，而执行导出的用户没有该表的SELECT权限；或者导入的用户没有CREATE ANY TABLE的权限。
3. 空间不足：表空间满了，导致无法创建新的数据段（比如新表或新索引），数据泵尝试创建对象时发现没地方放了，只能跳过。
4. 对象本身有问题或不受支持：有时候对象可能处于一种奇怪的状态，或者是一个非常特殊的对象类型，数据泵无法正常处理，尝试导出包含加密列的表但没有正确的加密钱包设置。
5. 网络或存储不稳定：在远程操作中，如果网络连接闪断，或者共享目录（如Dump文件存放的目录）出现短暂的访问问题，也可能导致数据泵无法读取或写入某个对象的定义或数据，从而将其跳过。

远程修复思路和故障排查步骤

当你在远程处理这个问题时,不能像在机房一样直接查看服务器状态，所以思路要清晰，主要依靠日志和SQL命令。

第一步：立刻查看日志，锁定目标

不要只看命令行窗口的简单输出,数据泵会生成一个非常详细的日志文件（通过LOGFILE参数指定），这是你最重要的线索，打开这个日志文件，直接搜索“ORA-39058”或“SKIPPED”，找到具体是哪个对象被跳过了，日志里通常会紧接着给出跳过这个对象的具体原因，ORA-31655: no data or metadata objects selected for job”（可能权限问题）或“ORA-00955: name is already used by an existing object”（对象已存在），这个具体的ORA错误代码是下一步排查的关键。

第二步：根据具体原因，分情况处理

1. 如果是“对象已存在”（常见ORA-00955）：

   • 策略选择：你需要决定如何处理这些已存在的对象。
     • 如果可覆盖：在导入命令中增加参数TABLE_EXISTS_ACTION=REPLACE，这会告诉数据泵：如果表存在，就先删除旧的，再创建新的，但务必谨慎，确认覆盖目标库的数据是可接受的。
     • 如果需追加数据：使用TABLE_EXISTS_ACTION=APPEND，但这要求表结构必须完全一致。
     • 如果需跳过：有时你确实想跳过，那么39058反而是预期的行为，可以忽略。
   • 手动处理：如果冲突对象不多，可以先在目标库手动删除（DROP TABLE ...）或重命名这些已存在的对象，然后重新运行导入。

2. 如果是“权限不足”（常见ORA-31655, ORA-01031）：

   • 检查导出用户权限：在源数据库，确认执行导出的用户是否有EXP_FULL_DATABASE角色或至少对要导出的所有对象有SELECT权限。
   • 检查导入用户权限：在目标数据库，确认执行导入的用户是否有IMP_FULL_DATABASE角色或足够的权限（如CREATE USER, CREATE TABLE, UNLIMITED TABLESPACE等）。
   • 授权：通过远程SQL连接，使用有足够权限的用户（如SYSTEM或SYS）给执行数据泵作业的用户授予所缺的权限。

3. 如果是“空间不足”（常见ORA-01652）：

   • 检查表空间使用率：远程连接到目标库，查询表空间使用情况，可以执行类似SELECT TABLESPACE_NAME, BYTES/1024/1024 MB_USED, MAXBYTES/1024/1024 MB_MAX FROM DBA_DATA_FILES;的语句（具体查询可调整）。
   • 扩容：如果表空间已满或接近满了，需要对其进行扩容，可以执行ALTER DATABASE DATAFILE '/path/to/datafile.dbf' RESIZE ...M;来扩大数据文件，或者添加新的数据文件ALTER TABLESPACE USERS ADD DATAFILE '/path/to/new_datafile.dbf' SIZE 100M;。

4. 如果是其他奇怪错误：

   • 查询具体错误号：将日志中伴随39058出现的具体ORA错误代码（如ORA-xxxxx）复制下来，去Oracle官方支持网站（My Oracle Support）或技术论坛搜索，通常能找到针对性的解决方案。
   • 检查对象状态：在源库或目标库，查询DBA_OBJECTS视图，看看这个被跳过的对象状态是否正常（STATUS字段是否为VALID）。

第三步：修复后重新运行

在根据上述步骤找到问题并修复后（比如加了权限、扩了空间、删除了冲突表），你需要重新运行数据泵导入作业，这里有个小技巧：如果跳过的对象只是整个任务中的一小部分，你可以使用INCLUDE参数来只导入之前失败的那些对象，这样可以节省大量时间。INCLUDE=TABLE:"IN ('SKIPPED_TABLE1', 'SKIPPED_TABLE2')"。

总结一下远程排查的心得：

• 日志是第一生命线：所有答案几乎都在日志里。
• 由大到小，逐步聚焦：先通过日志确定是哪个对象，再根据伴随的错误代码确定问题类型，最后针对性解决。
• 参数是控制数据泵行为的关键：熟悉TABLE_EXISTS_ACTION, EXCLUDE, INCLUDE等常用参数，能在关键时刻帮你灵活处理问题。
• 预防优于治疗：在启动大型数据泵作业前，最好先在测试环境演练一遍，提前检查权限、空间和对象冲突可能性，能避免很多不必要的麻烦。

（引用来源：综合自DBA在处理实际ORA-39058错误时的通用排查流程和Oracle Data Pump最佳实践指南）