A bug exists in the OE Replication product since OE11.7 where the metadata stored in after-imaging data structures in memory and in the recovery log notes on disk, that is used for determining the earliest sequence AI extent of the local database required for bringing the other target database to synchronization, is not of fine enough granularity such that it can lead to ambiguities with respect to which AI extent is the minimum required for synchronization.  When this bug manifests, the replication agent can get (1028) system error during or following a resynchronization, necessitating a rebase of the affected replication target database. 
              

The specific following sequence of events will produce this error:
             
1.           TRID of last transaction started on both target databases is equal.
2.           TargetDB1 has applied more notes from this transaction than TargetDB2, resulting from a 'dsrutil -C applyextent' command.
3.           AI extent switch occurs on TargetDB1 following the applyextent operation.

              
The bug will cause TargetDB1 to incorrectly determine that the new AI extent, switched into in step 3, is the minimum sequence AIextent required to synchronize TargetDB2.  In some cases, there can be notes in the preceding AI extent that are required to synchronize TargetDB2.
             
The issue can span multiple AI extents.  That is, if multiple AI extent switches occurred on TargetDB1in step 3 instead of only a single AI extent switch, then, any notes written in those AI extents leading up to, but not including, the busy AI extent may be required for synchronization. 

The bug was discovered from automated internal testing where, prior to a two target recovery transition with replication-set enabled, the applyextent command was run on only one of the target databases, and the notes applied during the applyextent operation were from the same transaction that had last been started on both target databases.  A transition was then performed with the transition recovery backup performed online, where the AI extent switch occurred.

A bug was discovered in the OpenEdge Replication, replication-set feature where one or both of the target databases may incorrectly determine the earliest sequence AI extent of the local target database that would be required to bring the other target database to synchronization.

 

 

Code changes provided in the fix for OCTA-71376 makes the issue less likely to occur, under the circumstances described.

A full fix will require an architectural change to After Imaging to support increased granularity in some data structures used to govern After Imaging.

This type of change is done only at major version updates and, therefore, cannot be back-ported to LTS releases.

Best practice recommendation: Run the 'dsrutil -C applyextent' command on both target databases, with the same AI extents on both databases, prior to a recovery transition with replication-set.