Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
SkippyTheMagnificent
Contributor II
Contributor II

Unable to get delete statement

All

Had a replicated table get suspended today with the following error:

Failed to get delete statement for table SIPMiner.RESULTS, stream position 411;637889683643563270;20220419144516826916|0000001b.347cb822.00000002.0000.01.0000:10873.2961722.16

How do I troubleshoot and resolve this so I can unsuspend the table without losing any data?

Appreciate the help

Nathan

Qlik Replicate 

Labels (2)
1 Solution

Accepted Solutions
lyka
Support
Support

Hi Nathan,

unfortunetaly the only way to resume from a suspended table is to reload.

what i think you can can try to do is to create a separate task just for this table and start from timestamp.

thanks
lyka

View solution in original post

15 Replies
KellyHobson
Support
Support

Hey @SkippyTheMagnificent ,

What is your source and target endpoint?  If you are able, can you attach a diagnostic package or a log at the time of the error to this thread? 

Ref: https://community.qlik.com/t5/Knowledge/How-to-collect-Diagnostics-Package-from-Qlik-Replicate/ta-p/...

Great handle name by the way!

Best,

Kelly 

lyka
Support
Support

Hi Nathan,

unfortunetaly the only way to resume from a suspended table is to reload.

what i think you can can try to do is to create a separate task just for this table and start from timestamp.

thanks
lyka
Heinvandenheuvel
Specialist II
Specialist II

If the task gets to the 'get delete statement' it has already gotten the metadata for the table.

My guess is that the metadata was not useable, possibly because a PK was expected but no PK was found?

Was the (target) table (metadata) changed behind Replicate's back - maybe while the task was running?

Did this ever work for any row? I don't think this is triggered by a surprised data values but I suppose that could be with funny characters in the key column values perhaps - wag!

Can you isolate the table in a test/dev task and run with maximum logging for details?

You may need repctl dumpmetadata output to figure this out.

Hein.

SkippyTheMagnificent
Contributor II
Contributor II
Author

Source is Oracle 19c.  Target is SQL Server 2019.  Table is 'Results'

Diag package attached.  

 

SkippyTheMagnificent
Contributor II
Contributor II
Author

This is disappointing.  800m record table.  Would really like to understand what went wrong before I reload to see if there are things that can be done to prevent the same issue from occurring again.

Nathan

Steve_Nguyen
Support
Support

 

@SkippyTheMagnificent
 

- look like your task is using Logstream, so the CDC come from the parent task. 

- the full load come from the source. so the error look like from CDC.

- so best to run with source_capture , target_apply, target_load to get more information , if issue happen again.

- make sure you are latest kit, 2021.11 sp5 or new 2022.5 kit

 


 

Help users find answers! Don't forget to mark a solution that worked for you! If already marked, give it a thumbs up!
SkippyTheMagnificent
Contributor II
Contributor II
Author

No known changes to either source or target table.  Defintions still match.  Been working for weeks.  Over 11m DML statements applied before the error occurred.  No errors in the attrep_apply_exceptions table either.  

Not used the repctl command before.  Where can I find some documentation on it?

 

 

SkippyTheMagnificent
Contributor II
Contributor II
Author

Running 2021.5.0.863 build.  

I'd agree issues was with CDC.  

 

Steve_Nguyen
Support
Support

@SkippyTheMagnificent
 

1, kit look ok.

2. try to set trace to get more info.

3. repctl command are only for export and import / if you look for API, look into QEM API.

 


 

Help users find answers! Don't forget to mark a solution that worked for you! If already marked, give it a thumbs up!