Tác giả: Vikram Khatri, Sumit Kumar, Kshitij Sanghoi, and Rajib Sarkar
Ngày phát hành: 27 JAN 2026
Chuyên mục: Advanced (300), Amazon RDS, RDS for Db2, Technical How-to

Khi di chuyển từ Db2 mainframe (z/OS) sang Amazon Relational Database Service (Amazon RDS) for Db2 trên Linux, việc chọn trang mã (code page) và trình tự đối chiếu (collation sequence) phù hợp là rất quan trọng để đảm bảo khả năng tương thích dữ liệu. Lựa chọn đúng sẽ giúp ngăn ngừa các vấn đề cắt cụt dữ liệu, mở rộng ký tự và duy trì hiển thị nhất quán các ký tự nước ngoài (chẳng hạn như các chữ cái Latin có dấu) cũng như hành vi sắp xếp.

Mặc dù Amazon RDS for Db2 mặc định sử dụng Unicode, bạn có thể đạt được khả năng tương thích với mainframe thông qua cấu hình cẩn thận. Bài viết này sẽ hướng dẫn bạn cách chọn trang mã phù hợp cho Amazon RDS for Db2 để giúp đảm bảo quá trình di chuyển dữ liệu diễn ra liền mạch.

Các tham số trang mã, đối chiếu và vùng lãnh thổ trong Amazon RDS for Db2 không thể sửa đổi sau khi tạo cơ sở dữ liệu. Việc lựa chọn cẩn thận ngay từ đầu sẽ tránh được việc phải tạo lại và di chuyển lại cơ sở dữ liệu.

Hiểu về CCSID và trang mã của mainframe

Trong Db2 for z/OS®, mỗi ký tự được ánh xạ tới một số tùy thuộc vào CCSID (coded character set identifier) và trang mã liên quan đến ký tự đó. Trang mã là một định danh số cho một ánh xạ byte cụ thể và chỉ là ánh xạ từ byte sang glyph. Ví dụ là trang mã 037, còn được gọi là Extended Binary Coded Decimal Interchange Code (EBCDIC) cho Hoa Kỳ và Canada. CCSID là một định danh đầy đủ mô tả bộ ký tự, mã hóa và các quy tắc chuyển đổi. CCSID bao gồm trang mã và ngôn ngữ với siêu dữ liệu chuyển đổi. Ví dụ là CCSID 0037 (EBCDIC cho Hoa Kỳ và Canada bao gồm các quy tắc chuyển đổi). Mỗi CCSID ngụ ý một trang mã, nhưng một trang mã không ngụ ý một CCSID hoàn chỉnh. Db2 for z/OS thực hiện chuyển đổi ký tự nội bộ và cần CCSID để biết chính xác cách chuyển đổi dữ liệu.

Các trang mã theo khu vực

Các trang mã Bắc Mỹ và Tây Âu

• IBM-37 (CCSID 37, CP037)
• IBM-500 (CCSID 500, CP500)
• IBM-1047 (CCSID 1047, CP1047)

Các trang mã Đức và Áo

• IBM-273 (CCSID 273, CP273): EBCDIC truyền thống của Đức và Áo
• IBM-1141 (CCSID 1141, CP1141): EBCDIC của Đức và Áo có hỗ trợ ký hiệu Euro

Các trang mã Nhật Bản

• IBM-930 (CCSID 930): Trang mã EBCDIC hỗn hợp SBCS và DBCS của Nhật Bản sử dụng SBCS Latin (Roman) và DBCS JIS X 0208
• IBM-939 (CCSID 939): Trang mã EBCDIC hỗn hợp SBCS và DBCS của Nhật Bản sử dụng SBCS Katakana và DBCS JIS X 0208
• IBM-1390 (CCSID 1390): Sử dụng SBCS Katakana có hỗ trợ ký hiệu Euro (€)
• IBM-1399 (CCSID 1399): Bộ ký tự byte hỗn hợp có SBCS được định nghĩa trong IBM 1027 và DBCS được định nghĩa trong IBM-300 ký hiệu Euro (€)
• IBM-5026 (CCSID 5026): Trang mã EBCDIC SBCS Katakana của Nhật Bản với các chữ cái Latin chỉ viết hoa và đối chiếu theo hướng Katakana
• IBM-5035 (CCSID 5035): Bộ ký tự byte hỗn hợp, có SBCS được định nghĩa trong IBM-1027 và DBCS được định nghĩa trong IBM-300

Các trang mã EBCDIC này mã hóa các bộ ký tự được tối ưu hóa cho các khu vực và ngôn ngữ cụ thể. Mặc dù nhiều trang mã chia sẻ các bộ ký tự Latin-1 tương tự, chúng khác nhau trong việc gán các điểm mã cụ thể để tăng cường khả năng tương thích với các yêu cầu cục bộ và hệ thống mở. Trên các nền tảng IBM, CCSID ký tự (CHAR và VARCHAR) và CCSID đồ họa (GRAPHIC và VARGRAPHIC) là khác biệt. Các CCSID chỉ DBCS như 1399 và 5035 được dành cho dữ liệu đồ họa và không thể biểu diễn các ký tự SBCS.

Chi tiết về các trang mã theo khu vực

Bắc Mỹ và Tây Âu:

• CCSID 37 (CP037): EBCDIC truyền thống cho Hoa Kỳ, Canada, Hà Lan và Bồ Đào Nha. Tối ưu hóa cho các ứng dụng mainframe cũ với vị trí ký hiệu tiêu chuẩn. Có nguồn gốc từ những năm 1960 cho các mainframe System/360.
• CCSID 500 (CP500): Biến thể EBCDIC quốc tế cho Bỉ, Canada-Pháp và Thụy Sĩ. Có các điều chỉnh cho các ký hiệu cục bộ (ví dụ: ký hiệu tiền tệ như CHF). Chia sẻ hầu hết các điểm mã với CCSID 37 nhưng bao gồm các hoán đổi để hỗ trợ đa ngôn ngữ.
• CCSID 1047 (CP1047): EBCDIC hệ thống mở được giới thiệu vào những năm 1990 cho OS/390 USS (Unix System Services). Một biến thể của CCSID 37 với sáu hoán đổi ký tự cụ thể để phù hợp với các tiêu chuẩn POSIX/C.
• CCSID 1140 (CP1140): EBCDIC nâng cao của Hoa Kỳ và Canada (CP037) bao gồm ký hiệu Euro (€).

Đức và Áo:

• CCSID 273 (CP273): Mã hóa EBCDIC truyền thống của Đức và Áo với các ký tự đặc trưng của Đức như ä, ö, ü và ß. Được sử dụng rộng rãi ở các nước nói tiếng Đức cho các hệ thống mainframe cũ.
• CCSID 1141 (CP1141): EBCDIC nâng cao của Đức và Áo bao gồm ký hiệu Euro (€). Được giới thiệu để hỗ trợ các yêu cầu của liên minh tiền tệ châu Âu trong khi vẫn duy trì hỗ trợ ký tự tiếng Đức.

Nhật Bản:

• CCSID 930 (CP930): Trang mã EBCDIC hỗn hợp SBCS và DBCS của Nhật Bản sử dụng SBCS Latin (Roman) và DBCS JIS X 0208.
• CCSID 939 (CP939): Trang mã EBCDIC hỗn hợp SBCS và DBCS của Nhật Bản sử dụng SBCS Katakana và DBCS JIS X 0208. Nó hỗ trợ cả SBCS (Katakana, Latin và chữ số) và DBCS Kanji. Nó rất phổ biến trên z/OS và các môi trường mainframe cũ hơn.
• CCSID 1390 (CP1390): Trang mã EBCDIC hỗn hợp SBCS và DBCS của Nhật Bản có hỗ trợ ký hiệu Euro (€).
• CCSID 1399 (CP1399): CCSID đồ họa DBCS EBCDIC của Nhật Bản (chỉ DBCS).
• CCSID 5026 (CP5026): Trang mã EBCDIC SBCS Katakana của Nhật Bản với các chữ cái Latin chỉ viết hoa và trình tự đối chiếu theo hướng Katakana.
• CCSID 5035 (CP5035): CCSID đồ họa DBCS EBCDIC của Nhật Bản (chỉ DBCS).

