Implementing Siebel Business Applications on DB2 for z/OS > Migrating a Siebel Database to Unicode Format >

About Migrating a Siebel Database to Unicode Format


You can migrate your Siebel database from either an ASCII or EBCDIC encoding system to a Unicode encoding system if the following conditions are met:

  • You are using a Innovation Pack 2015, Patchset 5 with DB2 Version for z/OS.
  • You are migrating to a DB2 version for z/OS subsystem.

When you migrate your Siebel schema from an ASCII or EBCDIC encoding system to a Unicode encoding system, all of the source tables that are marked as active in the repository are migrated to new target tables which are in Unicode format. Tables that are defined as inactive in the repository are not built in the Unicode target schema.

Migrating to Unicode involves the following steps:

  1. Innovation Pack 2015, Patchset 5 supports Unicode UTF-16 encoding, that is, it uses a double-byte character encoding scheme. To migrate to Unicode, Siebel database utilities first convert the existing schema to a schema that supports UTF-16.
  2. Siebel CRM database utilities then build SQL CREATE schema control cards and JCL templates, which are transferred to the z/OS host and applied to create the target database schema.
  3. Finally, data is migrated from the source ASCII or EBCDIC database to the target (Unicode) database using Cross Loader SQL control cards; these are built using options available on the Siebel Unicode Migration Option Menu on the z/OS host.

CAUTION:  Migrating to Unicode is more complex than simply importing your existing data into a Unicode database. Failure to execute the migration correctly can result in serious data corruption or unrecoverable data loss. For this reason, the participation of Oracle's Application Expert Services is mandatory if you perform a Unicode migration. Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle's Application Expert Services.

About Unicode Storage Requirements

The use of the Unicode UTF-16 encoding format will increase the storage required by your Siebel database. During the Unicode migration process, data types in the Siebel ASCII or EBCDIC database are mapped from single-byte to double-byte characters, as shown in Table 11.

Table 11. Data Type Mappings During Unicode Migration
Data Types on ASCII and EBCDIC Databases on Z/OS
Data Types on Unicode Databases on Z/OS

Char

Graphic

Varchar

Vargraphic

Longvarchar

Longvargraphic

Clob

DBClob

Moving from single-byte to double-byte characters causes some Siebel table spaces to exceed their page sizes and causes some tables to exceed the 32-KB limit; these tables will require LOB columns in the Unicode database.

To help you estimate the increase in storage that can occur when you migrate from a code page to a Unicode database, Table 12 shows the number of table spaces and the storage required for a sample SIA EBCDIC database, and the storage and table spaces required by the same database when it has been migrated to Unicode.

NOTE:  The figures in Table 12 are provided as a guideline only. The increase in storage required by your actual Unicode database might be greater or lesser than indicated for the sample database.

Table 12. Table Spaces and Storage Required by Sample Siebel SIA Databases
Siebel SIA Database
No of 4-KB Table Spaces
No of 8-KB Table Spaces
No of 16-KB Table Spaces
No of 32-KB Table Spaces
Total Space Required

EBCDIC

4229

(2,759,008 KB)

331

(312,112 KB)

171

(62,272 KB)

105

(52,160 KB)

 

3,185,552 KB

Unicode

3941

(2,507,584 KB)

405

(327,776 KB)

345

(358,992 KB)

247

(119,712 KB)

 

3,314,064 KB

Siebel Business Applications use COMPRESS set to YES as the default for table space definitions; setting the COMPRESS parameter to YES reduces the storage requirements for table spaces.

About the NOT PADDED Clause

To minimize any increase in storage when you migrate your database to Unicode, indexes in the Siebel Schema are defined with the NOT PADDED clause by default when you convert your storage control file to Unicode using the Siebel Database Storage Configurator as described in Converting the Storage Control File to Unicode.

When the NOT PADDED clause is specified:

  • Varying-length columns of an index are not padded to their maximum length; DB2 stores only the key data, which reduces the storage required by the index key.
  • VARGRAPHIC columns of an existing index are stored as varying-length columns.

    If the NOT PADDED clause is not specified, VARGRAPHIC columns are stored as fixed-length columns.

You can specify that indexes are to be NOT PADDED by default by specifying the PADIX DSNZPARM. You can also use the PADDED or NOT PADDED clauses in the CREATE INDEX or ALTER INDEX statements to specify whether an individual index is padded or not.

Differences Between ASCII, EBCDIC and Unicode Sort Order

The EBCDIC, ASCII, and Unicode encoding systems each use a different sort order for numbers, upper case alpha characters, lower case alpha characters, and special characters. As a result, if you load a partitioned table based on these characters, rows can be assigned to different partitions in the target table than they were in the original ASCII or EBCDIC source table, which might lead to unbalanced partitions in your database. You must determine if the partitioning keys need to be reevaluated when you migrate to Unicode.

Implementing Siebel Business Applications on DB2 for z/OS Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices.