GaussDB(DWS) GDS導入容錯詳解（Gaussdbdws8.1客戶端安裝步驟）

前言

GaussDB(DWS)作為一款數倉系統經常面臨大批量數據的導入導出，并且需要在短時間內處理上百TB的數據，GaussDB針對這種場景提供了一款高性能的導入導出服務工具GDS(GaussDB data server)。本主要面向已經對GDS有了一定基礎的同學，如果對GDS不是非常了解可以先查閱GaussDB(DWS)的官方文檔。

在海量數據的導入場景下由于用戶數據源的多樣性會降低數據的質量，因此就需要GaussDB(DWS)需要具備一定的數據容錯能力，比如對非法字符的替換，字符集轉換轉換的容錯，多余字段的忽略，字段缺失補齊等等。本文將會從最基礎的計算機知識和一個一個的例子開始，讓大家慢慢的理解GaussDB(DWS)的容錯原理。

1.1. 如何判斷文件的字符集編碼?

要想回答清楚這個問題，需要從很基礎的概念說起，比如字符集是什么,什么是字符，但是直觀起見我就用一個例子來幫助大家理解，來看下們最常用的編輯器工具"vim"是如何處理字符，字符集問題的。

1. 編寫一個hello.c程序,gcc hello.c -o hello 生成一個hello文件。

#include int main() { printf("hello world."); }

