When the Applier uses multiple threads to apply change data to a MySQL target, it ends with message IDR-070217, which reports the MySQL error "Lock wait timeout exceeded; try restarting transaction."
The Applier might end with error message IDR-070217 when applying change data to a MySQL target. This problem occurs if the Applier uses multiple threads to apply change data to the same target table simultaneously, resulting in a next-key lock. In this case, the MySQL database returns the error "Lock wait timeout exceeded; try restarting transaction." To resolve this issue, in the Data Replication Console, set the
Distribute By
option to
Tables
on the
Map Columns
tab for each of the target tables. For more information, see
Handling Applier Failures.
After Data Replication is upgraded to a later version, the Applier ends with message IDR-070217, which reports the DB2 error "Could not convert binary other than LO type" or "Value too long for type character varying."
After you upgrade Data Replication to a later version, the Applier might end with error message IDR-070217 when processing data from a DB2 source. This problem occurs if the DB2 source database returns the error "Could not convert binary other than LO type" or "Value too long for type character varying." To resolve this issue, in the Data Replication Console, open a replication configuration that uses the DB2 source database and save the configuration again. Then restart all of the replication tasks and schedules.
An ORA-942 "table not found" error occurs when I select an Oracle table owner.
When I try to connect to a MySQL database, the following error occurs:
Could not connect to target: Communication failure during handshake. Is there server running on localhost: 3306
If the MySQL process runs on the specified port but still receives the error, the issue probably occurs because you are using MySQL 4.1 or later.
During Data Replication Console startup, the following error occurs:
"'java' is not recognized as an internal or external command, operable program or batch file."
The Data Replication Console is a Java application that requires the Java Runtime Environment (JRE) to be installed. Data Replication supports 64-bit JRE 1.7 and 1.8.
If you determine that a supported JRE version is installed, the issue might be occurring because the java.exe or java executable is not specified in the PATH environment variable.
The Data Replication Console fails to start but does not display an error message.
To resolve the problem, perform one or more of the following actions:
View the
DataReplication_installation
/logs/se.log file on the system where you run the Data Replication Console. The file might contain a message about the error that caused the Data Replication Console failure. Then try to resolve the problem and run the Data Replication Console again.
If the
DataReplication_installation
/logs/se.log file is empty, on Windows, you can complete the following steps to try to display a message about the error in the Console:
Create a backup copy of the idr_console.cmd script.
Open the idr_console.cmd script in a text editor.
In the following command, replace
start javaw
with
java
:
start javaw -Dfile.encoding=utf-8 -Xms256m -Xmx1024m ^
The resulting statement should appear as follows:
java -Dfile.encoding=utf-8 -Xms256m -Xmx1024m ^
Save and close the idr_console.cmd script.
Run the Data Replication Console.
Look for an error message in the Console window. Then based on the error information, try to resolve the problem.
Replace the idr_console.cmd script with the backup copy and run the Data Replication Console again.
If you have an old version of Java Runtime Environment (JRE), some java components might block the Data Replication Console. To resolve the issue, update JRE to the latest supported version.
If you still cannot start the Data Replication Console, contact Informatica Global Customer Support.
The following error appears in se.log:
java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location
The se.log file might include multiple occurrences of this error.
These errors cause the se.log file to increase in size, but have no effect on the Data Replication Console performance. To resolve the problem, upgrade your Java Runtime Environment to version 10.
When I try to connect to Oracle while running the Data Replication engine, I get an error. However, when I connect to Oracle from the Data Replication Console, I do not get an error.
The following error is issued when I try to connect to Oracle while running the Data Replication engine:
TNS:listener could not resolve SERVICE_NAME given in connect descriptor.
The Data Replication Console uses a JDBC connection driver. With this driver, the Data Replication Console first tries to use the Oracle SID and then the SERVICE_NAME to establish a connection. The Data Replication engine uses the SERVICE_NAME by default to connect to the database.
The SERVICE_NAME is specified in a tnsnames.ora connection string as follows:
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname)(PORT=port)))(CONNECT_DATA=(SERVER=DEDICATED)(
SERVICE_NAME=instancename
)))
To resolve this issue, try using the Oracle SID value. Either select the
Use SID instead of SERVICE_NAME
option in the Data Replication Console or specify the following parameter in the configuration .xml file:
<UseSidInsteadOfServiceName>true</UseSidInsteadOfServiceName>
When the Data Replication Extractor runs on AIX, the following error occurs:
ACE_Message_Block[14:43:55.719] Processing file:/home/user/IDR/AIX/DBSync/cust_log/log_1098 status:0
[14:43:55.732] ACE_OS::pread() read -1 bytes. Error code: 14. Address: 0 fffffffffff0cc8. Block size: 512. Offset: 512.
[14:43:55.737] OracleLogParser::parseSingleLog parsing failed for /home/user/IDR/AIX/DBSync/cust_log/log_1098
If this error occurs on AIX or another Linux or UNIX operating system, try increasing the operating system ulimit value for the data area size to a value such as 170000. For more information about the ulimit command, see your operating system documentation.
The Server Manager and replication tasks use excessive amounts of virtual memory
The Server Manager or replication tasks that run on Linux with the glibc library version 2.10 or later might use excessive amounts of virtual memory.
This problem might be related to the enhanced dynamic memory allocation (malloc) behavior of the glibc library 2.10 or later.
To reduce virtual memory usage, set the MALLOC_ARENA_MAX environment variable to 4. Then restart the Server Manager that runs on this computer.
To reduce virtual memory usage of a Server Manager instance, you can also reduce the number of threads that the Server Manager uses. Adjust the following Server Manager properties:
ApiThreadsCount
BuiltinTaskManagersCountThreads
CountThreads
IntermediateFileTransfersCountThreads
SendCountThreads
TransferThreadPoolsCountThreads
You can also set the DisableStatistics advanced property for the Server Manager to 1 to stop the collection of latency statistics.
I receive one of the following warning or error messages that indicates that the available disk space for the Server Manager is low or critically low.
When trying to connect to the Server Manager, I receive the following error message:
Not enough disk space on the Server Manager file system.
I receive one of the following error messages in the Event Viewer or in a notification email:
[WARNING] Disk space on the system of the Server Manager
server_name
is low. Available disk space for the following directories is less than the low disk space threshold of
disk_space
GB that is specified in the
WarningValueFreeSpace
parameter:
list_of_directories
.
[ERROR] Disk space on the system of the Server Manager
server_name
is critically low. The Server Manager stopped all of the replication tasks. Available disk space for the following directories is less than the minimum disk space of
required_space
GB that is specified in the
LimitValueFreeSpace
parameter:
list_of_directories
.
To avoid the disk space error messages, provide sufficient memory resources for the specified Server Manager instance. To avoid the disk space warning message, you can also decrease the value of the WarningValueFreeSpace parameter. You can edit the Server Manager parameters on the
Advanced Settings
tab in the Server Manager
Properties
dialog box. For more information about setting advanced properties for the Server Manager, see
Editing Properties for the Main Server or a Subserver.
You can view the available disk space for the directories that the Server Manager uses on the
Version
tab in the Server Manager
Properties
dialog box. For more information about viewing details for the Server Manager, see
Viewing Information About the Server Manager System.
After an Applier task ends with an error or in response to the
Abort Task
option, the following Teradata error occurs during subsequent Applier runs:
error 2652: Operation not allowed:
schema_name
.
table_name
is being Loaded.
If the Applier task ends abnormally or is aborted when loading source data to audit log tables on a Teradata target, the task might lock the audit log tables. If the audit log tables are locked, during subsequent Applier runs, the Applier task ends with an error. To continue replication, resolve any problem that led to the abnormal completion of the task. Then, drop the locked audit log tables, re-create the audit log tables on the Teradata target, and restart the Applier task.
When trying to replicate source data to an Apache Kafka target, the Applier ends with message IDR-12004, which reports the error "Could not create the Java Virtual Machine."
The Applier spawns a Java Virtual Machine (JVM) to execute the code required to apply data to Kafka targets. When this error occurs, it indicates that the Server Manager PATH or LIBRARY_PATH path environment variable specifies a directory that does not contain the necessary Java JVM library.
Edit the appropriate environment variable on the system on which the Applier runs to specify a directory that includes the Java JVM library:
On Windows, add the directory that contains the jvm.dll library to the PATH environment variable. For example, use the following command:
PATH=%PATH%;%JAVA_HOME%\jre\bin\server
On Linux, add the directory that contains the libjvm.so library to the LD_LIBRARY_PATH path environment variable. For example, use the following command:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$JAVA_HOME/jre/lib/amd64/server
Then stop and restart the Server Manager. The JVM library directory must be specified in the PATH or LIBRARY PATH of your environment before you start the Server Manager on the target system.
When trying to replicate source data to an Apache Kafka target, I receive a Java Virtual Machine OutOfMemory error.
The Applier spawns a Java Virtual Machine (JVM) to execute the code required to apply data to Kafka targets. When a JVM OutOfMemory error occurs, it indicates that the JVM is attempting to consume more memory than the maximum it has been configured to consume. You can specify the maximum memory setting assigned to the JVM by changing the value of the LIBHDFS_OPTS environment variable. The Applier passes the value specified for the LIBHDFS_OPTS environment variable to the JVM.
For example, use the following command to set the maximum heap memory size to 1000 megabytes:
LIBHDFS_OPTS=-Xmx1000m
Set the LIBHDFS_OPTS environment variable before starting the Server Manager for the Applier.
The Applier does not explicitly set any memory limits or defaults for the JVM. The JVM will use its own default settings, which vary by JVM vendor and operating environment.
You can use the LIBHDFS_OPTS environment variable to set any property that the JVM accepts. However, setting memory limits is the most common use for the LIBHDFS_OPTS environment variable.
When trying to replicate source data to an Apache Kafka target, the Applier ends with message IDR-130003 QADPTR-15028, which reports the following error:
An attempt to connect to Kafka was unsuccessful because of a Class Not Found exception. A third-party library is probably missing from the generated Java classpath.
Typically, this message indicates that not all Kafka client library files have been added to the generated classpath. Verify that the apply.kafka.kafka_client_libraries_directory runtime parameter specifies the correct location of Kafka client library files on the machine where the Applier runs and that the version of the client library files matches the Kafka target version. The Kafka client libraries are JAR files located in the Kafka installation libs directory. For example,
kafka_2.11-0.10.0.1
/libs. For more information about the apply.kafka.kafka_client_libraries_directory runtime parameter, see
Data Replication Runtime Parameters.
For Oracle targets, the Applier and InitialSync use excessive amounts of memory
The Applier might use an excessive amount of memory when applying change data to LOB columns in Oracle target tables in either Audit Apply or Merge Apply mode. Also, InitialSync might use an excessive amount of memory when loading data to Oracle LOB columns. To reduce the memory usage, try upgrading the Oracle Client on the systems where the Applier and InitialSync run to the Client for the latest Oracle version that Data Replication supports.
InitialSyncs ends with error message IDR-000413, which reports the following DB2 for Linux, UNIX, and Windows driver error for a DB2 target:
[IBM][CLI Driver][DB2/NT64] SQL0964C The transaction log for the database is full. SQLSTATE=57011.
InitialSync might end with this error because the DB2 for Linux, UNIX, and Windows target database is not configured to handle the amount of data that InitialSync attempts to commit to the target. To resolve this issue, perform one of the following steps:
In the Data Replication Console, decrease the value of the initial.rows_to_commit runtime parameter. This parameter specifies the maximum number of Insert rows that a single InitialSync thread can commit on the target.
Increase the size of the DB2 transaction log.
