【发布时间】:2023-04-10 12:26:01
【问题描述】:
可以使用 Oracle 数据泵导入工具 (IMPDP.EXE) 使用 REMAP_SCHEMA 选项将一个模式导入另一个模式。但是,存在一个问题,即未正确重新映射触发器。这导致根本没有创建触发器,并出现如下错误:
ORA-39083: Object type TRIGGER failed to create with error: ORA-00942: table or view does not exist Failing sql is: CREATE TRIGGER "**NEW_SCHEMA**"."METER_ALARMS_BI" BEFORE INSERT ON
**OLD_SCHEMA**.METER_ALARMS ...
这是因为创建 SQL 仍然引用 OLD_SCHEMA。它确实在 Oracle 文档中说:
映射可能不是 100% 完整,因为有一定的 架构引用 Import 不是 能够找到。例如, 导入将找不到架构引用 嵌入体内 类型、视图的定义, 程序和包。
恕我直言,这是甲骨文的一种逃避,但这是另一个讨论!
根据 Oracle Metalink note 750783.1,解决方法是:
- 创建一个 SQLFILE 以包含相关的 DDL 命令:
impdp system/****** directory=test_dp
DUMPFILE=export_schemas.dmp
remap_schema=u1:u2 sqlfile=script.sql
- 从写入的 SQLFILE 中提取受影响的 DDL 并更正 架构参考。然后手动执行命令。
这不是一个好方法,尤其是当您有许多失败的对象并且想要自动化组合多个模式以进行数据库现场升级的过程时。
有没有人找到更好的方法来做到这一点?如果要在现场使用,我需要一个必须 100% 可靠的解决方案。我可以解析生成的 SQL 文件,但可以 100% 正确吗?有没有办法拦截由 IMPDP 执行的 CREATE SQL 语句并在导入时即时纠正它?可以直接修补 DMP 文件吗?
【问题讨论】:
-
我开始写这个作为答案,但实际上更多的是评论 - 我想不出有什么好的理由将模式的名称作为对象限定符包含在模式拥有的另一个对象中.我不清楚您对正在升级的数据库有什么控制权,但我会投票支持一次性清理这些引用以从源头上消除问题。在 DataPump 之前 (exp/imp) 的日子里,我直接修改了 .dmp 文件几次没有问题,但没有查看更新的格式。显然,如果您这样做,就 Oracle 而言,您只能靠自己。
-
注意点:我们正在处理一些将被清理的遗留对象,但即使是无所有者模式,IMPDP 的 REMAP_SCHEMA 仍然无法与触发器一起正常工作。是的,我还直接“修补”了 DMP 文件以重新映射架构,但是我发现使用 EXP 而不是 EXPDP 创建的 DMP 文件时问题较少。
-
按照 Oracle 的建议,使用 SQLFILE 选项生成由 IMPDP 执行的 SQL 在使用 SQL*Plus 运行时也会出现问题: - 存储过程 cmets 中的随机 cr/lf,给出“ORA-00933: SQL 命令未正确结束”等 - 生成的 SQL 对于视图来说太长,给出“SP2-0027:输入太长(> 2499 个字符)- 忽略行”。
-
确实应该有适当的解决办法
标签: oracle schema remap ora-00942 impdp