Document Type | Issue Resolution
Category | Administration
Applicable Product Versions | 5SP1FS01, 5SP1FS02, 5SP1FS03, 5SP1FS04, 5SP1FS06, 6FS01, 6FS02, 6FS03, 6FS04, 6FS05, 6FS06, 6FS07, 6FS07PS, 7FS01, 7FS02
Document Number | TADTS008
Issue
During synchronization from Oracle to Tibero via ProSync, the PRS_LCT table was not updated properly.
NoteThis issue was observed in the following environment.
Product: Prosync Version: 4.4.0
prs_lct Query Before Insert
SQL> alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss'; Session altered. SQL> select * from prs_lct; TSN TIME GROUP# ------- ------------------- ------ 8951525 2024/11/25 05:24:36 1 1 row selected
Insert and Data Synchronization Verification
The left session shows the source (Oracle) and the right session shows the target (Tibero).

prs_lct Query After Insert
The time and tsn should be updated to the post-commit timestamp, but they remain the same as before synchronization.
SQL> alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss'; Session altered. SQL> select * from prs_lct; TSN TIME GROUP# ------- ------------------- ------ 8951525 2024/11/25 05:24:36 1 1 row selected.
Cause
The 48-bit SCN value extracted from Oracle DB requires a >> 16-bit shift operation internally for use.
However, this operation was performed redundantly twice: once during the extraction in the ext stage and again when updating the PRS_LCT table during the apply stage, causing the TSN value mismatch.
As a result, it was incorrectly determined that the table update was unnecessary, leading to data that should have been applied not being updated.
Solutions
Apply the Prosync FS03_336052a patch to resolve the issue.
CautionApply the patch through technical support provided by TmaxTibero.