วิธีการ Migrate Character Set ที่เหมาะสม (ตอนที่ 2, ตอนจบ)

(แปลจากบางส่วนของ “Character Set Migration Best Practices", An Oracle White Paper January2005)

การแปลง และสิ่งที่ต้องทำหลังจากการแปลง
วิธีการต่าง ๆ ในการ Migrate
Oracle ได้เตรียมคำสั่ง, เครื่องมือ และบริการที่จะช่วยให้ใช้เวลาในการปิดระบบน้อยที่สุด ในขณะเดียวกันก็ปลอดภัยต่อข้อมูลมากที่สุด ซึ่งไม่ว่าจะใช้วิธีใด จะต้องทำการ Pre-Scan ข้อมูลโดยการใช้โปรแกรมที่ชื่อ Character Set Migration ดังได้กล่าวมาแล้ว

โปรแกรม Export/Import
โปรแกรม Oracle Export และ Import เป็นวิธีง่าย ๆ ในการย้ายข้อมูลระหว่างสองฐานข้อมูลที่เป็น Oracle ทั้งคู่ แม้ว่าทั้งคู่จะอยู่บนต่างฮาร์ดแวร์, OS หรือ (Database) Configuration เมื่อคุณ Export วัตถุใด ๆ ในฐานข้อมูล (เช่น Tables) วัตถุนั้น ๆ จะถูกดึง (แต่ไม่ได้ลบเอาวัตถุนั้นออกจากฐานข้อมูล) ออกมาพร้อมทั้งวัตถุที่เกี่ยวข้อง (เช่น Indexes, Comments และ Grants) ข้อมูลที่ถูกดึงออกมา จะถูกเขียนลงในไฟล์ Dump ที่เป็นฟอร์แมตของ Oracle โดยเฉพาะ และสามารถที่จะนำเข้าฐานข้อมูลเฉพาะ Oracle โดยการใช้โปรแกรม Oracle Import เท่านั้น โปรแกรม Import อ่านโครงสร้างของวัตถุและข้อมูลในวัตถุจากไฟล์ Dump และ Insert เข้าไปในฐานข้อมูล Oracle

ตั้งแต่ Oracle9i เป็นต้นมา โปรแกรม Export จะดึงข้อมูลโดยใช้ Character Set ของ Server (Character Set จะถูกกำหนดเมื่อตอนสร้างฐานข้อมูล) ย้อนหลังไป Oracle8i โปรแกรม Export จะดึงข้อมูลโดยใช้ Character Set ที่กำหนดโดยพารามิเตอร์ NLS_LANG ที่กำหนดไว้ที่เครื่องที่ใช้ในการ Export (ซึ่งอาจจะไม่ใช่ Database Server เอง อาจจะเป็นเครื่อง Client ก็ได้) เมื่อทำการนำข้อมูลเข้า โปรแกรม Import จะแปลงข้อมูลให้เป็น Character Set ของเครื่องที่ Import ข้อมูลเข้าโดยอัตโนมัติ คุณจะต้องระวังว่า Character Set ของไฟล์ Export (Dump)จะต้องเป็น Subset ของ Character Set ของ Import Server มีข้อจำกัดบางประการเมื่อ Export จากฐานข้อมูลที่มีชุดตัวอักษรเป็นแบบหลายไบท์ ดูรายละเอียดจาก Oracle Database Utilities Guide ในหัวข้อการ Export และ Import โปรแกรม Export/Import ใช้เทคโนโลยีที่เรียกว่า Oracle Stream ซึ่งทำให้สามารถทำได้โดยไม่ต้องปิดระบบฐานข้อมูลหรือถ้าปิดก็ใช้เวลาน้อยมาก

การใช้สคริปต์ CSALTER
สคริปต์ CSALTER เป็นเครื่องมือของ DBA สำหรับทำการ Migrate ชุดตัวอักษร CSALTER เป็นส่วนหนึ่งของ Character Set Scanner Utilities และเป็นสคริปต์ที่ใช้ในการ Migrate ชุดตัวอักษรที่ตรงไปตรงมาที่สุด แต่สามารถจะใช้ได้เฉพาะในบางสถานการณ์เท่านั้น กล่าวคือข้อมูลในฐานข้อมูลจะต้องใช้ชุดตัวอักษรที่เป็น Strict Subset(ทุกตัวอักษรในชุดจะต้องเป็นส่วนหนึ่ง)ของชุดตัวอักษรปลายทาง หรืออีกนัยหนึ่งชุดตัวอักษรปลายทางจะเป็น Strict Superset ของชุดตัวอักษรต้นทางก็ต่อเมื่อ
1) ตัวอักษรแต่ละตัว และทุก ๆ ตัวจะต้องมีในชุดตัวอักษรปลายทาง
2) ตัวอักษรแต่ละตัว และทุก ๆ ตัวจะต้องมีรหัส (Code Point) เดียวกันกับตัวอักษรในชุดปลายทาง เช่น ชุดตัวอักษรหลายชุดที่เป็น Strict Superset ของ US7ASCII

