What happens during model update - Connect_CDC - connect_cdc_mimix_share - 5 - 5.8

Connect CDC Advanced User Guide

Product type
Software
Portfolio
Integrate
Product family
Connect
Product
Connect > Connect CDC (MIMIX Share)
Version
5.8
Language
English
Product name
Connect CDC
Title
Connect CDC Advanced User Guide
Copyright
2023
First publish date
2003
ft:lastEdition
2023-09-27
ft:lastPublication
2023-09-27T18:12:55.651884

The table below describes what happens during Model Update:

Step

Incremental Model Update

Full Model Update

  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.

4. Waits for the queues to drain.
  • Analyzes the queues to determine the requests currently in the queues. It builds up a list of affected requests, that is, requests for which the modified tables are the source. While waiting for the queues to drain, the kernel only waits as long as rows belonging to these affected requests are in the queues. As soon as these rows have drained, the rest of Model Update proceeds.

  • Only requires the affected requests to be active. Requests that the model commit does not affect need not be running even though they may have data in queues. For full Model Update, all requests are affected so all requests that have data in the queues must be active. The kernel waits for the entire queue to drain before proceeding with the rest of the Model Update activities.

5. Shuts down all active requests.
  • For Copy requests, waits for a short time for Copy to end normally. If Copy does not end, it is shut down.

  • Replication requests are shutdown.

  • For Synchronization requests in their Copy phase, the rules governing Copy requests apply. For Synchronization requests in their Replication phase, the rules governing Replication requests apply.

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).

You see Alert messages about the activities in the message section of the window. You also see a graphic next to the menu bar that indicates a Model Update is in progress.