2. vim打開hello

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@e^D@^@^@^@^@^@D^D@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^L^@^@^@^@^@^@^@è^C@^@^@^@^@^@^M^@^@^@^@^@^@^@′^E@^@^@^@^@^@^Y^@^@^@^@^@^@^@^P^N`^@^@^@^@^@^[^@^@^@^@^@^@^@^H^@^@^@^@^@^@^@^Z^@^@^@^@^@^@^@^X^N`^@^@^@^@^@^\^@^@^@^@^@^@^@^H^@^@^@^@^@^@^@?t?o^@^@^@^@<98>^B@^@^@^@^@^@^E^@^@^@^@^@^@^@^X^C@^@^@^@^@^@^F^@^@^@^@^@^@^@?^B@^@^@^@^@^@ ^@^@^@^@^@^@^@?^@^@^@^@^@^@^@^K^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@^U^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^@^@^@^@^@^@^@^P`^@^@^@^@^@^B^@^@^@^@^@^@^@0^@^@^@^@^@^@^@^T^@^@^@^@^@^@^@^G^@^@^@^@^@^@^@^W^@^@^@^@^@^@^@<98>^C@^@^@^@^@^@^G^@^@^@^@^@^@^@<80>^C@^@^@^@^@^@^H^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@t??o^@^@^@^@`^C@^@^@^@^@^@???o^@^@^@^@^A^@^@^@^@^@^@^@e??o^@^@^@^@X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@(^N`^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^F^D@^@^@^@^@^@^V^D@^@^@^@^@^@^@^@^@^@GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-36)^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^A^@8^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^B^@T^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^C^@t^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^D^@<98>^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^E^@?^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^F^@^X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^G^@X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^H^@`^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@ ^@<80>^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@ @ @ @ @ @ @ @ @ @ @ @ "hello" [noeol][converted] 4L, 8799C

有經驗的同學看到文件中大量的^@時候就會說，這是一個二進制文件，但是我們又是如何判斷說這是一個二進制文件的呢？

3. vim 命令模式中使用:set fileencoing 可以查看vim在當前的環境下提供了哪些用來處理數據的字符集。

@^E^@^@^@^@^@^@^@^X^C@^@^@^@^@^@^F^@^@^@^@^@^@^@?^B@^@^@^@^@^@ ^@^@^@^@^@^@^@?^@^@^@^@^@^@^@^K^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@^U^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^@^@^@^@^@^@^@^P`^@^@^@^@^@^B^@^@^@^@^@^@^@0^@^@^@^@^@^@^@^T^@^@^@^@^@^@^@^G^@^@^@^@^@^@^@^W^@^@^@^@^@^@^@<98>^C@^@^@^@^@^@^G^@^@^@^@^@^@^@<80>^C@^@^@^@^@^@^H^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@t??o^@^@^@^@`^C@^@^@^@^@^@???o^@^@^@^@^A^@^@^@^@^@^@^@e??o^@^@^@^@X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@(^N`^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^F^D@^@^@^@^@^@^V^D@^@^@^@^@^@^@^@^@^@GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-36)^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^A^@8^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^B^@T^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^C^@t^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^D^@<98>^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^E^@?^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^F^@^X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^G^@X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^H^@`^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@ ^@<80>^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@ @ @ @ @ @ @ @ @ @ @ @ fileencodings=ucs-bom,utf-8,latin1

可以看到當前linux語言環境下vim可以選用ucs-bom(windos為多字節字符提供的bom頭機制)，utf8,和latin1字符集來識別文件中的數據。

4. 繼續在vim命令模式中使用:set fileencoding 可以查看當前vim最終選擇了哪個字符集來編碼數據。

^@^@^@^@è^C@^@^@^@^@^@^M^@^@^@^@^@^@^@′^E@^@^@^@^@^@^Y^@^@^@^@^@^@^@^P^N`^@^@^@^@^@^[^@^@^@^@^@^@^@^H^@^@^@^@^@^@^@^Z^@^@^@^@^@^@^@^X^N`^@^@^@^@^@^\^@^@^@^@^@^@^@^H^@^@^@^@^@^@^@?t?o^@^@^@^@<98>^B@^@^@^@^@^@^E^@^@^@^@^@^@^@^X^C@^@^@^@^@^@^F^@^@^@^@^@^@^@?^B@^@^@^@^@^@ ^@^@^@^@^@^@^@?^@^@^@^@^@^@^@^K^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@^U^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^@^@^@^@^@^@^@^P`^@^@^@^@^@^B^@^@^@^@^@^@^@0^@^@^@^@^@^@^@^T^@^@^@^@^@^@^@^G^@^@^@^@^@^@^@^W^@^@^@^@^@^@^@<98>^C@^@^@^@^@^@^G^@^@^@^@^@^@^@<80>^C@^@^@^@^@^@^H^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^X^@^@^@^@^@^@^@t??o^@^@^@^@`^C@^@^@^@^@^@???o^@^@^@^@^A^@^@^@^@^@^@^@e??o^@^@^@^@X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@(^N`^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^F^D@^@^@^@^@^@^V^D@^@^@^@^@^@^@^@^@^@GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-36)^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^A^@8^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^B^@T^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^C^@t^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^D^@<98>^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^E^@?^B@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^F^@^X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^G^@X^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^H^@`^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@ ^@<80>^C@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@ @ @ @ @ @ @ @ @ @ @ @ fileencoding=latin1

可以看到vim最終選擇了latin1來編碼數據。其實vim 會順序的從fileencodings中選擇字符集，首先選擇bom頭發現編碼失敗，然后嘗試使用utf8字符集編碼發現還是失敗，最后無奈之下只能使用latin1這種萬能編碼，總之先到先得。當前我使用linux系統語言環境字符集 LANG=en_US.UTF-8如果fileencodings中的編碼全都編碼失敗，則會選擇linux操作系統語言環境的字符集UTF8強制編碼,編碼失敗則對非法字符做容錯處理。

1.1.2. 回過頭再看文件中的'^@'是什么

通過:help digraph-table命令可以查看vim的不可見字符的替換表，也就是說vim的屏顯功能在實現的時候會將‘00’替換成兩個可見字符‘^@’，所以并不是說包含"^@"的文? ? 件就是二進制文件。

char digraph hex dec official name ^@ NU 0x00 0 NULL (NUL) ^A SH 0x01 1 START OF HEADING (SOH) ^B SX 0x02 2 START OF TEXT (STX) ^C EX 0x03 3 END OF TEXT (ETX) ^D ET 0x04 4 END OF TRANSMISSION (EOT) ^E EQ 0x05 5 ENQUIRY (ENQ) ^F AK 0x06 6 ACKNOWLEDGE (ACK) ^G BL 0x07 7 BELL (BEL) ^H BS 0x08 8 BACKSPACE (BS) ^I HT 0x09 9 CHARACTER TABULATION (HT) ^@ LF 0x0a 10 LINE FEED (LF) ^K VT 0x0b 11 LINE TABULATION (VT) ^L FF 0x0c 12 FORM FEED (FF) ^M CR 0x0d 13 CARRIAGE RETURN (CR) digraph.txt.gz [Help][RO]

總結：所有的文件本質上都是一串二進制數據流，根本沒有什么方絕對的方法可以判斷一個文件的內容是什么字符集編碼的，即使強如vim也只能嘗試著去判斷文件的編碼，并順其自然。我們沒有什么好的方法去判斷一個文件確切的是什么編碼，因為文件的編碼取決于數據是否滿足相應的字符集編碼。

2.1. 非法字符和亂碼

繼續舉例，現有一串字節流："e4b8bc4042" 如果用utf8字符集編碼則得到的結果是“丼@B”,如果用GBK編碼則得到的是“涓粿B”，通過不同的字符集編碼都能得到合法的字符串，那么哪一個叫亂碼呢？

亂碼：數據本身可以被多種字符集規則識別，校驗，只是未按照預期的規則對數據編碼。

如果上面的字節流稍加修改，"e4b8bc4042"->"e4b8bc",如果用utf8編碼則得到的是“丼”，如果用GBK編碼則得到的是"涓"和一個非法字符"bc".

"bc"被認定為非法字符的原因是bc不能被GBK字符集規則識別，校驗，‘bc’只是GBK字符的前半部分屬于半個GBK字符。關于GBK的編碼規則下面會做介紹。

非法字符：在GaussDB(DWS)中不滿足指定的字符集規則或者不能轉換成目標字符集的字符被稱作非法字符。不能轉換這個很好理解，我們都知道UTF8所包含的字符數遠遠大于GBK做能包含的字符數，因此肯定有某些字符包含在UTF8中但不包含在GBK中，比如： "?"它雖然不是一個GBK字符但是它一個utf8字符，因此對于GBK來說他就是一個非法字符。同時GaussDB(DWS)中還有有一個特殊的非法字符"0x00"

所以應用程序程序本身不可能去幫用戶解決亂碼的問題，因為在應用程序看來亂碼也是一串合法的數據，解決亂碼問題需要用戶清楚自己文件內容的字符集編碼，但是應用程序可以盡可能的去幫助用戶解決或者規避非法字符問題。

2.2. 非法字符和亂碼處理

前面已經說了亂碼本質上是不是數據的問題，只是因為選擇錯了字符集編碼，但是一般程序可以對非法字符做一定的處理。我們還是先看下vim是如何處理非法字符的，以便于理解GaussDB(DWS)的處理方式。

前置：

1. linux 環境，語言環境 LANG=en_US.UTF-8

2. ~/.vimrc中添加? set fileencodings=""? ##強制vim不要從fileencodings中選擇字符集編碼數據，當fileencodings為空時會選擇當前語言環境的字符集作為數據編碼的字符集。

3. cat utf8.txt 添加內容并保存

中華人民共和國

4. vim -b utf8.txt? ?將“國”的十六進制“e5 9b bd”認為修改為非法的UTF8字符 “e5 ff bd”，utf8的編碼規則下面有說明。? ? ?:%!xxd -r 保存。

5. vim utf8.txt? 查看更改后的數據

中華人民共和???

顯然后面的非法字符‘e5 ff bd’的每一個字節都被替換成"?"，這也正是vim的容錯處理，事實上GaussDB(DWS)也是這么做的。

例如”0x00“在GaussDB(DWS) 中是一個非法字符。當用戶設置compatible_illegal_chars=true時會將“0x00”替換成空格，將其他的非法字符替換成"?"否則將會報錯

invalid byte sequence for encoding "UTF8": 0x00

2.3. GaussDB(DWS)導入數據時的字符編碼處理

GaussDB本質上也是一個應用程序因此和vim一樣也會有字符和字符集的處理功能，但是出于功能和性能的考慮GaussDB(DWS)肯定不能像編輯器那樣遍歷字符集列表選擇字符集。 GaussDB在使用GDS導入數據時候會讓用戶提供導入文件的字符集編碼，如果用戶沒有提供，GaussDB(DWS)會認為用戶數據的字符編碼和數據庫的字符編碼是一致的。

目前GaussDB(DWS)數據庫只支持庫級別的編碼設置，不能對表單獨設置字符集，共支持如下四種編碼方式：UTF8、GBK、Latin1、SQL_ASCII按導入文件字符編碼方式跟數據庫字符編碼方式的組合，正交驗證各種編碼方式下，非法字符是否能容錯導入

導入文件字符編碼方式

數據庫字符編碼方式

UTF8

GBK

Latin1

SQL_ASCII

UTF8

UTF8編碼校驗

UTF8轉換至GBK

UTF8轉換至Latin1

UTF8編碼校驗

GBK

GBK轉換至UTF8

GBK編碼校驗

GBK轉換至Latin1

GBK編碼校驗

Latin1

除0x00外均合法

不兼容

不校驗/除0x00外均合法

除0x00外均合法

SQL_ASCII

UTF8編碼校驗

GBK編碼校驗

除0x00外均合法

不校驗/除0x00外均合法

注：表中紅色字體為8.0.0.5以下版本規格。

SQL_ASCII字符集

概述：ASCII的擴展字符集，8bit，可以存儲除0x00外的任意字節流(GaussDB(DWS)的萬能編碼)

UTF8字符集

概述：Unicode字符集具體的編碼實現，1-4字節變長字節編碼

非法取值范圍

1字節：[0x80, 0xc2]或者(0xf4, 0xff]；

2字節：1字節為0xe0并且（2字節處于[0x00, 0xa0)或者(0xbf, 0xff])；

1字節為0xed并且（2字節處于[0x00, 0x80)或者(0x9f, 0xff])；

1字節為0xf0并且（2字節處于[0x00, 0x90)或者(0x8f, 0xff])；