อย่างไรก็ตาม ในกรณีของ CLOB สคริปต์ CSALTER จะทำการแปลงได้เฉพาะคอลัมน์ CLOB ใน Data Dictionary และ Sample Schema ซึ่งถูกสร้างโดย Oracle เท่านั้น คอลัมน์ CLOB ที่ user สร้างขึ้นมาเองจะต้องถูกจัดการแยกต่างหาก จาก Oracle9i เป็นต้นมา Field ที่ใช้ภายในบางตัวของ Data Dictionary และ Sample Schema ถูกเก็บในคอลัมน์ CLOB กรณีเป็นคอลัมน์ CLOB ที่สร้างขึ้นเอง ถ้าชุดตัวอักษรเป็นแบบหลายไบท์ ข้อมูลที่เป็น CLOB จะถูกเก็บในรูปแบบที่สอดคล้องกับข้อมูลที่เป็น UCS-2 แต่ถ้าชุดตัวอักษรเป็นแบบไบท์เดี่ยว ข้อมูล CLOB จะถูกเก็บโดยใช้ชุดตัวอักษรของฐานข้อมูลเองCSALTER จะแปลงข้อมูลในคอลัมน์ CLOB ใน Data Dictionary และใน Sample Schema เท่านั้น คอลัมน์ CLOB อื่น ๆ คุณจะต้อง Export ออกมาและ Drop ทิ้งก่อนที่จะใช้สคริปต์ CSALTER

การใช้ CSALTER ร่วมกับการ Export/Import แบบเลือกเฉพาะบางรายการ
CSALTER เป็นวิธีที่อาจจะเร็วที่สุดในการ Migrate เนื่องจากมันไม่ได้ทำการการแปลงข้อมูลใด ๆ ยกเว้นกับคอลัมน์ CLOB ที่อยู่ใน Data Dictionary และใน Sample Schema ซึ่งสร้างขึ้นโดย Oracle (ตอนสร้างฐานข้อมูล) บ่อยครั้งที่ข้อมูลส่วนใหญ่ในชุดตัวอักษรต้นทางเป็น Strict Subset ของชุดตัวอักษรปลายทาง แต่อย่างไรก็ตามถ้าหากมีข้อมูลที่มีลักษณะที่อาจจะต้องมีการเปลี่ยนแปลงจากโคัดหนึ่งไปยังอีกโคัดหนึ่ง (Convertible) แม้เพียงนิดเดียวก็จะทำให้ไม่สามารถใช้ CSALTER