Khả năng tương thích di chuyển và các tiêu chuẩn ISO

Đối với các trang mã dựa trên Latin (37, 500, 1047, 273): ISO-8859-1 (Latin-1 hoặc CCSID 819) đóng vai trò là tương đương ASCII trực tiếp, cho phép chuyển đổi không mất dữ liệu cho hầu hết các ký tự.

Xem xét ký hiệu Euro: ISO-8859-1 không bao gồm ký hiệu Euro (€) vì nó được chuẩn hóa trước khi Euro ra đời. Đối với các hệ thống mainframe sử dụng các trang mã hỗ trợ Euro (1140, 1141, 1390), hãy xem xét:

• ISO-8859-15 (Latin-9): Bao gồm ký hiệu Euro và thay thế một số ký tự ít dùng từ ISO-8859-1
• UTF-8: Hỗ trợ Unicode toàn diện bao gồm Euro và tất cả các ký tự quốc tế

Đối với các trang mã Nhật Bản (930, 939, 1390, 1399): UTF-8 là mã hóa đích được khuyến nghị vì ISO-8859-1 không thể biểu diễn các ký tự Nhật Bản. Lưu ý rằng cả 930 hoặc 939 đều có thể được chuyển đổi sang UTF-8 vì chuyển đổi là một chiều. Nếu bạn cố gắng chuyển đổi ngược lại từ UTF-8 sang 930 hoặc 939, gần một nửa số ký tự trong UTF-8 sẽ không hoạt động trong 930 và 939. Vì lý do này, bạn sẽ không thể chuyển đổi qua lại mà không gặp vấn đề.

Hiểu về các trang mã Db2 LUW

Db2 LUW (Linux, Unix, và Windows) không sử dụng CCSID theo cách mà Db2 trên z/OS sử dụng.

• Db2 LUW được xây dựng trên một trang mã thay vì CCSID.
• Một trang mã là bất biến và được định nghĩa tại thời điểm tạo cơ sở dữ liệu.
• Db2 LUW dựa vào chuyển đổi trang mã client/server.
• Db2 LUW không có cột danh mục CCSID — nền tảng này sử dụng International Components for Unicode (ICU) và các ngôn ngữ US thay vì các định nghĩa CCSID của IBM.

Hỗ trợ trang mã: Db2 LUW hỗ trợ nhiều trang mã khác nhau bao gồm UTF-8 (Unicode) để hỗ trợ ký tự toàn diện.

Khả năng tương thích ký tự: ISO-8859-1 đóng vai trò là đối tác ASCII trực tiếp của bộ ký tự IBM 37, IBM 500 và IBM-1047, cho phép chuyển đổi không mất dữ liệu cho các ký tự Latin-1.

Hành vi đối chiếu:

• Các đối chiếu tiêu chuẩn dựa trên ngôn ngữ (ví dụ: en_US)
• Các chuỗi 256 byte tùy chỉnh có thể mô phỏng sắp xếp EBCDIC cho các cơ sở dữ liệu một byte
• Các cơ sở dữ liệu Unicode sử dụng đối chiếu CLDR (Common Locale Data Repository) hoặc UCA (Unicode Collation Algorithm), làm cho việc mô phỏng EBCDIC phức tạp hơn

Tính nhất quán hiển thị ký tự: Các ký tự nước ngoài (không phải ASCII) hiển thị chính xác khi dữ liệu được chuyển đổi đúng cách trong quá trình truyền. Nếu không có chuyển đổi, các byte EBCDIC xuất hiện dưới dạng ký tự không hợp lệ trong LUW (ví dụ: 0xC1 biểu thị A trong EBCDIC nhưng không hợp lệ trong ASCII). Giao thức DRDA của Db2 và các công cụ như db2move xử lý chuyển đổi tự động.

Chiến lược lựa chọn trang mã cho Amazon RDS for Db2

Trong phần này, chúng ta sẽ xem xét sự linh hoạt của trang mã mainframe so với Amazon RDS.

