Expdp使用version参数时,报ORA-39373
某天晚上,同事在使用数据泵进行数据迁移的过程中遇到点问题,简要记录之。
1、概述
同事需要将一套19C数据库中的数据迁移到COMPATIBLE=12.1.0的数据库中,在使用数据泵导出的命令中添加了VERSION=12.1.0选项。在导出的日志中有几条ORA-39373报错信息。具体日志如下所示:
ORA-39373: cannot export SYSTEM_GRANT: ….. to version 12.1.0 due to long identifiers ORA-39373: cannot export SYSTEM_GRANT: ….. to version 12.1.0 due to long identifiers ORA-39373: cannot export INDEX_STATISTICS to version 12.1.0 due to long identifiers |
2、从报错的信息可以看出,由于指定了导出的版本(VERSION=12.1.0),而一些标识符太长,所以无法导出,SYSTEM_GRANT这个关键字,看样子是系统权限这部分的内容;INDEX_STATISTICS应该是索引的统计信息。
3、同事担心这个报错是否会导致迁移的数据不一致,这些报错其实可以在数据迁移后手动处理,也不会造成业务数据的不一致。数据迁移完成后,对比两个库中业务用户的系统权限部分,查看目标端的业务用户缺少哪些系统权限,手动赋予这些系统权限即可。而索引的统计信息,这本来就是需要在数据迁移完成后,手动重新收集的。
4、这个问题在MOS文章:12.2 DataPump Export (EXPDP) Using a Lower Export Client Fails Due To ORA-39373 (Doc ID 2369249.1)中也有说明(In 12.2 Oracle database, the maximum length of identifiers is increased to 128 bytes for most identifiers, up from 30 bytes in previous releases.)。MOS中的解决方案是对超过30个字符的数据对象进行重命名,然后重新导出。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· DeepSeek在M芯片Mac上本地化部署