การ Export/Import ข้อมูลทั้งฐานอาจจะใช้เวลาและทรัพยากรของเครื่องมากหากเป็นฐานข้อมูลขนาดใหญ่ ซึ่งเราสามารถใช้วิธีลูกผสมในการนี้ได้ โดยเบื้องต้นข้อมูลจำนวนน้อยส่วนที่เป็น Convertible จะถูก Export ไปเป็นไฟล์ Dump และถูกลบออกจากฐานข้อมูล ซึ่งจะทำให้เราสามารถใช้สคริปต์ CSALTER ได้ จากนั้นเราก็จะ Import ส่วนข้อมูลจากไฟล์ Dump กลับเข้ามาเป็นชุดตัวอักษรใหม่ ดู Case Study3 ซึ่งจะอธิบายถึงสภาวะที่เหมาะสม ส่วนเทคนิคในการแปลงแบบนี้ กรุณาดู Oracle Database 10g Globalization Guide เกี่ยวกับเรื่อง CSALTER

เตรียมแบ็คอัพ
ในขั้นตอนนี้ข้อมูลต้นฉบับได้ถูกสแกน และได้เลือกวิธีการในการแปลงไว้แล้ว การทำการแบ็คอัพเป็นเรื่องจำเป็นโดยเฉพาะกับเครื่องที่เป็น Production ก่อนที่จะทำการแปลง ถ้าข้อมูลถูกแก้ไขหลังจากการสแกนครั้งล่าสุด ก็ให้รัน Database Character Set Scanner อีกที ถ้าจำเป็น

เช็คดูว่ามีพื้นที่เพียงพอ
เมื่อคุณ Migrate จากชุดข้อมูลแบบไบท์เดี่ยวมาเป็นหลายไบท์ จะทำให้ต้องใช้พื้นที่เพิ่มขึ้นเป็นจำนวนมากสำหรับฐานข้อมูลตัวใหม่ เราสามารถทำการคำนวณการขยายตัวของข้อมูลได้จากสัดส่วนของจำนวนไบท์ระหว่างตัวต้นทางกับตัวปลายทาง เช่นถ้า Migrate จากไบท์เดี่ยวไปยังหลายไบท์แบบความกว้างคงที่ (Fixed Width Multibyte Character Set เช่น AL16UTF16 จะกินพื้นที่สองไบท์ต่อหนึ่งตัวอักษรเสมอไม่ว่าจะเป็นตัวอักษรใด) การคำนวณก็จะตรงไปตรงมาคือคูณด้วยสอง แต่สำหรับการแปลงไปยังหลายไบท์แบบความกว้างไม่คงที่ (Variable Width Multibyte Character Set เช่น AL32UTF8) การคำนวณจะซับซ้อนกว่า เช่นกรณีของ UTF-8 ถ้าเป็นส่วนที่เป็น ASCII จะใช้หนึ่งไบท์ต่อหนึ่งตัวอักษร ตัวอักษรละตินที่มี Accent, ภาษา Greek, Cyrillic, Arabic และภาษา Hebrew จะใช้สองไบท์ ส่วนภาษาอื่น ๆ รวมทั้งภาษาจีน, ญี่ปุ่น, เกาหลี และอินเดียจะใช้สามไบท์สำหรับแต่ละตัวอักษร และถ้าเป็น ตัวอักขระพิเศษ (Supplementary Character) จะใช้สี่ไบท์สำหรับแต่ละตัวอักษร

ซ้อมรัน
แนะนำให้ทำการทดสอบการรันบนฐานทดสอบ ซึ่งจะช่วยให้คุ้นเคยกับขั้นตอนทั้งหมด ซึ่งจะลดเวลาในการปิดระบบ และยังจะช่วยให้กะเวลาได้ว่าจะใช้เวลาทั้งหมดเท่าใด และจะต้องใช้ทรัพยากรเท่าใด และเป็นจังหวะที่เราสามารถทดสอบดูด้วยว่า Application ดั้งเดิม (Legacy) หรือ Application ใหม่สามารถทำงานได้ไม่มีปัญหากับชุดตัวอักษรชุดใหม่

