MYSQL數(shù)據(jù)遷移到ORACLE中碰到的亂碼問題的解決方法

165次閱讀

共計(jì) 4070 個(gè)字符，預(yù)計(jì)需要花費(fèi) 11 分鐘才能閱讀完成。

本篇內(nèi)容主要講解“MYSQL 數(shù)據(jù)遷移到 ORACLE 中碰到的亂碼問題的解決方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓丸趣 TV 小編來帶大家學(xué)習(xí)“MYSQL 數(shù)據(jù)遷移到 ORACLE 中碰到的亂碼問題的解決方法”吧!

MYSQL 字符集 UTF8,ORACLE 字符集 GBK
LINUX 5.3
MYSQL 5.1
ORACLE 9208
數(shù)據(jù)行數(shù) 1800W

基于這個(gè)數(shù)據(jù)量, 我們首先想到的是將 MYSQL 數(shù)據(jù) DUMP 到文本文件, 再用 SQLLOAD 泵進(jìn) ORACLE.

但我們在第一步 (MYSQL 數(shù)據(jù) DUMP 到文本文件,) 就出現(xiàn)了問題. 中文顯示為亂碼.

所以我們把首要問題先解決: 如何讓 MYSQL 正確地 DUMP 到文本文件?

其實(shí)這個(gè)歸根還是字符集的問題. 但在這個(gè)場景, 我們還要考慮到 MYSQL 對不同的輸出方式也有不同的字符集轉(zhuǎn)換模式.

首先來我們來看一下,DUMP 數(shù)據(jù)有多種方法:
1. set names gbk; select … into outfile /tmp/a1.txt from test.t1;
2. mysql -uroot -h227.0.0.1 –default-character-set=gbk -e select … from test.t1 /tmp/a1.txt
3. mysqldump -uroot -h227.0.0.1 –tab /tmp –fields-terminated-by= –lines-terminated-by= $$$$$ –default-character-set=utf8 test t1