Mainframe Db2 cho phép định nghĩa trang mã ở nhiều cấp độ:

• Cấp độ hệ thống con: Định nghĩa CCSID (SBCS_CCSID, MIXED_CCSID và DBCS_CCSID) thiết lập các giá trị mặc định cho các đối tượng và ứng dụng không chỉ định rõ ràng một CCSID
• Cấp độ Tablespace và Table: Một mệnh đề CCSID trong quá trình tạo thiết lập mã hóa mặc định cho tất cả các cột ký tự trừ khi bị ghi đè ở cấp độ cột
• Cấp độ cột: CCSID cụ thể cho từng cột (ví dụ: VARCHAR(50) CCSID 1208 cho UTF-8)

Db2 định nghĩa trang mã chỉ tại thời điểm tạo cơ sở dữ liệu và không thể sửa đổi sau đó.

Các cân nhắc chính

Khi tạo một phiên bản Amazon RDS for Db2, hãy tránh chỉ định tên cơ sở dữ liệu mặc định trong quá trình tạo phiên bản, vì nó mặc định là UTF-8 với vùng lãnh thổ US.

Tính tương đương của trang mã:

• Trang mã IBM 819 (ISO-8859-1) là tương đương chính xác của các trang mã mainframe 37, 500, 1047 và 273 (không bao gồm ký hiệu Euro).
• Để hỗ trợ ký hiệu Euro, ISO-8859-15 (Latin-9) cung cấp khả năng tương thích với các trang mã 1141 và các biến thể hỗ trợ Euro khác.
• Các trang mã Nhật Bản (930, 939, 1390 và 1399) yêu cầu mã hóa UTF-8 để biểu diễn ký tự đúng cách. Tuy nhiên, đối tác của các trang mã Nhật Bản 930 và 939 trong Db2 LUW là IBM-943. Có vẻ như hầu hết khách hàng Nhật Bản chọn IBM-943 cho các trang mã Nhật Bản 930 và 939.

Khung quyết định

Chọn trang mã phù hợp dựa trên các yêu cầu di chuyển cụ thể của bạn.

Tùy chọn 1a: Bộ mã ISO-8859-1

Sử dụng ISO-8859-1 khi:

• Chỉ sử dụng một CCSID (37, 500 hoặc 1047) cho tất cả các bảng và cột trong mainframe Db2.
• Yêu cầu không cắt cụt dữ liệu.
• Phải giữ nguyên thứ tự sắp xếp chính xác của mainframe. Thứ tự sắp xếp trong Db2 được bật tại thời điểm tạo cơ sở dữ liệu thông qua tham số đối chiếu.
• Không cần hỗ trợ đa ngôn ngữ.
• Không yêu cầu ký hiệu Euro (ISO-8859-1 ra đời trước khi Euro được giới thiệu).

Triển khai:

$ db2 connect to rdsadmin user <MasterUserName> using <MasterUserPassword>
$ db2 "call rdsadmin.create_database('<DBNAME>',32768,'ISO-8859-1','US','EBCDIC_819_037')"

Thay thế <MasterUserName>, <MasterUserPassword> và <DBNAME> bằng các giá trị thực tế của bạn.

Tùy chọn 1b: Bộ mã ISO-8859-15 (hỗ trợ Euro)

Sử dụng ISO-8859-15 khi:

• Di chuyển từ các trang mã mainframe hỗ trợ Euro (1141 và 1390)
• Yêu cầu hỗ trợ ký hiệu Euro (€)
• Duy trì mã hóa ký tự một byte — SBCS (Single Byte Character Set)
• Yêu cầu đa ngôn ngữ hạn chế

Triển khai:

$ db2 "call rdsadmin.create_database('<DBNAME>',32768,'ISO-8859-15','US','SYSTEM')"

Các tùy chọn trình tự đối chiếu:

Tham số thứ năm chỉ định trình tự đối chiếu. Chọn dựa trên CCSID mainframe của bạn:

Hướng dẫn lựa chọn:

