ASCII dmp导入Oracle Unicode库的字符集适配、字段截断及定义保留问题咨询

字符集变更流程中导入能否规避字符串截断 #

直接给结论：在数据库字符集变更的流程里直接执行这类dmp导入，完全没法自动规避字符串截断问题。

• 截断的根源是两端字符集的存储逻辑差：源端的WE8ISO8859P1、IW8ISO8859P8都是单字节编码，单个字符固定占1字节；目标库AL32UTF8是变长多字节编码，带重音的西欧字母、希伯来语字符这类非ASCII内容，在目标库里单个就要占2~3字节。
• Oracle的原生导入工具（不管是老版exp/imp还是新版expdp/impdp），默认只会对dmp里的实际数据做字符集映射转换，不会自动给目标表的字段扩长度。打个比方：源端单字节集下一个10字节长度的VARCHAR2字段，存满10个希伯来语字符的话，转到AL32UTF8之后要占20~30字节，远超字段本身的长度上限，直接就会触发截断报错。
• 就算你操作的时候，先临时把目标库的字符集改成和源端一致、导完再切回AL32UTF8，也白搭：切字符集的工具只会把库里已经存的内容做映射转换，根本不会修改字段的长度定义，后续写多字节内容的时候还是会因为长度不够被截断。

导入后varchar2(10)的字段定义会怎么变 #

直接给结论：走标准无自定义参数的导入流程，目标库会100%保留源端的原始字段定义，绝不会自动改成varchar2(10 CHAR)。

• 源端没显式指定长度语义的varchar2(10)，默认就是BYTE长度语义（按字节算长度），这个定义完完整整存在dmp的表元数据里。导入工具建目标表的时候，会直接读这些元数据，生成和源端一模一样的varchar2(10 BYTE)字段，根本不会自动给你改成CHAR语义。
• 只有两种特殊情况会让长度语义变样：
  • 目标库提前开了全局初始化参数NLS_LENGTH_SEMANTICS=CHAR，而且导入的时候没硬套dmp里的元数据长度定义，这时候新建的字段才会默认用CHAR语义；
  • 导入之前提前手动改过建表的SQL脚本，把字段定义改了，不然原生导入逻辑不会做这类改写。

实操踩坑提醒 #

• 别指望导入流程自动帮你适配截断问题，正确的规避方式是导入前先给所有字符串字段提前扩容：把原来单字节语义的字段，按AL32UTF8下单字符最大占用2~3倍的系数算扩容长度，或者直接统一改成CHAR长度语义，匹配原库的最大字符存储数就行。
• 导完之后可以查数据字典，批量对比所有VARCHAR2字段的实际存储峰值和定义长度的差值，有溢出风险的提前改长度，省得后面跑业务的时候报错。

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