Takes LONG time to reload target

[PerJansdal]

We tested a total reload of our SQL-servers from MainFrame DB2 with replicate  "version": "7.0.0.356" it took about 3 hours.

We then upgrated to "version": "2021.11.0.165" the reload time is now about 8 hours.

The environment is the same.

What do we have to think about?

Regards Per Jansdal

[Pedro_Lopez]

Hello Per Jansdal,

From the description it could be due to some reasons that the load time took more than the previous version. Are the endpoints pointing to the exact same DBs and is the data volume the same for both runs? 

I believe it would be best to troubleshoot this if you create a case on our support portal, please attach the task's diagnostic package to the case from both versions (7.0 and 2021.11) if you still have them.

Kind regards,

Pedro

[KellyHobson]

Hey @PerJansdal 

I agree with Pedro, this may be a good candidate to open a case to compare 7.0 to 2021.11.

A few other ideas to consider:

1. Is it the same number of tables in the task?

2. Have the task settings related to Full Load tuning been modified? Task Settings -> Full Load -> Full Load Tuning

3. Was the full load run at the same time of day / time of week? It's possible it is taking longer if it is a busy time on the source side and its waiting for open transactions to be committed.

4. You can test task with a null target to narrow down whether the slowdown coming from source or target. i.e if you test a null target and it loads at expected speed then there may be something going on with target endpoint.

https://community.qlik.com/t5/Knowledge/Null-File-Target/ta-p/1737871

Thanks,

Kelly

[Heinvandenheuvel]

This is unlikely to be caused by a Replicate upgrade as the core algoritmes did not change.

8 hours vs 3 hours is a significant difference. You 'll need to dig deeper to see whether the degradation is across the board, or perhaps is related to a specific table. 

Are the full-load details still visible in the GUI? Sort by descending "Load Duration" for a starting point. Sort by descending finish time to see which tables came in last.

Where there perhaps (excessive) errors being logged during the last reload

Is the attrep_history table enabled for the task under metadata - control tables? If not, switch it on for the future. If yes, then it is now time to see if it provides any detail like a slow hour in somewhere during the load.

I recommend you start looking carefully at the reptask_xxx.log file at least for the last log, and ideally compare that with a 3 hour run. You'll be able to see how many sub-tasks were running in parallel. Did that change?

if all the reptask logss are there, notable for a 3hr runs, I have some scripts which can sift through them and present a timeline for help to learn where to start looking.

Do you have tasks exports from around the time the 3 hr load was run and now? (you should have those!) . Compare them!

hth,

Hein.

[Barb_Fill21 · Accepted solution]

@PerJansdal 

As I support the Db2z/OS endpoint, I am suspecting the target may be your issue. 

You can always get an ODBC tool installed on the Replicate server and run the same queries to see how long they run.  The way to find the queries is to put Source Unload and Target Load to Verbose for only 2-3 minutes and then immediately put them back to INFO.

We're doing essentially a Select * from the source so it will be as fast as DB2Z can deliver it. Typically the issue is on the target side being so busy... trying to keep up with the mainframe ( because the mainframe is like a rocket and usually sends the data faster than the target can handle)  🙂 

Let us know.

Sincerely,

Barb