Migration to Unicode Datatypes for Multilingual Databases and Applications An Oracle White Paper January 2005 Migration to Unicode Datatypes for Multilingual Databases and Applications Introduction .....................................................................................................................................................3 Unicode Datatype Features .............................................................................................................................3 Unicode Character Set Encoding.................................................................................................................3 Character Length Semantics........................................................................................................................4 Interoperability ............................................................................................................................................4 Exception Handling for Data Loss ..............................................................................................................5 SQL Unicode String Processing..................................................................................................................5 Unicode Data Input .....................................................................................................................................6 Unicode Data Input in Oracle Database 10g ...............................................................................................6 Limitations...................................................................................................................................................7 Database Migration .........................................................................................................................................8 Step 1. Choosing the Unicode Character Set...............................................................................................8 Step 2. Identify Columns to be Migrated ....................................................................................................9 Step 3. Considerations Before Migration ....................................................................................................9 Step 4. Schema migration..........................................................................................................................10 Apply ”Alter Table‘ SQL Commands ...................................................................................................10 Online Table Redefinition .....................................................................................................................12 Comparison Between —Alter table“ and —On-line Table Redefinition“.................................................14 Step 5. Post Migration Tasks.....................................................................................................................14 Application Migration to Unicode Datatypes................................................................................................16 PL/SQL Application..................................................................................................................................16 PL/SQL Variables .................................................................................................................................16 PL/SQL String Literal ...........................................................................................................................17 PL/SQL String Comparison ..................................................................................................................18 PL/SQL Procedures/Functions ..............................................................................................................18 Length Semantics Change .....................................................................................................................19 String Functions ....................................................................................................................................19 CLOB to NCLOB Migration.................................................................................................................22 OCI Application ........................................................................................................................................22 JDBC Application .....................................................................................................................................25 Summary .......................................................................................................................................................28 Migration to Unicode Datatypes Page 2 Migration to Unicode Datatypes for Multilingual Databases and Applications Introduction Unicode datatypes were introduced in Oracle9 i. Unicode datatypes are supported through the SQL NCHAR datatypes: NCHAR, NVARCHAR2, and NCLOB. (In this paper, —Unicode datatypes“ refers to SQL NCHAR types.) SQL NCHAR datatypes have existed since Oracle8. However, in Oracle 9i forward, they have been redefined and their length semantics have been changed to meet customer globalization requirements. Data stored in columns of SQL NCHAR datatypes are exclusively stored in a Unicode encoding regardless of the database character set. These Unicode columns allow users to store Unicode in a database, which may not use Unicode as the database character set. Therefore, developers can build Unicode applications without dependence on the database character set. The Unicode datatypes also make it easier for customers to incrementally migrate existing applications and databases to support Unicode. This paper consists of three parts. First, it briefly introduces the Unicode datatype features. It then discusses the steps to migrate existing databases to make use of the Unicode datatypes and what the considerations are about functionality and performance. The third part highlights the steps to migrate applications to support Unicode datatypes and work with the database schema changes. Finally, it concludes with a brief summary. Unicode Datatype Features The concept of the Unicode datatype, introduced in Oracle 9i allows customers to support Unicode columns in a non-Unicode database. This is a very powerful feature and is further enhanced by the inter-operability between SQL NCHAR types and other datatypes. Users can store, process and retrieve SQL NCHAR data the same as SQL CHAR data. There are several major aspects for the new Unicode datatype features that will be discussed in this section: • Character set encoding • Character length semantics • Interoperability • Data loss handling • Unicode string processing Unicode Character Set Encoding Oracle9i and Oracle Database 10g support two Unicode encodings for the Unicode datatypes. The Oracle characters set names are AL16UTF16 and UTF8. When the database is first created AL16UTF16 or UTF8 can be specified as the "national character set" parameter. When the national character set is not specified, the default is AL16UTF16. For details on Unicode encoding support, please refer to the Globalization Support Guide. Migration to Unicode Datatypes Page 3 Supplementary Character is a Unicode encoded character having a Unicode code point between U+10000 and U+10FFFF. In UTF-16 encoding, it is encoded with a surrogate pair that consists of a sequence of two Unicode values, where the first value is a high-surrogate in the range U+D800 through U+DBFF and the second is a low-surrogate in the range U+DC00 through U+DFFF. Here is an example of creating a database with AL16UTF16 as the NCHAR character set: CREATE DATABASE mydb MAXINSTANCES 1 MAXLOGHISTORY 1 MAXLOGFILES 5 MAXLOGMEMBERS 5 MAXDATAFILES 100 DATAFILE '/vobs/oracle/oradata/mynewdb/system01.dbf' SIZE 325M REUSE CHARACTER SET al32utf8 NATIONAL CHARACTER SET AL16UTF16 LOGFILE GROUP 1 ('/vobs/oracle/oradata/mynewdb/redo01.log') SIZE 100M, GROUP 2 ('/vobs/oracle/oradata/mynewdb/redo02.log') SIZE 100M; Character Length Semantics Character length semantics was also introduced in Oracle 9i . It measures characters based on number of Unicode code units instead of number of bytes. - When it is based on the number of bytes, it is called byte length semantics. A Unicode code unit is a 16-bit unit that is used to represent a UCS2 code point or its equivalent in other character sets. It is the minimal bit combination that can represent a unit of encoded text. It is equivalent to the length semantics for Java strings. The advantages of character length semantics over byte semantics include lengths close to visual length and portability across different character sets. While the default length semantics for a database is BYTE, character length semantics is the only allowable length semantics for SQL NCHAR types. It is not allowed to specify any ”CHAR‘ or ”BYTE‘ quantifiers for SQL NCHAR column definitions . Example: CREATE TABLE emp ( empno NUMBER(4), ename NVARCHAR2(10), job NVARCHAR2(9), mgr NUMBER(4), hiredate DATE, SAL NUMBER(7,2), deptno NUMBER(2)); The ename column can hold up to 10 Unicode code units. When NCHAR character set is AL16UTF16, its maximum byte length is 20 bytes. Otherwise, if the NCHAR character set is UTF8, the ename column would again hold up to 10 Unicode code units, but its maximum byte length is 30 bytes. Interoperability When operations between SQL NCHAR types and other datatypes are necessary, users can either apply explicit conversion functions or