1字節為0xf4并且（2字節處于[0x00, 0x80)或者(0xbf, 0xff])；

2字節處于[0x00, 0x80)或者(0xbf, 0xff]

3字節：3字節處于[0x00, 0x80)或者(0xbf, 0xff]；

4字節：4字節處于[0x00, 0x80)或者(0xbf, 0xff]。

Gaussdb(DWS)GBK字符集

概述：國家簡體中文字符集，使用2字節表示中文等字符

有效值范圍：高字節從81到FE，低字節從40到FE，剔除xx7F一條線。

建議： GaussDB(DWS)支持GBK字符集編碼，雖然GBK字符集比UTF8編碼占用的存儲空間小，但是GBK字符集編碼的字符數遠遠小于UTF8, 如果用戶將UTF8的數據導入GBK的庫會存在數據丟失的風險，因此仍然不建議使用GBK字符集作為數據庫編碼。

3.1. GaussDB(DWS)在GDS導入數據的時候實現自動的進行編碼轉換

3.2. GaussDB(DWS) GDS導入自動轉換過程

3.2.1. 數據讀取

DN讀取原始數據d6d0b9fa。

3.2.2. GBK編碼校驗

當外表參數和數據庫參數不同時候數據庫會對讀取的數據做編碼校驗，GBK字符集的"中"首字節為'd6' 大于'7f'說明將要解析的字符為多字節字符，