รันการแปลง และขั้นตอนการตรวจสอบหลังการแปลง
ทันทีที่การแปลงเสร็จสิ้น และฐานข้อมูลได้เปิดใช้งาน ให้ตรวจสอบว่าการแปลงข้อมูลทำได้ถูกต้อง ถ้าเราใช้โปรแกรม Import ให้ตรวจสอบดูว่าไม่มีข้อความเตือนใด ๆ ใน Log เราอาจจะตรวจสอบข้อมูลสักกลุ่มหนึ่งว่าถูกต้อง และเราอาจจะรัน Database Character Set Scanner อีกครั้งหนึ่งเพื่อเช็คหา Exception ทดสอบดูทุก ๆ Application ที่ใช้ฐานข้อมูลเพื่อให้แน่ใจว่ายังทำงานได้ตามปกติ และท้ายสุดตรวจสอบระบบอย่างใกล้ชิดสักช่วงระยะเวลาหนึ่งเพื่อดูประสิทธิภาพในการทำงานว่าลดลงหรือไม่ (ประสิทธิภาพที่ลดลงอาจจะมาจากขนาดของแต่ละตัวอักษรที่ใหญ่ขึ้น)

กรณีศึกษา
กรณีศึกษาข้างล่าง มีเพื่อเป็นตัวอย่างของวิธีการ, เทคนิค และการตัดสินใจที่จะต้องทำ ในการทำการ Migrate ชุดตัวอักษรให้ปลอดภัย

1) Migrate ฐานข้อมูลที่ใช้ US7ASCII เพื่อให้รองรับภาษาได้มากขึ้น
ผู้ใช้รายหนึ่งมีความต้องการที่จะ Migrate ฐานข้อมูลจากตัวเดิมที่เป็น US7ASCII เพื่อให้รองรับภาษาในยุโรปตะวันตก และประเทศในเอเชีย เครื่อง Client ที่ใช้ติดต่อกับฐานข้อมูลเป็น Windows ภาษาอังกฤษ โดยได้ตั้งค่า NLS_LANG เป็น AMERICAN_AMERICA.US7ASCII ดังนั้นการติดต่อจาก Client ไปฐานข้อมูลจึงเป็นแบบ PASS-THUR ผู้ใช้คิดว่าข้อมูลที่เข้ามาน่าจะเป็น ASCII แท้ร้อยเปอร์เซนต์ แต่หลังจากรัน Database Character Set Scanner โดยให้ชุดตัวอักษรต้นทางเป็น US7ASCII (ASCII 7 บิท) และปลายทางเป็น AL32UTF8 กลับพบว่า มี Exception โดยเมื่อผ่านการตรวจสอบแล้วพบว่ามีตัวอักษรท้องถิ่น และตัวอักษรพิเศษ (ที่เป็นตัวอักษร 8 บิท) ที่อยู่ในฐานข้อมูลอย่างผิดปกติ ตอนนี้ผู้ใช้จะต้องตัดสินใจว่าจะทำยังไงต่อ ถ้าข้อมูลที่เป็น 8 บิทไม่สำคัญ ผู้ใช้ก็อาจจะตัดสินใจลบข้อมูล หรือทำการแก้ไขข้อมูลนั้น เช่นแก้จากตัวอักษร 'ä' เป็นตัว 'a' เมื่อข้อมูล "สะอาด" และได้สแกนดูอีกทีแล้วว่าเป็นข้อมูลที่เป็นแบบ Changeless ทั้งหมด (คือเมื่อแปลงแล้วตัวอักษรจะมี Code Point เหมือนเดิม) ก็สามารถใช้ CSALTER ได้

