0

I have a table with both source and target as IBM DB2 iSeries. The replication method is Mirror. After refresh before mirroring, the message Table <lib>/<table> should already have been refreshed. Transformation Server will terminate. occurs and the state of table stays as Refresh. Other tables in the same subscription are running normally. Below is the detailed log:

source

  1. Table lib/table, member table will be refreshed to subscription.
  2. Table lib/table, member table refresh to subscription is complete 200000 rows sent.
  3. Table lib/table member table could not be refreshed.
  4. Table lib/table should already have been refreshed. Transformation Server will terminate.

target

  1. Refresh started for target table lib/table, member *ONLY.
  2. 220310 rows deleted from member *FIRST of table lib/table.
  3. Refresh completed for table lib/table, member *ONLY. 200000 rows received, 199500 rows successfully applied, 500 rows failed.

Does anyone have any ideas towards this kind of situation?

lke
  • 73
  • 6

2 Answers2

0

May be seeing the job log would give more clarity as what is the cause for this behavior, as this could happen in many reasons. One of the thing that can be try is, in Management Console select mapped tables

  1. parked the table
  2. Flag it to Refresh and start subscription it will refresh the table and enters into "Active" state.

Thanks

sudarshan K
  • 1
  • When you don't have a definite answer, giving suggestions to the OP ("original poster") on what to try next are usually more appropriate in a comment to the question than in an answer-- assuming you have at least 50 rep to be able to comment. But you can always suggest an edit ("Maybe you could include the log here for more clarity") with only 1 rep. – Christopher Hamkins Oct 21 '21 at 09:35
0

CDC iSeries will try to get a very short exclusive lock (allow read) to ensure that the there are no uncommitted commit cycles involving the table at the time that the refresh starts. if it cannot get a lock then it skips the refresh, moves on to the next table, posts the message that you have reported. So you will need to run the refresh of the table at a time of low activity on the table (or no activity). This lock is required to ensure consistency if the source application is updating the table under commitment control, as the journal scraper would otherwise ignore any transactions belonging to a commit cycle that started before the refresh itself started. If the source application is not using commitment control at all and the iSeries is the only source then you can get the target to ignore commitment control. The source will then know not to try the lock. To turn off commitment control for a Java-based target add the target system parameter mirror_commit_on_transaction_boundary and set it to false, if the target is iSeries change the target commitment control parameter to *NONE. Please be sure that commitment control is not used at all if you make this change on the target as otherwise you may have some troublesome synchronisation issues if changes are rolled back concurrent with a table refresh

Robert Philo
  • 16
  • `add target system parameter mirror_commit_on_transaction_boundary and set it to false` solve the issue. Thank you. – lke Feb 24 '22 at 10:36