且在GBK字符集規定的高字節范圍(81->fe)內，說明該多字節字符的長度一定為2,因此還需要繼續向下讀取一個字節'd0',該字節范圍在GBK字符集規定的低字節范圍(00->fe)內,說明該多字節字符是一個合法的GBK字符。

3.2.3 編碼轉換

GaussDB(DWS)內部定義了很多編碼映射文件，其中就包含了GBK和utf8的映射關系，然后從GBK->utf8的map文件中找到"d6d0"這個key就可以找到對應的UTF8的十六進制編碼:"e4b8ad",最后將轉換后的UTF8字符寫入數據庫中且該字符占用了3個字節。

4. GaussDB(DWS)容錯措施

4.1. 數據錯入錯出

數據庫和GDS的外表參數都設置成sql_ascii編碼。sql_ascii字符集編碼也叫錯入錯出編碼，當數據庫設置為sql_ascii編碼后數據庫不會對數據進行編碼但是會校驗數據中是否包含0x00，其他字符都會原樣入庫。

latin1和sql_ascii 都屬于單字節字符編碼，雖然可以給用戶帶來方便，但是強烈不建議用戶使用這一類編碼，因為沒有了數據自身的校驗約束機制，一旦某張表被寫入了多種編碼的數據，這張表的可維護性將變得極低。

4.2. 非法字符替換

當用戶設置compatible_illegal_chars=true時會將非法字符“0x00”替換成空格，否則會產生如下報錯

invalid byte sequence for encoding "UTF8": 0x00

當用戶設置compatible_illegal_chars=true時GaussDB(DWS)會將不能被識別的字符和不能轉換的字符替換成"?", 否則也會報錯

## 不能被轉換時 ERROR: character with byte sequence 0xe4 0x99 0x91 in encoding "UTF8" has no equivalent in encoding "GBK" ## 不能被識別時 invalid byte sequence for encoding "UTF8": 0xe5 0xff 0xbd

4.3. 錯誤表機制

錯誤表機制只會在數據導入時生效，也就是說只有執行insert into select * from "GDS外表" 時錯誤表機制才會生效，單純的查詢外表是不會觸發錯誤表機制的。

數據導入過程中發生的錯誤，一般分為數據格式錯誤和非數據格式錯誤。

數據格式錯誤包括編碼編碼轉換錯誤，不能識別的編碼，和非法字符，多列少列，數據類型錯誤，非空約束，唯一約束，字段過長等等。

在創建外表時，通過設置參數“LOG INTO error_table_name”，將數據導入過程中出現的數據格式錯誤信息寫入指定的錯誤信息表error_table_name中。您可以通過以下SQL，查詢詳細錯誤信息。