• Mainframe CCSID 37: Sử dụng EBCDIC_819_037
• Mainframe CCSID 500 hoặc 1047: Sử dụng EBCDIC_819_500
• Mainframe CCSID 273: Sử dụng EBCDIC_819_500
• Mainframe CCSID 930: Sử dụng EBCDIC_932_5026 (đối chiếu Katakana)
• Mainframe CCSID 939: Sử dụng EBCDIC_932_5035 (đối chiếu Latin)
• CCSID hỗ trợ Euro (1141, 1390, 1399): Cân nhắc UTF-8 hoặc ISO-8859-15

Lệnh CREATE_DATABASE tạo một cơ sở dữ liệu Db2 với:

• Kích thước trang 32 K được khuyến nghị. Kích thước trang mặc định là 8 K.
• Bộ mã ISO-8859-1 (tương đương với trang mã IBM 819)
• Vùng lãnh thổ US
• Đối chiếu EBCDIC cho trang mã mainframe được chỉ định

Các mã vùng được hỗ trợ cho ISO-8859-1 và ISO-8859-15: AL, AU, AT, BE, BR, CA, CH, CN, DE, DK, ES, ET, FI, GB, ID, IE, IN, IS, IT, JP, KE, KR, Lat, MY, NL, NZ, NO, PH, PT, TW, TZ, US, và ZA

Tham khảo tài liệu của IBM để biết các kết hợp vùng lãnh thổ và trang mã hợp lệ.

Tùy chọn 2: Trang mã UTF-8

Sử dụng UTF-8 khi:

• Yêu cầu hỗ trợ dữ liệu đa ngôn ngữ
• Di chuyển từ các trang mã mainframe Nhật Bản (930, 939 hoặc 1390)
• Cần hỗ trợ ký hiệu Euro (€) và các ký tự quốc tế toàn diện
• Việc chuẩn bị cho tương lai để xử lý ký tự toàn cầu là quan trọng
• Việc giữ nguyên thứ tự sắp xếp của mainframe không quan trọng

Các cân nhắc quan trọng:

• Mở rộng ký tự: UTF-8 có thể yêu cầu nhiều không gian lưu trữ hơn
  • Các nguyên âm có dấu (à, é, î), ký hiệu tiền tệ (¢, £, ¥), phân số (¼, ½, ¾) và các ký tự đặc biệt (ß, ¬, µ) yêu cầu 1 byte trong các trang mã mainframe nhưng 2 byte trong UTF-8
  • Yêu cầu sửa đổi DDL: Độ dài CHAR và VARCHAR phải được điều chỉnh, điều này không hề đơn giản

Triển khai:

$ db2 connect to rdsadmin user <MasterUserName> using <MasterUserPassword>
$ db2 "call rdsadmin.create_database('<DBNAME>',32768,'UTF-8','US','SYSTEM')"

UTF-8 được hỗ trợ ở tất cả các vùng lãnh thổ. Tham khảo tài liệu của IBM để biết các tùy chọn vùng lãnh thổ có sẵn.

Hiểu về CODEUNITS32 trong cơ sở dữ liệu Db2 UTF-8

Khi sử dụng UTF-8 trong Amazon RDS for Db2, việc di chuyển mainframe chắc chắn sẽ gặp phải các vấn đề cắt cụt dữ liệu vì sự mở rộng ký tự — một số ký tự tăng từ 1 byte trên mainframe lên 2 byte hoặc hơn trong UTF-8.

Để tránh các thay đổi DDL, Db2 cung cấp một cơ chế để thay đổi phép đo chuỗi mặc định từ OCTETS sang CODEUNITS32 bằng cách sửa đổi tham số cấu hình cơ sở dữ liệu STRING_UNITS.

$ db2 connect to rdsadmin user <MasterUserName> using <MasterUserPassword>
$ db2 "call rdsadmin.update_db_param('<DBNAME>','STRING_UNITS', 'CODEUNITS32', 'NO')"

Thay đổi này yêu cầu khởi động lại phiên bản vì STRING_UNITS không phải là tham số động. Các DDL phải được tạo sau khi cập nhật tham số này để tham số có hiệu lực.

