JKM MSSQL Consistent at Lock Subscriber Step Retrieves Values of Another Subscriber in an ODI 11.1.1.7.0 Integration Interface at Runtime (Doc ID 1591875.1)

Last updated on JUNE 16, 2022

Applies to:

Symptoms

Incorrect information is retrieved for the Window Extend in SNP_CDC_SUBS when multiple Models of the same Logical Architecture use the JKM MSQL Consistent. In the case of one Model no problems whatsoever are observed. However, in the presence of at least 2 Models, the second one inherits the values of the first in the Window information columns of the SNP_CDC_SUBS table although there are two different Subscribers.

When a new Journal is added to the Model, the values in the above Repository tables should be -1, -1, -1 for the Window columns as is expected for one Model.

If then a Package executes an Extend Window/Lock Subscriber operation these values are modified as expected. The problem occurs if a second Model is added at this point to the Journal with a new subscriber; its values in the SNP_CDC_SUBS table instead of starting with -1, -1, -1, etc, they start with the latest value of the subscriber of the first Model.

Indeed this reproduces under the following situation:

1. Model1 from LogicalArchitecture1, with subscriber s1
2. Model2 from "same" LogicalArchitecture1, with subscriber s2.

When Extending the Window and Locking subscriber of Model1 the operation runs as expected. Then Extend Window and Lock Subscriber of Model1 several times.

Now if adding Model2 to the Journal, with s2, the SNP_CDC_SUBS table for line of subscriber s2 is filling columns:

  MAX_WINDOW_ID
  MAX_WINDOW_ID_INS
  MAX_WINDOW_ID_DEL

with values of SNP_CDC_SET but of subscriber s1 (instead of values -1, -1, -1, etc).

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.