Replicate quits pulling from iSeries journal after a couple hours of running.

[Benrie]

The company I work for recently installed Replicate and I am trying to figure out why it quits processing the changes after a few hours of running.  We are replicating the data from an iSeries with journaling to SQL Server.  I reload all tables within the task successfully and the task is in run status.  It picks up changes for a few hours during the day but then all of a sudden stops.  The logs don't show anything unusual happening and basically just state the task is running every 10 minutes.

[Barb_Fill21]

@Benrie  - Can you put the source_capture to verbose for 5-10 Minutes only and move it back to INFO afterward?

And review the log. Does it show something like "No Data  - Wait"?  If so it seems that maybe the receiver files have "moved on" and Replicate may not have.  Could be DB2  maintenance, check with the DBA. But it could be that you need a heartbeat table set up,  to keep Replicate actively looking at the logs(journal receivers).

Let me know what you see. 

Or you can open a case and attach a Diagnostic package for a more in-depth analysis of what's going on. 

Sincerely,

Barb

[Benrie]

I made that change but the next time through it states the same thing in the log "Task is running" with nothing else.  Just a single statement.  Do I have to stop and restart after making that task logging change?

[Benrie]

I also checked the journal receivers for the journals on the tables that are being updated and none of them switched over at the time the last transaction went through.  So I don't think it's receiver related if that helps.

[Barb_Fill21]

@Benrie  Can you set the Source_capture to Verbose for ONLY 5 minutes during the time this happens?

Then set the logging back to INFO. ( don't forget) 

I would recommend you open a case and attach the new Diagnostic Package. 

You might need a heartbeat table but I need to see the logs and the Task JSON to see what the issue is. 

Sincerely

Barb

[Benrie]

I actually did do the source_capture change with no difference in the logging that I could tell.  I'm new at this so not sure if what I did or looked at was accurate.  I am currently working with Ted Alexander to see if he can help figure out what is wrong.  But wanted to ask on here also to see if anyone else had a similar issue.

[Bill_Steinagle]

Hi,

Thank you for the post to the QDI Forums. As noted by Barb's update depending on how long the Task took to reload the Tables did you also check the retention period of the Journal/Receivers how often they are archived and or detached from the DB2i environment? Replicate has no control over the switching of the receivers during processing other than the stream/sequence position we keep track of in the replicate\data\task\sorter directory while the load is running. Would ask DBA the retention policy for these journaling on the Source. 

Thanks!

Bill

[Benrie]

I did check if the receiver had disconnected and created a new one during the test.  It did not.  So if the receiver does get disconnected how do we make sure Replicate picks up with the new receiver?  

[Bill_Steinagle]

Hi,

I would stop the Task and Resume as if the sequence was rolled to the next receiver the DISPLAY_JOURNAL query we pass to the DB2i should pick it up. It could be also a timing issue with the Task/Retention and or any Maint being done on Source as well. Best approach is SOURCE_CAPTURE set to VERBOSE will see the DISPLAY_JOURNAL which will show the receiver the sequence we are querying (events) from that receiver as shown in example below.

Note: I would also check if the DB2i is running any Journal Maint eg: “Apply Journaled Changes (APYJRNCHG)” is applicable to Replicate’s use of DISPLAY_JOURNAL.

Thanks!

Bill

[amit-lamba-ns]

Hi @Barb_Fill21 , 

Like you mentioned above, can you please help me in understanding how and where we can setup heartbeat table. How we can align this table along with Cdc table ? 

Thanks,

Amit Lamba