Ví dụ thực tế: Cơ sở dữ liệu ISO-8859-1

Ngoài ra, bạn có thể chỉ định CODEUNITS32 ở cấp độ cột khi tạo đối tượng mà không thay đổi tham số STRING_UNITS.

Tạo cơ sở dữ liệu ISO-8859-1:

$ db2 connect to rdsadmin user <MasterUserName> using <MasterUserPassword>
$ db2 "call rdsadmin.create_database('MYDB',32768, 'ISO-8859-1','US','EBCDIC_819_037')"

Kiểm tra với dữ liệu mẫu:

db2 connect to mydb user <MasterUserName> using <MasterUserPassword>
db2 "create table t1 (c1 char(2))"
db2 "insert into t1 values ('ßA')"
db2 "insert into t1 values ('ßB')"
db2 "insert into t1 values ('ßC')"
db2 "insert into t1 values ('¬I')"
db2 "insert into t1 values ('µ5')"
db2 "insert into t1 values ('¼O')"
db2 "insert into t1 values ('¼Q')"
db2 "insert into t1 values ('¼S')"
db2 "select c1, character_length(c1, octets) LENGTH from t1"

Kết quả:

C1 LENGTH          
-- -----------
ßA           2
ßB           2
ßC           2
¬I           2
µ5           2
¼O           2
¼Q           2
¼S           2
  8 record(s) selected.

Lưu ý rằng mỗi cột sử dụng chính xác 2 byte trong cơ sở dữ liệu ISO-8859-1. Thực hiện kiểm tra tương tự với cơ sở dữ liệu UTF-8.

Tạo cơ sở dữ liệu UTF-8:

$ db2 connect to rdsadmin user <MasterUserName> using <MasterUserPassword>
$ db2 "call rdsadmin.create_database('MYUTFDB',32768, 'UTF-8','US','SYSTEM')"

Kiểm tra với CODEUNITS32:

db2 connect to myutfdb user <MasterUserName> using <MasterUserPassword>
db2 "create table t1 (c1 char(2 CODEUNITS32))"
db2 "insert into t1 values ('ßA')"
db2 "insert into t1 values ('ßB')"
db2 "insert into t1 values ('ßC')"
db2 "insert into t1 values ('¬I')"
db2 "insert into t1 values ('µ5')"
db2 "insert into t1 values ('¼O')"
db2 "insert into t1 values ('¼Q')"
db2 "insert into t1 values ('¼S')"
db2 "select c1, character_length(c1, octets) LENGTH from t1"

Kết quả:

C1 LENGTH          
-- -----------
ßA           3
ßB           3
ßC           3
¬I           3
µ5           3
¼O           3
¼Q           3
¼S           3
  8 record(s) selected.

Quan sát chính: Mỗi cột sử dụng 3 byte trong cơ sở dữ liệu UTF-8, mặc dù được định nghĩa là CHAR(2 CODEUNITS32). Đặc tả CODEUNITS32 cho phép hai ký tự với tối đa 4 byte mỗi ký tự (tổng phân bổ 8 byte).

Đánh đổi và khuyến nghị về CODEUNITS32

Tác động của CODEUNITS32 cấp cơ sở dữ liệu:

• Phân bổ CHAR và VARCHAR mặc định thay đổi từ 1 byte thành 4 byte cho mỗi ký tự
• Giảm độ dài tối đa:
  • CHAR: từ 255 xuống 63 ký tự
  • VARCHAR: từ 32.704 xuống 8.174 byte (kích thước trang 32 KB)
• Đối với các cơ sở dữ liệu có 90% ký tự ASCII, kích thước có thể mở rộng lên 3,8 lần so với ban đầu

Nên tránh sử dụng CODEUNITS32 ở cấp độ cơ sở dữ liệu. Một lựa chọn là sử dụng CODEUNITS32 cấp cột có chọn lọc, nhưng hãy thực hiện cẩn thận, vì nó có thể lãng phí đáng kể không gian.

Ví dụ, CREATE TABLE t1 (c1 CHAR(2 CODEUNITS32)) phân bổ 8 byte.

