Skip to content
≡

Administrator

Developer

Tools

External Tools

Common

Common#

OutOfMemoryError occurs during data transfer.#

Cause#

This error can occur due to a lack of memory while several threads are inserting data into the target database through batch operations.

Solution#

According to the error message output from OutOfMemoryError, there are two cases as below.

<Java heap space>#

Depending on the situation, you can choose between the two methods below.

  • Change performance property values to reduce memory usage
  • Open the project.
  • Click the menu "Migration" → "Migration Options".
  • Lower the Batch Size and Thread Count values
  • Increase the maximum amount of memory the program can use
  • Open the executable file (migcenter.bat or migcenter.sh) with the editor.
  • Set the value of the option '-Xmx' that sets the maximum heap size in the JVM to be higher than the existing value.

On Windows 32 bit machines, you can set Xmx values up to 1.5 GB due to OS dependency.

<PermGen space>#
  1. Open the executable file (migcenter.bat or migcenter.sh) with the editor.
  2. Set the '-XX: MaxPermSize' option to set the maximum size of the permanent generation space in the JVM above the existing value.
<Metaspace>#

If the version of the JVM you are using is Java 8 or higher, the lack of space in Metaspace may be the cause. Metaspace, implemented since Java 8, is a replacement for PermGen (permanent generation space).

  1. Open the executable file (migcenter.bat or migcenter.sh) with an editor.

  2. Change '-XX: MaxPermSize', which is the option to set the maximum size of permanent generation space in JVM, to an option that determines the maximum size of the metaspace, and modify it higher than the existing value.

    • Before change: -XX:MaxPermSize=128m
    • After change: -XX:MaxMetaspaceSize=256m

  3. References

The NOT NULL constraint on a table column whose data type is LOB is not migrated.#

Cause#

It is a phenomenon that the Migration Center arbitrarily removes the NOT NULL constraint on the LOB column.

The Migration Center inserts data into the target database using a query that contains parameters (e.g., "insert into tablename values (?,?)").

Unlike other columns, Altibase processes data into LOB columns by initializing data to null first, then receiving data through LOB Locator and inputting data. Therefore, if the column has a NOT NULL constraint, the insertion is failed because the data cannot be initialized to null.

In order to overcome this difference, the Migration Center removes the NOT NULL constraint on the LOB column to perform data migration. For more detailed information, refer to the General Reference - 1. Data Type - LOB Data Type - Restrictions.

Because Oracle performs constraint checking only at commit time, you can insert data even under these conditions.

Solution#

After the migration, execute an SQL statement that adds a NOT NULL constraint to the corresponding column in Altibase

Database Character Set Notes#

Generally, it is recommended to use the same DB character set of the source database and target database.

If you need to specify different character sets because of special circumstances, you should check whether each DB character set is compatible. If you migrate data between incompatible character sets, the data may be corrupted.

Example#

  1. From source database KSC5601 to Destination database UTF8: Migratable
    KSC5601 Korean data can be written in UTF8. Therefore, each character set is compatible with each other.

    Note: Because the data length can be longer, you need to increase the size of the character type column when you relocate the table object.

  2. From source database KSC5601 to Destination database GB231280: Not migratable
    KSC5601 Korean data cannot be written as GB231280. Therefore, each character set is incompatible with each other.
    If data migration is required under these conditions, the table column data types CHAR and VARCHAR of the target database should all be changed to NCHAR and NVARCHAR, and data transfer must be performed.

JDBC & Migration Center Character Set Process#

  1. When fetching data from the source database, get the char data as the source database DB character set and store it in a byte array.
  2. Convert the data stored in the byte array to UTF-16 format and store it in a String object of Java base type.
  3. Pass the String object to the PreparedStatement object that inserts the data into the target database with the setString function.
  4. JDBC driver converts the String object into data into the DB character set of the target database and insert them into the target database.

The program terminates abnormally while selecting the JDBC driver file.#

Cause#

This is an error that can occur when running the Migration Center in a Windows environment. While selecting the JDBC driver file when registering the connection information, changing the directory may cause the problem that the program terminates abnormally. This is a Java JVM crash caused by a communication problem between the JVM and the Windows operating system. Users can check for the Java crashes that usually occurs in the old version of the JVM through the link below.

Solution#

Install the latest version of the JRE, modify the JAVA_HOME path in the migcenter.bat file, and rerun the Migration Center.

When running the CLI Mode, UnsatisfiedLinkError: /usr/lib/jvm/java-8-oracle/jre/lib/amd64/libawt_xawt.so: libXrender.so.1: cannot open shared object file: No such file or directory has occurred.#

This error occurs when the 64-bit libXrender.so file is requested by the JVM, but the package is not installed in the OS.

Cause#

This usally occurs when you install a 32-bit JRE on a 64-bit device and try to run the Java program by using it.

Solution#

After installing a new JRE that matches the bit value of the device, change JAVA_HOME to the appropriate location. Debian-like Linux installs a package by executing the following command. 

sudo apt-get install libXrender1

References#

When Running the Migration Center, the message "Could not create the java virutal machine" is displayed and the startup fails.#

Cause#

This is an error that can occur when the maximum memory allocation value (-Xmx) set in bat and sh is lager than the memory allocated by the system. In particular, this error is frequently reported in Window O/S 32 bit.

Solution#

Change the value of -Xms -Xmx in bat and sh according to the user environment, and then restart Migration Center.