What happens during model update - Connect_CDC - connect_cdc_mimix_share - Latest

1. Analyzes the delta XML files.

   • Determines which tables are being modified according to the delta XML files.
   • Determines to which request(s) these tables belong.
   • Determines if any of these requests are currently active.

✓

2. Blocks change capture.

• For log-based capture on UDB, Model Update puts the Change Selector in a drain state that prevents it from reading the redo logs (journals). Users are not blocked, and no loss of data occurs since the redo logs can be read later.

• For IBM i and for Oracle, Model Update shuts down the Change Selector.

• For trigger-based capture (Informix, MS SQL Server, Sybase), a blocking trigger, necessary to prevent data loss, prevents users from inserting, updating, or deleting rows in user tables. This impacts only the tables that are associated with the affected request. All other tables may continue to access these tables, thus continuing replication for all other active requests

3. If queues are not empty when model update is initiated, the kernel displays the list of requests it needs to drain and then starts waiting for the queues to drain.  It displays this list only if there is data in the queues that needs to be drained.

The message is in the form of an alert and shows up in the “Alerts” tab of the Connect CDC MonCon.

If Model Update fails because the queues did not drain, the list of requests that did not drain are also displayed through an alert.

✓

✓

✓

✓

✓

✓

6. Disables capture on all modified tables associated to this request.

Tables are determined in step 1.

Applied to all tables.

7. Performs the Model Update, loading in the new model. The version numbers are updated so that the new version number becomes the current number.

✓

✓

8. Enables capture on all tables associated to this request. This includes enabling capture on new tables added to a request if capture was enabled for the request prior to Model Update. If you add a server on a new host, Model Update does not automatically enable capture for the tables on the new server.

✓

✓

9. Removes any blocking triggers or enables log capture. On IBM i, Model Update restarts the Change Selectors.

✓

✓

10.Reactivates all requests that were forcefully stopped in Step 3, provided the request continues to be active in the new model. “Continues” Synchronization requests.

Some examples follow:

• If the request was dropped, Model Update will not re-activate it.

• Two replication requests that use the same source table cannot be active at the same time. If the updated model defined the requests in a way that violates this rule, Model Update will not re-activate them.

• You may selectively disable capture on some tables even when capture is enabled for a request. Model Update honors your preference and does not re-enable capture for these tables.For example, consider a model with a replication request “repl” having three source tables A, B, and C. Capture is enabled for request “repl” as described in the following stages:

1. Capture is enabled for all three tables.

2. b. Subsequently, capture on table B is disabled.

3. c. Next, a new model is committed in which request “repl” has one additional source table D.

4. d. The model is updated. Capture is enabled for A, C, and D (since D is new) but disabled for B (since that was a previous choice).

✓

✓