Một cách tiếp cận tốt hơn là sử dụng OCTETS với độ dài được điều chỉnh. OCTETS là một biểu diễn của một byte. Đó là một ánh xạ một-một giữa một ký tự và một số liên quan trong các trang mã không phải Unicode. CREATE TABLE t1 (c1 CHAR(4 OCTETS)) phân bổ chính xác 4 byte.

Thực hành tốt nhất: Chỉ sử dụng CODEUNITS32 khi chắc chắn rằng bạn sẽ lưu trữ các ký tự 3–4 byte (ví dụ: các ngôn ngữ Đông Á). Đối với hầu hết các ký tự quốc tế, hãy sử dụng và điều chỉnh độ dài OCTETS cho phù hợp.

Sự khác biệt về đối chiếu: EBCDIC so với SYSTEM

So sánh thứ tự sắp xếp.

Thứ tự đối chiếu EBCDIC: Các ký tự đặc biệt, chữ thường, chữ hoa, sau đó là chữ số

Thứ tự đối chiếu SYSTEM: Chữ số, chữ hoa, chữ thường, sau đó là các ký tự đặc biệt

Ví dụ thực tế

Kiểm tra đối chiếu EBCDIC:

db2 "with s(v) as (values '-','0','A','a','ß','¬','µ','¼') select v as VALUE from s order by v"

Kết quả:

VALUE
-----
ß    
¬    
-    
a    
µ    
¼    
A    
0    
  8 record(s) selected.

Kết quả cho thấy thứ tự sắp xếp mong đợi của các ký tự đặc biệt, chữ thường, chữ hoa và chữ số.

Kiểm tra đối chiếu SYSTEM:

$ db2 "with s(v) as (values '-','0','A','a','ß','¬','µ','¼') select v as VALUE from s order by v"

Kết quả:

VALUE
-----
-
0
A
a
¬
µ
¼
ß
  8 record(s) selected.

Kết quả cho thấy thứ tự sắp xếp mong đợi của các chữ số, chữ hoa, chữ thường và các ký tự đặc biệt.

Xử lý các ký tự không được hỗ trợ trong ISO-8859-1

Khi các ứng dụng cố gắng chèn các ký tự không có sẵn trong ISO-8859-1 (CCSID 819), cơ sở dữ liệu sẽ thực hiện thay thế ký tự một cách âm thầm.

Ví dụ kiểm tra:

db2 "create table t1(c1 char(4))"
db2 "insert into t1 values ('常')" -- Japanese character
db2 "select c1, hex(c1) hex, character_length(c1, octets) length from t1"

Kết quả:

C1   HEX      LENGTH     
---- -------- -----------
     1A202020           4

Điều gì đã xảy ra:

• Không có lỗi hoặc cảnh báo nào được tạo
• Ký tự Nhật Bản đã được thay thế bằng ký tự SUB (substitute) (0x1A)
• Các byte còn lại được điền bằng khoảng trắng (0x20)

Điểm mấu chốt: Các cơ sở dữ liệu ISO-8859-1 không thể lưu trữ các ký tự không được hỗ trợ. Các ký tự không xác định sẽ được thay thế một cách âm thầm bằng 0x1A theo sau là khoảng trắng (0x20) cho các vị trí byte còn lại.

Đảm bảo tính nhất quán của ký tự trên các nền tảng

Các thực hành tốt nhất khi di chuyển dữ liệu

Công cụ chuyển đổi: Sử dụng liên kết Db2 (catalog cơ sở dữ liệu z/OS trong LUW) hoặc các công cụ như db2move/EXPORT với định dạng ASC/DEL để chuyển đổi ký tự tự động.

Kiểm tra cấu hình CCSID của mainframe

CCSID cấp bảng:

SELECT NAME, ENCODING_SCHEME
FROM SYSIBM.SYSTABLES
WHERE NAME = '<TABLE_NAME>' AND CREATOR = '<CREATOR_NAME>';
Example Result:
NAME             |ENCODING_SCHEME|
-----------------+---------------+
TABLE_NAME.      |E              | -- E = EBCDIC

CCSID cấp cột:

