Modify Records takes hours to complete

Hello everyone,

Don’t know if this is the right place to post my question but here it goes.

I’m using OEID 3.1 .
I want to update my records in my Data Domain to replace the values in a new column that I’ve created previously in Endeca.
The query gets my elements and order them in 1-3 minutes top (with 3.2 M records) but when it reaches the modify records components, it takes hours and hours to modify the records.

I noticed that it gets stuck on specific values for a lot of time and then it moves on, happening again in other records. Why is this happening ?
The number of records are the same and I’ve tried a lot of different ways but this is happening every time.

Here’s the code if you want to check it out.

Many thanks everyone.
Regards and have a good week.

<?xml version="1.0" encoding="UTF-8"?>

<![CDATA[select pcodigo, stg_val_cc(pbi, codigo_cartao_cidadao) as CC_VALIDA, stg_sugestao_cc(pbi, codigo_cartao_cidadao) as SUGESTAO_PBI from pessoas where nova_pessoa=0]]>

Dear aiaimanel,

As this issue relates to Endeca Data Integrator please do contact Oracle Endeca support in this matter directly. They need to be informed about this issue and will work with us directly if needed. Thank you for your cooperation!

I can give you some general tips how to find performance bottleneck:

* try to put each component into separate phase so you will see in run log which component is the slow one
* use FastSort instead of ExtSort, or tune parameters (http://www.cloveretl.com/blog/sorting-d … -fastsort/)

I hope this helps.

I don’t know Endeca much, but judging from your graph - the modification happens inside Endeca specific component - “ENDECA_MODIFY_RECORDS” which has to connect to Endeca server over network. So I would be looking into the performance bottleneck inside Endeca Server or check the network connection.

But as stated before - this is Endeca specific, the component has been created by Endeca team. The CloverETL team does not have visibility into this.

The suggestion about splitting into phases is valid though - it should help verify that the problem lies in the Endeca specific component.