Oracle 資料庫字元集移轉 (Database Character Set Migration)

伴隨著組織擴張與全球化(Globalization)的需求與佈局,資料庫由特定國碼(ex:ZHT16MSWIN950)轉換到統一碼/標準萬國碼(ex:AL32UTF8)的資料庫字元集移轉 (Database Character Set Migration)就變成不可避免的趨勢. 然而,資料庫字元集移轉往往也是DBA與Programer所面臨最棘手的問題之一.

目前比較普遍使用的Unicode資料庫為AL32UTF8(變動長度1~3 bytes,增補字符集 4 bytes)與UTF8(變動長度1~3 bytes,增補字符集 2*3bytes=6bytes). 其中AL32UTF8是Oracle原廠建議採用的字元集.

另一種Unicode儲存資料的方法為使用NCHAR資料型態(NCHAR,NVARCHAR,NCLOB). 這種儲存於欄位的Unicode並不會受到底端資料庫字元集的不同而有所影響. 也就是說,資料在儲存進欄位時已經被自動編碼成Unicode. NCAHR的優點在於支援固定長度亞洲字元集(fixed-width character sets),藉此提供更好的亞洲字元資料處理效能.

NCHAR資料型態可分為兩種:AL16UTF16與UTF8. 其中AL16UTF16為系統預設的NCHAR資料型態.

移轉時最常發生的問題不外乎就是資料斷尾(Data Truncation),資料遺失(Data Loss)與資料損毀(Data Corruption). 這些問題必須在移轉前考量到,並透過嚴謹的移轉計劃(Migration Plan)來避免.

移轉的方法大致可歸納為三種:
1.使用Full Export and Import
2.使用Alter Database Character Set Statement
3.使用Alter Database Character Set Statement及選擇性的Imports

第一種方法適用在絕大部分的案例,但須特別注意資料斷尾與資料遺失的問題.

第二種是最快速移轉的方法,但也因為所須滿足該方法的前提太多,除非能確定要移轉的DB已經滿足了全部要素,不然不建議採用.

第三種方法適合於充分了解資料的分布並且所需移轉的資料僅佔用極少數的Tables時.

但不管採用哪種移轉方式,都必須兼顧到移轉後資料完整性(Data Integrity)與最少程式調整負擔(Modification of Minimum). 與前端AP開發人員良好的溝通協調是達成此目標的不二法則.