【发布时间】:2015-10-09 16:43:56
【问题描述】:
我一直在尝试将 db2 中的表从一个外部源导出到另一个,到目前为止,我注意到在尝试将其导入源表时出现错误。
我在一个 shell 脚本上使用它:
myDate=$(date +"%Y%m%d%I%M")
myPath=/tmp/test
myDataSource="external"
myTableName=tableSchema.sourceTable
db2 +w -vm "export to $myPath/$myDataSource.$myTableName.$myDate.ixf of ixf
messages $myPath/$myDataSource.$myTableName.$myDate.ixf.xmsg
SELECT * from $myTableName"
经过进一步调查,似乎插入了一个奇怪的字符“▒”。我检查了来源,没有任何奇怪的字符。所以在检查细节后我发出了这个命令:
select *
from SYSIBM.SYSCOLUMNS
where
tbcreator = 'SOURCESCHEMA'
and tbname = 'SOURCETABLE'
for fetch only with ur;
这表明源列上的 CCSID 是 37。我在目标架构上做了同样的事情,列的 CCSID 是 1208。
当我尝试再次导出表时,强制它转换为 CCSID 1208 添加 由 codepage=1208 修改:
db2 +w -vm "export to $myPath/$myDataSource.$myTableName.$myDate.ixf of ixf
modified by codepage=1208
messages $myPath/$myDataSource.$myTableName.$myDate.ixf.xmsg
SELECT * from $myTableName"
这会导致脚本工作,但我收到以下警告:
SQL3132W The character data in column "COLUMN" will be truncated to size "4".
所述列在源和目标上的大小相同,但似乎由于 CCSID 我需要更改目标上的大小(我无法更改源上的任何内容并更改目标上的 CCSID会破坏目标)所以,我的问题是:
- 如何根据编码计算每个 varchar/char 列所需的大小,例如 CCSID 37 上的 varchar(4) 是否需要 varchar(5) 来保存 CCSID 1208 的值?
-
是否有可能做类似的事情:
选择 CAST(COLUMN as VARCHAR(12) CCSID 1208)——对于所有列 来自 tableSchema.sourceTable;
所以我不会丢失这些字符串的任何部分。
- 数字呢?
谢谢!
【问题讨论】:
-
涉及到什么平台和版本的DB2?对 CCSID 37 (US EBCDIC) 的引用导致怀疑至少有一个是大型机 (z/OS) 或中型机 (IBM i)。 CCSID 1208 是 unicode (UTF-8)。所以它是单字节,不知道为什么会发生截断。源和目标中的列是如何定义的?您使用什么工具来查看“古怪的角色”?最后,带有奇怪字符的数据的实际十六进制值是多少?
-
嘿@Charles,所以在源代码中它似乎是 db2 版本 10,而目标是 9.7。两台服务器具有相同的列定义(varchar 大小),目标是(我相信)Power7。奇怪的字符在十六进制编辑器上显示为“a0”,在我导出 IXF 文件之前,我可以在十六进制中看到它。要查看我使用字符串
| 的字符。 grep "字符附近的值" 有帮助吗? -
在源机器上,使用SQL中的HEX(problem_column)函数,显示整列的十六进制值。
标签: db2