Issue

When the Oracle character set is KO16KSC5601, even though certain Korean character types such as '샾', '똟', '잌' are not supported by KO16KSC5601, if they are entered and can be queried in the DB, migrating the data to Tibero can result in corrupted data.

Cause

When data is entered through Oracle JDBC, it can be converted and entered as CHAR and VARCHAR2 Korean data in the DB using UTF-8.

If the data was not entered normally as above, and the Tibero character set is set to MSWIN949, UTF8, or the like, migrating the data will result in data corruption during migration.

Solutions

This issue can be resolved by performing the migration using Tibero to Oracle DB LINK.

1. Tibero to Oracle DB Link Configuration Environment

• Set the Oracle Server version and the Oracle Client version installed on the Tibero Server to be the same

2. Set NLS_LANG in .profile (or .bash_profile) to be the same as the Oracle Server's NLS_LANG

$ vi .profile
export NLS_LANG=KOREAN_KOREA.KO16KSC5601

3. Set TB_NLS_LANG in tbdsn.tbr

$ vi tbdsn.tbr
oralink=((GATEWAY =(PROGRAM=/tibero/tbgateway/gw4orcl_11g)(TARGET=Oracle)(TX_MODE=GLOBAL)))

# If Tibero is UTF8, set to UTF8; if MSWIN949, set to MSWIN949

TB_NLS_LANG=UTF8 

4. Set SKIP_CHAR_CONV=Y in tbgw.cfg

 $ vi tbgw.cfg
LISTENER_PORT=9998
LOG_DIR=/tibero/tbgateway/oracle/log
LOG_LVL=5
MAX_LOG_SIZE=502400000
SKIP_CHAR_CONV=Y

※ SKIP_CHAR_CONV Parameter

SKIP_CHAR_CONV parameter, when set to Y,
will configure the character set according to the NLS_LANG environment variable set on the server where the Gateway is running.

Therefore, in an environment where the Oracle character set is KSC5601, even if a character '잌' that is not supported by KSC5601 is stored, by setting the NLS_LANG and SKIP_CHAR_CONV parameters as above, both the character set conversion in Oracle and in Tibero can be skipped.

As a result, the data can be migrated normally without corruption.