ในอีกทางหนึ่งถ้าข้อมูลที่เป็น 8 บิทจำเป็นจะต้องเก็บไว้ก็ต้องใช้วิธีการอื่น โดยจะต้องทำการตรวจดูว่าข้อมูลโดยทั่วไปมีลักษณะเป็นอย่างไร สมมติว่าข้อมูล 8 บิทนั้นมาจาก Windows ภาษาอังกฤษ เราอาจจะลองใช้ Scanner และเลือกชุดตัวอักษรต้นทางที่เราคิดว่าครอบคลุมชุดตัวอักษรของข้อมูล สิ่งหนึ่งที่ต้องสังเกตคือชุดตัวอักษร Latin1 (WE8ISO8859P1) และ WE8MSWIN1252นั้นแม้ว่าจะมีความคล้ายกันมาก แต่ก็ไม่เหมือนกัน ชุดตัวอักษร WE8MSWIN1252 ของไมโครซอฟต์นั้น มีตัวอักษรเพิ่มเติมซึ่งใช้ทุก ๆ รหัสที่อยู่ในช่วง 8 บิท ดังนั้นถ้าเราตั้งให้ Scanner ใช้ WE8MSWIN1252 ก็จะไม่ช่วยในการหา Exception ที่อยู่ในช่วงของชุดตัวอักษร 8 บิท วิธีการที่ดีกว่าน่าจะเป็นการตั้งค่าตัวอักษรต้นทางเป็น WE8ISO8859P1 และเลือกตัวปลายทางเป็นตัวที่ต้องการเช่น AL32UTF8 ผลการสแกนอาจจะแสดงว่าอาจจะเกิดการตัดแบ่ง (Truncation) เนื่องจากตัวอักษรยุโรป (เดิมที่ใช้หนึ่งไบท์) ที่เป็นตัว Accented จะใช้สองไบท์ใน UTF-8 ดังนั้นถ้าไม่เพิ่มขนาดคือยังคงใช้หนึ่งไบท์จะทำให้การแปลงข้อมูลผิดพลาด ดังนั้นจึงต้องมีการเปลี่ยนแปลงขนาดของคอลัมน์ด้วย ถ้าผลการสแกนแจ้งว่าข้อมูลทั้งหมดสามารถที่จะถูกแปลงได้ (Convertible) และไม่มีคอลัมน์ใด ๆ ที่จะถูกตัดแบ่ง ก็หมายความว่าข้อมูลสามารถจะถูก Migrate ได้อย่างปลอดภัยโดยใช้โปรแกรม Export และ Import มีขั้นตอนสองขั้นตอนที่ต้องทำ ถ้าชุดตัวอักษรเดิมเป็น US7ASCII เราจะต้องรันสคริปต์ CSALTER เพื่อจะเปลี่ยนชุดตัวอักษรไปเป็น WE8MSWIN1252 หรือ WE8ISO8859P1 จากนั้นก็การ Export (แบบ Full) และ Import เพื่อที่จะแปลงข้อมูลทั้งหมดไปเป็น UTF-8

2) Migrate จาก WE8ISO8859P1 ไปเป็น WE8ISO8859P15 เพื่อให้สนับสนุนตัวอักษรยูโร (€)
ตัวอย่างนี้เป็นการ Migrate จาก WE8ISO8859P1 (Latin1) ไปเป็น WE8ISO8859P15 (Latin9) เพื่อให้รองรับตัวยูโร WE8ISO8859P1 มีชุดตัวอักษรบางตัวที่ไม่มีใน WE8ISO8859P15 {เช่น ¼,½,¾,¤ และอื่น ๆ} ถ้าผลจากการสแกนแสดงว่าข้อมูลทั้งหมดเป็น Changeless ก็สามารถที่จะใช้สคริปต์ CSALTER ได้ สังเกตว่าในสคริปต์ CSALTER เพียงแค่ตรวจสอบว่าข้อมูลใน Schema ที่มีอยู่ (ไม่ใช่ชุดตัวอักษร) เป็น Strict Subset ของชุดตัวอักษรปลายทาง ถ้าผลจากการสแกนบอกว่าข้อมูลทั้งหมดไม่ได้เป็นแบบ Changeless เราจะต้องตัดสินใจว่าจะทำยังไงกับข้อมูลที่ไม่สามารถแปลงได้ (Non-Convertible) เราอาจจะต้องใช้ Oracle Locale Builder เพื่อที่จะตัดแต่ง WE8ISO8859P15 เพื่อให้สามารถรองรับตัวอักษรใน WE8ISO8859P1 ที่มันไม่รองรับ แล้วจึง Migrate โดยใช้ Export และ Import เพื่อให้ฐานข้อมูลรองรับตัวอักษรเพิ่มเติมเหล่านี้

3) Migrate จากชุดตัวอักษรยุโรปตะวันตกไปเป็น AL32UTF8 เพื่อให้สามารถรองรับภาษาเอเชียได้
ฐานข้อมูลส่วนใหญ่ที่ใช้ชุดตัวอักษรยุโรปตะวันตกจะมีตัวอักษรที่อยู่ในชุดของ ASCII เป็นจำนวนมาก ถ้าเราเลือก Migrate เฉพาะคอลัมน์ที่เก็บข้อมูลที่ใช้ชุดตัวอักษรยุโรปตะวันตก เราจะเหลือแต่ข้อมูลที่ใช้ชุดตัวอักษร ASCII ซึ่งจะทำให้เราสามารถใช้สคริปต์ CSALTER ได้ ประโยชน์ของวิธีการนี้คือสามารถลดเวลาที่ปิดฐานข้อมูลเพื่อแปลงข้อมูลโดยใช้โปรแกรม Export และ Import การสแกนจะแสดงผลว่า ASCII เป็นข้อมูลที่ Changeless ในขณะที่ข้อมูลภาษายุโรปตะวันตกจะเป็น Convertible
- ถ้ามีการใช้ตัวอักษรยุโรปตะวันตก (ตัวอักษรที่ถูก Accent และตัวอักษรพิเศษเช่น ตัวยูโร (€) ซึ่งจะถูกแปลงเป็นสองไบท์ใน UTF-8) เป็นจำนวนมาก และกระจัดกระจายทั่วไปในฐานข้อมูล การทำ Full Export/Import น่าจะเป็นวิธีการที่ดีที่สุด
- ถ้ามีการใช้ตัวอักษรยุโรปตะวันตกเป็นจำนวนน้อย และแยกอยู่ในตารางไม่กี่ตาราง การเลือก Export/Import เฉพาะตารางเหล่านั้นก็ทำให้งานง่ายขึ้น โดยปล่อยให้ส่วนที่เหลือของฐานข้อมูลถูกแปลงโดยใช้สคริปต์ CSALTER หลังจากที่การสแกนให้ผลว่าส่วนที่เหลือนั้นเป็น Changeless
- ถ้าการใช้งานภาษายุโรปตะวันตกเป็นไปอย่างกระจายคืออาจจะมีจำนวนไม่มากนัก แต่กระจายออกไปในหลาย ๆ ตาราง วิธีที่ดีที่สุดอาจจะเป็น Oracle Migration Services, Inline Migration Utility สามารถใช้ผลที่ได้จากการสแกน เพื่อที่จะแปลงเฉพาะภาษายุโรปตะวันตก และใช้ CSALTER เพื่อแปลง ASCII ไปเป็น AL32UTF8
จากกรณีต่าง ๆ ที่กล่าวมา ลองมาดูว่าข้อมูลที่ผิดปกติมีผลอย่างไรต่อกรณีเหล่านี้ สมมติว่ามีผู้ใช้รายหนึ่งต้องการ Migrate จาก WE8ISO8859P1 (Latin1) ไปเป็น AL32UTF8(UTF-8) เพื่อให้สามารถรองรับภาษาเอเชียได้เพิ่มเติมจากภาษายุโรปตะวันตกที่ใช้อยู่ ผู้ใช้รัน Database Character Set Scanner โดยมี Source เป็น WE8ISO8859P1 และ Target เป็น AL32UTF8 ผลการสแกนแสดงว่ามีตัวอักษรภาษาญี่ปุ่นเก็บอยู่ในฐานข้อมูลแบบผิดปกติ ผู้ใช้จะต้องตัดสินใจว่าจะทำอย่างไร ในขั้นแรกผู้ใช้ทราบว่าข้อมูลดังกล่าวเข้ามาในฐานข้อมูลได้จากวิธีการ Pass-Thru อย่างไรก็ตามข้อมูลเหล่านี้จะต้องถูกเก็บไว้ด้วย แต่จะทำอย่างไร? การเลือก Export/Import เฉพาะบางรายการอาจจะเป็นทางเลือก แต่ก็ยังมีคงปัญหาทางเทคนิคอยู่ดี เนื่องจากฐานข้อมูลเป็น WE8ISO8859P1 ซึ่งจะถูก Export ด้วย Character Set นี้ และการ Import ไปเป็น AL32UTF8 ก็จะให้ผลที่ผิดพลาด เมื่อพบสถานการณ์แบบนี้อาจจะต้องพึ่งบริการ Migration จาก Oracle