SELECT NAME, CCSID
FROM SYSIBM.SYSCOLUMNS WHERE TBNAME = '<TABLE_NAME>' AND TBCREATOR = '<CREATOR_NAME>';

Ví dụ kết quả:

NAME             |CCSID|
--------------------+-----+
COL1.              |   37|
COL2               |    0| -- 0 = subsystem default
COL3               |    0|
COL4               |   37|

Xác thực và kiểm thử

Kiểm thử ký tự: Chèn dữ liệu thử nghiệm với các ký tự quốc tế (ví dụ: café, niño) trên mainframe, xuất và nhập vào LUW và xác minh tính nhất quán hiển thị bằng cách sử dụng các ứng dụng khách GUI như:

• DBeaver
• DataGrip
• IBM Data Studio
• IBM Database Management Console

Rủi ro chuyển đổi: Các chuyển đổi khứ hồi (EBCDIC → ASCII → EBCDIC) có thể làm mất các biến thể ký tự mà không có ánh xạ chính xác. Xác minh kết quả bằng cách sử dụng các bảng CCSID chính thức của IBM.

Kết luận

Các tham số trang mã, đối chiếu và vùng lãnh thổ trong Db2 là bất biến sau khi tạo cơ sở dữ liệu — không giống như các hệ thống cơ sở dữ liệu khác. Điều này làm cho việc lựa chọn ban đầu trở nên quan trọng đối với sự thành công của quá trình di chuyển. Các cân nhắc chính:

• ISO-8859-1: Chọn để có khả năng tương thích chính xác với mainframe và không mất dữ liệu. Sử dụng trình tự đối chiếu được định nghĩa trong Amazon RDS for Db2 để giữ nguyên hành vi sắp xếp của mainframe
• ISO-8859-15: Cân nhắc để hỗ trợ ký hiệu Euro khi di chuyển từ các trang mã mainframe hỗ trợ Euro (1141, 1390) và xác minh hỗ trợ của Amazon RDS
• UTF-8: Chọn để hỗ trợ đa ngôn ngữ, nhưng hãy lưu ý về sự mở rộng ký tự và các sửa đổi DDL tiềm năng
• Lập kế hoạch sớm: Giải quyết các yêu cầu về trang mã và đối chiếu sớm trong chu kỳ di chuyển để ngăn ngừa các vấn đề về chất lượng dữ liệu

Việc lựa chọn trang mã phù hợp sẽ ngăn ngừa cắt cụt dữ liệu, quản lý hiệu quả sự mở rộng ký tự và giúp đảm bảo hành vi ứng dụng nhất quán trên các nền tảng.

Lời cảm ơn

Cảm ơn Chiranjeev Mukherjee, Hajime Minagawa và Akira Shimosako đã xem xét kỹ lưỡng bài đăng blog này từ góc độ di chuyển mainframe và đặc biệt là đối với các bộ ký tự Nhật Bản.

Về tác giả

Vikram

Vikram là Kỹ sư cơ sở dữ liệu cấp cao (Sr. DBE) cho Amazon RDS for Db2. Vikram có hơn 20 năm kinh nghiệm về Db2. Anh ấy thích phát triển các sản phẩm mới từ đầu. Trong thời gian rảnh rỗi, anh ấy thực hành thiền và thích nghe podcast.

Sumit Kumar

Sumit là Kiến trúc sư giải pháp cấp cao tại AWS và thích giải quyết các vấn đề phức tạp. Anh ấy đã giúp khách hàng trong nhiều ngành khác nhau xây dựng và thiết kế khối lượng công việc của họ trên AWS Cloud. Anh ấy thích nấu ăn, chơi cờ vua và dành thời gian cho gia đình.

Rajib Sarkar

Rajib là Kỹ sư cơ sở dữ liệu cấp cao cho Amazon RDS for Db2. Rajib có hơn 20 năm kinh nghiệm về Db2.

Kshitij Sanghoi

Kshitij là Kỹ sư phát triển phần mềm cấp cao (Sr. Software Development Engineer) và có hơn 15 năm kinh nghiệm CNTT bao gồm hơn 11 năm tại AWS.