Document TypeㅣTroubleshooting
CategoryㅣAdministration
Applicable Product Versionsㅣ6FS06, 6FS07
Error Codeㅣ15104
Document NumberㅣPADTS003
Issue
In ProSync 4.0, when renaming a synchronization target table, a 15104 error occurs in the extraction log (ext), and synchronization is interrupted.
[02-10T13:15:36.336460] [REA-04] [E] trigger execution failed (seq#:29, error:ALTER TABLE PART.PART (TBR-15104: No matching data found. )) [prs_ext_dd.c:835]
Cause
ProSync 4.0 does not support renaming; thus, when renaming a synchronization target table, an error occurs in the extraction log, and synchronization is interrupted.
Solutions
Since ProSync 4.0 does not support renaming, you need to first remove the table from synchronization targets, then rename the table, and finally re-add it.
[Example] Procedure after renaming the existing synchronization target table PART.PART to PART.PART_BAK
1. Connect to the source server as the ProSync user and update the status column with value 100 to 1 in PRS_DDL_HIST.
- Load is not possible for failed DDLs where the status column in the PRS_DDL_HIST table has values other than 0/1/2 (for sites, 100 is used).
- 0: Before DDL start, 1: DDL completed successfully, 2: DDL failed, SQLCODE: error number
SQL> select * from prosync_xx_to_us.prs_ddl_hist;
DD_SEQ# TSN STATUS MESSAGE
---------- ---------- ---------- ---------------------------------------------------------------------------------------------------------
29 10775520 100 ALTER TABLE PART.PART (TBR-15104: No matching data found. )
SQL> update prosync_xx_to_us.prs_ddl_hist set status=1 where dd_seq#=29;
1 row updated.
SQL> commit;
Commit completed.2. Add the renamed table (PART.PART_BAK) to the synchronization targets.
$ prs_adm Admin> alter XX_TO_US add table PART.PART_BAK group=1; Table 'PART.PART_BAK' added.
3. Remove the original table (PART.PART) from the synchronization targets.
$ prs_adm Admin> alter XX_TO_US del table PART.PART group=1; Table 'PART.PART' deleted. You should drop supplemental log.
4. Verify that the renamed table (PART.PART_BAK) is synchronizing properly.