Working with rule sets
DDL replication is supported in the CDC Replication Engine for Oracle databases and the CDC Replication Engine for DB2® for LUW for tables specified through rule-based selection. This is achieved through the creation of rule sets within a subscription, which are then used to determine the tables that will have DDL operations replicated. For tables matching rule sets, both the data within the tables as well as the structure of the tables will be replicated as they change
When you start replication for a subscription, the subscription's rule sets are used to determine which tables will be in-scope. Replication for all tables in the subscription that satisfy the rules criteria will begin with the target table being dropped (if it exists) and created. This is called a structural refresh. This is then followed by a normal data refresh. Mirroring of both data changes and structural changes will begin after the refresh is complete.
Rule sets are defined on a per-subscription basis. That is to say that they are defined within, and belong solely to, a selected subscription. You can define multiple rule sets within each subscription.
When replicating DDL operations using the CDC Replication Engine for Oracle databases, subscriptions can contain both Rules-based mappings for DDL replication and the standard InfoSphere® CDC mappings (called Direct Mappings) for DML-only replication. However, when replicating DDL operations using the CDC Replication Engine for DB2 for LUW, subscriptions cannot contain both Rules-based mappings and Direct Mappings; each subscription can only contain one type of mappings.
The Table Mappings view will show a separate display for each type of mapping. Just like subscriptions containing Direct Mappings, subscriptions containing Rules-based mappings (or combinations of Direct Mappings and Rules-based mappings) can be copied, promoted, exported and imported.
Each rule set identifies a pool of tables from within a single schema; the tables are selected either by exact name or through a pattern. Individual tables can be chosen to either be included or excluded from replication. Patterns can be defined to include or exclude tables that match the criteria.
A simple example of pattern-based identification for a rule set would be as follows:
- Tables to include: A*, B*
- Tables to exclude: *C
The returned result would be that all tables whose names begin with the letter A or the letter B, whose names do not end in the letter C in the selected schema would be in-scope for replication.
The evaluation process is performed on each rule set independently and in no particular order (there is no order of precedence for rule sets). As each rule set is evaluated, the tables that match the criteria are added to a pool. As each rule set is consulted, the pool is augmented by the tables that match it's criteria. If there are multiple rule sets, a table must match only a single rule to be included in the pool; a table doesn’t have to match all the rules to be included. Tables will not be removed from the pool once added and tables will not be added multiple times to the pool.
When you are defining a rule set, you should consider the following issues:
- Understand your logic fully when creating your patterns and table lists. You should make sure that the conditions set in the various rules are not contradictory.
- You should consider not just the tables that currently exist that will match the rules, but also the tables that the rule set will match in the future.
- You should also consider the rules defined for other subscriptions replicating to the same target database and verify that there is no overlap. A table targeted for DDL replication cannot be involved in any other CDC Replication table mapping, either Direct Mapping or Rules-based.
- When you are creating patterns for your rule sets, keep in mind that patterns are case-sensitive.
- All DDL replication actions for tables in Management Console are based on the table name, not the Source ID
You can only create or modify rule sets while replication is not active.
If you want to arrange the order in which the tables will be refreshed, you can set the Refresh Order and move the tables that are in-scope for replication into groups. Refresh order, in the sequence you chose, will be performed before mirroring begins.
You can set the capture point for tables that are included in a rule set. If tables are marked as Mirror/Active, CDC Replication will assume that the target table is synchronized with the source table at the time that the capture point is marked, so there is no need to do a refresh.
You can see what the rules evaluate to before starting replication by previewing the tables that will be in-scope for replication. Management Console will display a list of the tables that satisfy the rule set criteria at the current moment. That is to say, what is actually in the database at the moment the preview occurs; changes in the database may result in the list of in-scope tables being different at the moment that replication is actually started than it was when previewed.
Please note the following limitations for subscriptions that have rule sets defined:
- You cannot manually park tables in a Rules-based mapping.
- A Direct table mapping takes precedence over a Rules-based mapping for that table. Tables in a Direct mapping are excluded from DDL replication.
- DDL replication is not available for tables with Direct Mappings.
- Replication of tables with interval partitions is supported only for Rules-base mappings, not Direct mappings.