1

postgres=# SELECT * FROM error_table_name;

錯誤信息表結構如表1所示。

列名稱

類型

描述

nodeid

integer

報錯節點編號。

begintime

timestamp with time zone

出現數據格式錯誤的時間。

filename

character varying

出現數據格式錯誤的數據源文件名。

rownum

bigint

在數據源文件中，出現數據格式錯誤的行號。

rawrecord

text

在數據源文件中，出現數據格式錯誤的原始記錄。

detail

text

詳細錯誤信息。

非數據格式錯誤

對于非數據格式錯誤，一旦發生將導致整個數據導入失敗。您可以根據執行數據導入過程中，界面提示的錯誤信息，幫助定位問題，處理。

根據獲取的錯誤信息，請對照下表，處理數據導入錯誤。

錯誤信息

原因

解決辦法

missing data for column "r_reason_desc"

數據源文件中的列數比外表定義的列數少。

對于TEXT格式的數據源文件，由于轉義字符（\）導致delimiter（分隔符）錯位或者quote（引號字符）錯位造成的錯誤。

示例：目標表存在3列字段，導入的數據如下所示。由于存在轉義字符“\”，分隔符“|”被轉義為第二個字段的字段值，導致第三個字段值缺失。

BE|Belgium\|1

由于列數少導致的報錯，選擇下列辦法解決：

在數據源文件中，增加列“r_reason_desc”的字段值。

在創建外表時，將參數“fill_missing_fields”設置為“on”。即當導入過程中，若數據源文件中一行數據的最后一個字段缺失，則把最后一個字段的值設置為NULL，不報錯。

對由于轉義字符導致的錯誤，需檢查報錯的行中是否含有轉義字符（\）。若存在，建議在創建外表時，將參數“noescaping”（是否不對'\'和后面的字符進行轉義）設置為true。

extra data after last expected column

數據源文件中的列數比外表定義的列數多。

在數據源文件中，刪除多余的字段值。

在創建外表時，將參數“ignore_extra_data”設置為“on”。即在導入過程中，若數據源文件比外表定義的列數多，則忽略行尾多出來的列。

invalid input syntax for type numeric: "a"

數據類型錯誤。

在數據源文件中，修改輸入字段的數據類型。根據此錯誤信息，請將輸入的數據類型修改為numeric。

null value in column "staff_id" violates not-null constraint

非空約束。

在數據源文件中，增加非空字段信息。根據此錯誤信息，請增加“staff_id”列的值。

duplicate key value violates unique constraint "reg_id_pk"

唯一約束。

刪除數據源文件中重復的行。

通過設置關鍵字“DISTINCT”，從SELECT結果集中刪除重復的行，保證導入的每一行都是唯一的。

1

postgres=# INSERT INTO reasons SELECT DISTINCT * FROM foreign_tpcds_reasons;

value too long for type character varying(16)

字段值長度超過限制。

在數據源文件中，修改字段值長度。根據此錯誤信息，字段值長度限制為VARCHAR2(16)。

4.4. conflict_delimiter參數解決字段分割符被非法字符"感染"

conflict_delimiter 參數解決源數據中因為某種原因只包含了多字節字符的前半部分,導致該半個字節和分隔符被編碼成一個字符導致的數據格式錯誤

例如：假設有一行GBK數據"3|+|膢+|20191212"要被導入到UTF8的數據庫，用戶自定義的字段分割符為"|+|"。

這行GBK數據和十六進制對應關系如下

33 7C 2B 7C C4 7C 2B 7C 323031393132313 ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ 3 | + | ** | + | 20191212

當導入UTF8數據庫時，數據庫會發生如下轉換。

GBK -> UTF8 33->33 (3) 7C->7C (|) 2B->2B (+) 7C->7C(|) C47C-> E886A2(膢) 2B->2B(+) 7C->7C(|) 323031393132313-> 20191212

由于用戶定義的字段分割符號為"|+|"，因此對改行數據分割后獲取的數據是3，膢+|20191212,

實際上用戶可能要獲得的是3，？,20191212。

"膢" 這個字符其實是一個用戶不期望的半個字符，和用戶定義的分割符“|+|”中的“|”產生了沖突，導致數據錯亂或者導入失敗。

如果用戶想要忽略這種字符可以使用conflict_delimiterr配合compatible_illegal_chars參數將“C4”這個半個GBK字符準換成“？”導入UTF8數據庫。

數據倉庫服務 GaussDB(DWS) 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。