4) ผู้ใช้ต้องการให้ระบบรองรับภาษาจีนทั้งแบบ Simplified และ Traditional
กรณีฐานข้อมูลของผู้ใช้รองรับภาษาจีนแบบ Simplified อยู่โดยใช้ชุดตัวอักษร ZHS16GBK ต่อมาเกิดความต้องการที่จะให้ฐานข้อมูลสามารถรองรับ Traditional Chinese ได้ด้วย การให้ฐานข้อมูลสามารถรองรับภาษาเอเชียได้มากกว่าหนึ่งภาษาพร้อม ๆ กันนั้นมักจะต้องใช้ชุดตัวอักษรแบบ Unicode ผู้ใช้รันฐานข้อมูล Oracle10g และใช้ AL32UTF8 เพื่อที่จะให้รองรับ 94,140 ตัวอักขระที่เพิ่มขึ้นมา ซึ่งรวมถึงตัวอักษร Ideographs ของเอเชียนด้วย หลังจากที่สแกนและ "ทำความสะอาด" ตามที่จำเป็นแล้ว ผู้ใช้สามารถใช้โปรแกรม Export/Import เพื่อแปลงข้อมูล ในกรณีนี้ผู้ใช้ต้องขยายบางคอลัมน์ เพื่อให้สามารถรองรับการขยายตัวของชุดตัวอักษร ZHS16GBK (ที่ใช้สองไบท์) มาเป็นสามไบท์ใน AL32UTF8

สรุป
การ Migrate ชุดตัวอักษรเป็นเรื่องที่ Serious การทำโดยปราศจากความเข้าใจ และขั้นตอนที่ถูกต้องสามารถทำให้เกิดความเสียหายได้มาก จงปฏิบัติตามข้อควรระวัง และใช้เทคนิคที่ได้รับการยอมรับแล้วดังที่กล่าวในเอกสารนี้ เพื่อ Migrate อย่างปลอดภัยและมีประสิทธิภาพ ถ้ามีปัญหาในขั้นตอนใด ๆ ให้หาความช่วยเหลือจาก Oracle Support and Migration Services โดยตัว Oracle เองได้ช่วยให้ผู้ใช้หลายรายสามารถ Migrate ชุดตัวอักษรได้อย่างประสบผลสำเร็จมาแล้ว เมื่อการ Migrate เสร็จสมบูรณ์จะช่วยให้สามารถรวมฐานข้อมูลเป็นหนึ่งเดียว และสนับสนุนชุดตัวอักษรใหม่ และตัวอักษรหลากชนิดในแต่ละชาติแต่ละภาษา ทำให้ข้อมูลมีประโยชน์และสามารถให้บริการให้กับผู้ใช้งานได้กว้างขวางขึ้น

อ่านรายละเอียดเพิ่มเติมใน Oracle Database Globalization Support Guide 10g Release 2 (10.2)

จบบทความเรื่อง "วิธีการ Migrate Character Set ที่เหมาะสม" โดยบริบูรณ์ครับ