創(chuàng)建測試表:
set names gbk;
CREATE TABLE `t1` (`col0` varchar(100) , `col1` varchar(100) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;
insert into t1 values (中國 , 1aaaaaa
select * from t1;

下面我們分別來看一下, 上面說的三種方法能不能正確 DUMP 中文到文本文件

1. set names gbk; select * into outfile /tmp/a1.txt from test.t1;
========================================================================
root@127.0.0.1 : (none) 15:35:26 use test;
Database changed
root@127.0.0.1 : test 15:35:27 set names gbk;
Query OK, 0 rows affected (0.00 sec)

root@127.0.0.1 : test 15:35:30 select * from t1;
+——+———+
| col0 | col1 |
+——+———+
| 中國 | 1aaaaaa |
+——+———+
1 row in set (0.00 sec)

root@127.0.0.1 : test 15:35:33 select * into outfile /tmp/a1.txt from test.t1;
Query OK, 1 row affected (0.00 sec)

root@127.0.0.1 : test 15:35:53 system cat /tmp/a1.txt
涓? 浗 1aaaaaa

root@127.0.0.1 : test 15:35:59 system hexdump /tmp/a1.txt
0000000 b8e4 e5ad bd9b 3109 6161 6161 6161 000a
000000f
========================================================================
注解: 用 MYSQL CLIENT GBK 看能正常顯示中文, 但 OUTFILE 里存的卻是 UTF8 的編碼數(shù)據(jù).
在這里猜測是:
當(dāng)數(shù)據(jù)返回給 MYSQL 客戶端的時(shí)候, 數(shù)據(jù)經(jīng)過 character_set_results=gbk 的轉(zhuǎn)換.
當(dāng)數(shù)據(jù)返回給 OUTFILE 的時(shí)候, 是直接 DUMP 數(shù)據(jù).(經(jīng)過測試,character_set_results 不管設(shè)成什么, 都不影響 OUTFILE 生成的結(jié)果)

2. mysql -e select .. /tmp/a2.txt
========================================================================
[root@PerfTestDB1 tmp]# mysql -uroot -h227.0.0.1 -N -s –default-character-set=gbk -e select * from test.t1 /tmp/a2.txt
[root@PerfTestDB1 tmp]# more /tmp/a2.txt
中國 1aaaaaa
[root@PerfTestDB1 tmp]# hexdump /tmp/a2.txt
0000000 d0d6 fab9 3109 6161 6161 6161 000a
000000d
========================================================================
注解: 在這里能正常 DUMP 出來, 是因?yàn)榉祷亟o MYSQL CLIENT 的時(shí)候, 已經(jīng)經(jīng)過 character_set_results=gbk 的轉(zhuǎn)換.
這個(gè)相當(dāng)于第一種方法里的前半部分, 直接查看(select * from t1;)

3. mysqldump (這種方式將會(huì)產(chǎn)生文件: .sql– 建表語句 .txt– 數(shù)據(jù))
========================================================================
[root@PerfTestDB1 tmp]# mysqldump -uroot -h227.0.0.1 –tab /tmp –fields-terminated-by= –lines-terminated-by= $$$$$ –default-character-set=gbk test t1
[root@PerfTestDB1 tmp]# more t1.txt
涓? 浗 1aaaaaa$$$$$
[root@PerfTestDB1 tmp]# hexdump t1.txt
0000000 b8e4 e5ad bd9b 2626 3126 6161 6161 6161
0000010 2424 2424 0024
0000015
========================================================================
注解: 不管上面的 –default-character-set 設(shè)成 GBK/UTF8/LATIN1, 導(dǎo)出的結(jié)果都是一致的.
其實(shí)這也說明這種方式也是直接將表的真實(shí)數(shù)據(jù)編碼直接 DUMP 出來, 而沒有經(jīng)過轉(zhuǎn)換.
為了進(jìn)一步證明上述的說法. 我 STRACE 了一下第 2, 第 3 兩種方法.
strace mysql -uroot -h227.0.0.1 -N -s –default-character-set=gbk -e select * from test.t1 /tmp/mysql.log
strace mysqldump -uroot -h227.0.0.1 –tab /tmp –fields-terminated-by= –lines-terminated-by= $$$$$ –default-character-set=gbk test t1 /tmp/mysqldump.log

通過查看日志文件:/tmp/mysql.log /tmp/mysqldump.log , 發(fā)現(xiàn)在 mysql.log 中. 有這么一段:
—————————————————–
munmap(0xb7f4e000, 4096) = 0
stat64(/usr/share/mysql/charsets/Index.xml , {st_mode=S_IFREG|0755, st_size=18173, …}) = 0
open(/usr/share/mysql/charsets/Index.xml , O_RDONLY|O_LARGEFILE) = 3
read(3, ?xml version= 1.0 encoding= ut …, 18173) = 18173
close(3)
—————————————————–
我想這正是 MYSQL 在做字符集轉(zhuǎn)換. 而在 mysqldump.log 中沒有找到.

再進(jìn)一步跟蹤另一種 MYSQLDUMP 備份方法(導(dǎo)成 SQL 語句).
strace mysqldump -uroot -h227.0.0.1 –default-character-set=gbk test t1 mysqldump1.log
你是不是發(fā)現(xiàn)在這里又出現(xiàn)了上面那一段? (可以搜索:/usr/share/mysql/charsets/Index.xml)

4. 小結(jié).

經(jīng)過以上的測試. 那么現(xiàn)在我們可以知道, 想要中文正確的顯示在文本文件里. 有兩種方法:
1) mysql -uroot -h227.0.0.1 -N -s –default-character-set=gbk -e select * from test.t1 /tmp/a2.txt
2) select convert(name USING gbk) into outfile /tmp/a21.txt from test.t1 ;

到此，相信大家對“MYSQL 數(shù)據(jù)遷移到 ORACLE 中碰到的亂碼問題的解決方法”有了更深的了解，不妨來實(shí)際操作一番吧！這里是丸趣 TV 網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

正文完