• If a table at a target system is updated from multiple source systems, the order of the update processing is unpredictable. If you need to control the order of update processing, you must do so by handling the processing appropriately. Suppose that data linkage is established from two source systems, A and B, to table T1 at a target system, and that a table row corresponding to source system A's mapping key value 100 is updated. Then a table row corresponding to source system B's mapping key value 100 is updated. In this case, the contents of the table row corresponding to key value 100 at the target system might not be the same as that of the corresponding row at source system B.
• Before you modify the extraction definition at the source system, you must ensure that all update information has been sent from the source system to the target Datareplicators. If you modify the extraction definition while some update information still remains untransmitted at the source Datareplicator, import processing might result in an error. In such a case, a target Datareplicator might not be able to recover the error, necessitating use of the HiRDB Dataextractor to re-create the target database.
• The source Datareplicator sends the update information for transactions that have been completed within the transmission interval to the target system, where the update information is imported in the order the transactions were committed. Therefore, a transaction that is not completed within the transmission interval might be sent to the target system after a transaction that occurs later. In such a case, the order of update processing might not match between the source and target databases.
• If the source HiRDB is a parallel server, the source Datareplicator extracts and transmits update information for all back-end servers in parallel. Therefore, the order of update processing among the back-end servers is not predictable. Conformity between the source and target databases is guaranteed when all update information has been extracted from the system log files at all back-end servers, sent, and imported into the target database.

If you start the source system in the initialized status, start the target Datareplicator with the hdsstart -i or hdsstart -i -D command. If you start the source Datareplicator using the partial initial start mode, use the hdsstart -i or hdsstart -i -D command to start the target Datareplicator corresponding to the specified destination. If you start only the source system in the initialized status, the KFRB02003-E error results (detail code 5).

If you specified nocheck in the extract_init operand in the import environment definition, there is no need to start the target Datareplicator in the initial start or partial initial start mode.

Even if an event code sent from the source system is undefined in the import environment definition, there is no effect on the import processing; the target Datareplicator still recognizes it as an event.

If you specify the HDE_BIN_COL_MAXLEN environment variable (in kilobytes) in the source Datareplicator, you can perform data linkage on BLOB-type columns that have a definition length of 2 GB or greater but whose actual data is small without having to redefine the table. If the source Datareplicator detects a BLOB-type column that is longer than the definition length specified in the HDE_BIN_COL_MAXLEN environment variable, the source Datareplicator performs the following processing:

• Replaces the data in the corresponding BLOB-type column with the null value, and then imports it to the target Datareplicator.
• Outputs information about mapping keys from the update information resulting from the null value replacement to a file.

The following explains the file that is output.

File name and output destination:

The file is created under the name warn_keyinfo.BES-name.target-name in the source Datareplicator directory (directory specified in the HDEPATH environment variable). If the source database is in a HiRDB/Parallel Server, the file is created in the source Datareplicator directory on the machine that contains the back-end server in which is located the BLOB-type column that exceeds the definition length specified in the HDE_BIN_COL_MAXLEN environment variable.

Contents of the file

The following shows an example of the contents that are output to the file:

Note:

• Delete this file manually before the source Datareplicator starts. If the file then exists when the source Datareplicator operation has terminated, it means that a BLOB-type column that is longer than the definition length specified in the HDE_BIN_COL_MAXLEN environment variable was detected.
• Information about the mapping key columns is output during transmission processing. If an error occurs during transmission processing, information about the mapping key columns that has been output once might be output again when transmission processing is restarted.