Heim >Datenbank >MySQL-Tutorial >如何解决Oracle DUL恢复clob时中文乱码问题?
本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger 的Oracle技术博客 本文链接地址: 如何解决Oracle DUL恢复clob时中文乱码问题? 闲来无聊,研究了一下Oracle DUL 恢复clob的情况,对于中文存储。这一点DUL赶ODU差距一大截。用起来
本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: 如何解决Oracle DUL恢复clob时中文乱码问题?
闲来无聊,研究了一下Oracle DUL 恢复clob的情况,对于中文存储。这一点DUL赶ODU差距一大截。用起来也很不顺手。
不过这当是无聊玩玩了,下面来说准备测试环境,本文仅供参考,不过各种Oracle数据恢复可以联系我!
++++准备测试表
[ora10g@killdb ~]$ sqlplus roger/roger ? SQL*Plus: Release 10.2.0.5.0 - Production on Sun Sep 14 03:58:10 2014 ? Copyright (c) 1982, 2010, Oracle. All Rights Reserved. ? ? Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options ? www.killdb.com>select * from test_clob; ? ID NAME ---------- ------------------------------------------- 1 我爱中国 2 我帅爆了 3 killdb.com ? www.killdb.com>desc test_clob Name Null? Type ---------------------------------------- -------- --------------------------- ID NUMBER NAME CLOB ? www.killdb.com> ? DUL> desc roger.test_clob; Table ROGER.TEST_CLOB obj#= 58448, dataobj#= 58448, ts#= 6, file#= 5, block#=835 tab#= 0, segcols= 2, clucols= 0 Column information: icol# 01 segcol# 01 ID len 22 type 2 NUMBER(0,-127) icol# 02 segcol# 02 NAME len 4000 type 112 CLOB cs 852(ZHS16GBK) LOB Segment: dataobj#= 58449, ts#= 6, file#= 5, block#=843 chunk=1 LOB Index: dataobj#= 58450, ts#= 6, file#= 5, block#=851 DUL>
将该block的数据dump,我们来看下数据实际上在block内是怎么存放的,如下:
tab 0, row 0, @0x1ee4 tl: 51 fb: --H-FL-- lb: 0x1 cc: 2 col 0: [ 2] c1 02 col 1: [44] 00 54 00 01 02 0c 80 00 00 02 00 00 00 01 00 00 00 26 a3 cd 00 18 09 00 00 00 00 00 00 08 00 00 00 00 00 01 62 11 72 31 4e 2d 56 fd tab 0, row 1, @0x1eab tl: 57 fb: --H-FL-- lb: 0x1 cc: 2 col 0: [ 2] c1 03 col 1: [50] 00 54 00 01 02 0c 80 00 00 02 00 00 00 01 00 00 00 26 a3 ce 00 1e 09 00 00 00 00 00 00 0e 00 00 00 00 00 01 00 62 00 11 00 5e 00 05 00 72 00 06 00 4e tab 0, row 2, @0x1e58 tl: 83 fb: --H-FL-- lb: 0x1 cc: 2 col 0: [ 2] c1 04 col 1: [76] 00 54 00 01 02 0c 80 00 00 02 00 00 00 01 00 00 00 26 a3 cf 00 38 09 00 00 00 00 00 00 28 00 00 00 00 00 01 00 00 00 6b 00 00 00 69 00 00 00 6c 00 00 00 6c 00 00 00 64 00 00 00 62 00 00 00 2e 00 00 00 63 00 00 00 6f 00 00 00 6d end_of_block_dump
这里我们以第一行的数据为例,我们知道,我第一行的数据其实只要4个汉字,为什么dump的col 1这么长呢?
前面的84个byte其实的lob header的信息,后面的8个bytes才是实际的lob data。可以看到这不是我们以往
说知道的16进制,而是unicode编码。如果你去对照unicode的中文编码表,这8个byte正好表示我们的4个汉字。
首先我们来测试dul,正常情况下,你会发现dul抽取的信息直接sqlldr加载之后,中文都是乱码。
####不经过转码的情况
--unload table数据 DUL> unload table roger.test_clob; . unloading (index organized) table LOB01400353 DUL: Warning: Recreating file "LOB01400353.ctl" 0 rows unloaded Preparing lob metadata from lob index Reading LOB01400353.dat 0 entries loaded and sorted 0 entries . unloading table TEST_CLOB DUL: Warning: Recreating file "ROGER_TEST_CLOB.ctl" 3 rows unloaded DUL> ? --创建相同表结构的测试表 www.killdb.com>create table test_clob_1 as select * from test_clob where 1=0; ? Table created. ? www.killdb.com> ? --修改ctl文件 修改ROGER_TEST_CLOB.ctl中的表名称,将内容修改为如下: load data CHARACTERSET ZHS16GBK infile 'ROGER_TEST_CLOB.dat' insert into table "ROGER"."TEST_CLOB_1" fields terminated by whitespace ( "ID" CHAR(1) enclosed by X'7C' ,"NAME" LOBFILE(LF58449) TERMINATED BY EOF NULLIF LF58449 = 'NONE', LF58449 FILLER CHAR(20) enclosed by X'7C' ) 说明:其实就是替换了一下表名称. ? --将数据加载到test_clob_1 [ora10g@killdb dul]$ sqlldr roger/roger control=ROGER_TEST_CLOB.ctl ? SQL*Loader: Release 10.2.0.5.0 - Production on Sun Sep 14 04:11:03 2014 ? Copyright (c) 1982, 2007, Oracle. All rights reserved. ? Commit point reached - logical record count 3 [ora10g@killdb dul]$ ? --验证test_clob_1 的数据 www.killdb.com>show user USER is "ROGER" www.killdb.com>select * from test_clob_1; ? ID NAME ---------- --------------------------------------------------------- 1 br1N-V 2 b^rN 3 ? www.killdb.com>
我们可以看到,几乎全是乱码。
开始我将unload产生的lob文件用UE打开,以及对比发现是以unicode的方式存在的,因此我们需要转码才行。
#### 经过转码的测试
使用Linux自带的iconv工具进行转码,该工具非常强大,支持多种编码,如下:
[ora10g@killdb dul]$ iconv -l|grep GB CN-GB// CSGB2312// CSISO58GB1988// EBCDIC-CP-GB// GB// GB2312// GB13000// GB18030// GBK// GB_1988-80// GB_198880// ISO646-GB// [ora10g@killdb dul]$ iconv -l|grep UCS 10646-1:1993/UCS4/ CSUCS4// ISO-10646/UCS2/ ISO-10646/UCS4/ UCS-2// UCS-2BE// UCS-2LE// UCS-4// UCS-4BE// UCS-4LE// UCS2// UCS4// ? [ora10g@killdb dul]$ mv LF0002.lob LF0002.lob.old [ora10g@killdb dul]$ iconv -f UCS-2BE -t gb2312 LF0002.lob.old > LF0002.lob
加载数据之前,先将表truncate清空:
www.killdb.com>truncate table test_clob_1; ? Table truncated. ? ++++加载数据 [ora10g@killdb dul]$ sqlldr roger/roger control=ROGER_TEST_CLOB.ctl ? SQL*Loader: Release 10.2.0.5.0 - Production on Sun Sep 14 04:27:43 2014 ? Copyright (c) 1982, 2007, Oracle. All rights reserved. ? Commit point reached - logical record count 3 [ora10g@killdb dul]$ ? ++++ 验证test_clob_1数据 ? www.killdb.com>select * from test_clob_1; ? ID NAME ---------- -------------------------------------------------------- 1 br1N-V 2 我帅爆了 3 ? www.killdb.com>
我们可以看到,经过处理的第2条数据正常的显示了。
可见,结合iconv工具,Oracle DUL可以完美的支持clob的中文恢复。
No related posts.
本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客 本文链接地址: 如何解决Oracle DUL恢复clob时中文乱码问题? 闲来无聊,研究了一下Oracle DUL 恢复clob的情况,对于中文存储。这一点DUL赶ODU差距一大截。用起来也很不顺手。 不过这当是无聊玩玩了,下面来说准备测试环境,本文仅供参考,不过各种Oracle数据恢复可以联系我! ++++准备测试表 [ora10g@killdb ~]$ sqlplus roger/roger SQL*Plus: Release 10.2.0.5.0 - Production on Sun Sep 14 03:58:10 2014 Copyright (c) 1982, 2010, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production With [...]