View Issue Details

IDProjectCategoryView StatusLast Update
0003736SymmetricDSBugpublic2018-10-03 17:29
Reporterjayvaughn Assigned To 
Priorityhigh 
Status closedResolutionno change required 
Product Version3.9.13 
Summary0003736: may or may not be bug - data replication bombing when changing pk_data field in sym_data
DescriptionWe are having a performance issue with a single table. We are replicating a DB2 table (which consists of 306 columns) to an sql server table. The symmetric DS tool has attached its own trigger onto the DB2 file, however this causes a big delay in the I/o processing to carry out the trigger processing. So we developed our own table trigger to write the changed row info to sym_data.
1.) the original trigger was putting changed row data into row_data and old row data into both pk_data and old_row... this allowed replication to execute however if source/target tables got out of sync, no more updates could be applied (naturally)
2.) when we change the trigger pgm to output the key field info only to the pk_data as the symmetricDS literature suggests, we get an exception error. I am the iseries developer and our offshore team is handling the administration/configuration of the tool.
What could we be missing in allowing the tool to work only with the key data fields instead of the entire row in pk_data?
TagsNo tags attached.

Activities

jayvaughn

2018-09-26 17:33

reporter  

symmetricDS.jpg (65,254 bytes)   
symmetricDS.jpg (65,254 bytes)   

elong

2018-09-28 18:12

developer   ~0001245

So you're using a custom trigger to populate sym_data, but SymmetricDS gets an exception when processing it. What is the exception?

Did you try using the sym_trigger.stream_row = 1 feature? It captures only the PK values for the table, which makes the trigger very efficient. It will query for the row during extraction instead.

jayvaughn

2018-09-28 18:18

reporter   ~0001246

we got it working using our custom trigger on the iSereis...

when we output to sym_data we first make sure that the max(trigger_hist_id) in sym_trigger_hist contains ONLY the key values in sym_trigger_hist... if not, the trigger goes ahead and updates PK_DATA with those column names only... it then carries that trigger_hist_id over to sym_data when it inserts the changed row data... this has provided success for us and the results we need (since I put the original issue in your system)... are there any pitfalls to look out for this method?

this table has 306 columns and the default symmetricDS trigger was just taking too long... our new trigger submits the request to batch (and does the above method)...

Issue History

Date Modified Username Field Change
2018-09-26 17:33 jayvaughn New Issue
2018-09-26 17:33 jayvaughn File Added: symmetricDS.jpg
2018-09-28 18:12 elong Note Added: 0001245
2018-09-28 18:18 jayvaughn Note Added: 0001246
2018-10-03 14:25 hanes Status new => feedback
2018-10-03 17:29 hanes Status feedback => closed
2018-10-03 17:29 hanes Resolution open => no change required