MIMIX manages referential (foreign key) constraints on replicated files on the target node when a data group associated with an application group is created with shipped default values or has been converted to use multithreaded database apply processing.
When a data group is configured to allow target constraint management and uses multithreading, *FILE objects that are constrained together and are properly configured for replication are assigned to apply session B and its associated multithreaded job. In the grandfathered scenario where single-threading is used, the constrained files can be assigned to different apply sessions, which are assigned when the data group is started with a request to clear pending activity entries.
Constraints are managed only on target files replicated as the result of configuration selection rules (entries) that meet requirements for cooperative processing from the user journal. To be eligible, the corresponding source files must be identified by the following at the time that the clear pend start is performed:
-
Data group object entries must specify *ALL or *FILE for Object type (OBJTYPE), *YES for Cooperate with database (COOPDB), and either *DFT or *FILE for Cooperating object types (COOPTYPE).
-
Corresponding data group file entries must exist for the files identified by the object entries.
When the database apply processes are started, MIMIX disables foreign key constraints on the target node for all *FILE objects identified by file selection rules (data group file entries). The constraints remain disabled when replication processes are ended, but you have the option to allow them to be enabled.
Any MIMIX-disabled constraints must be enabled before performing a switch. MIMIX-disabled constraints are automatically enabled by steps included in the shipped default procedures SWTPLAN, SWTUNPLAN, and RUNBACKUP. In other procedures, such as END or ENDTGT, you may need to enable the appropriate step programs to enable constraints. However, you may need to enable constraints outside the scope of a switch procedure. Examples of when this may be necessary are before manually switching a data group with the Switch Data Group dialog (SWTDG command), or before performing other operations for which you would want constraints enabled on the target node, such as running a backup from the target node. You can use the Stop Data Group dialog (ENDDG command) to optionally enable constraints.
Also, when a virtual switch includes a data group that uses target constraint management, the virtual switch procedure SWTVRT ensures that any disabled constraints remain disabled when the virtual switch recovery ends and normal replication processing continues.
For more information about enabling target constraints, see topic “Enabling MIMIX-disabled target constraints” in the Assure MIMIX Operations book.
Considerations for using target constraint management. MIMIX-managed constraints can improve performance of the database apply process performance in high volume, performance-sensitive environments that have previously established networks of constrained files that do not frequently add or remove constraints or do not frequently create or delete files with constraints.
Files that are constrained together need to be replicated by the same data group. If constraints are added between files replicated by different data groups, or between a replicated file and a file that is not replicated, constraint operations may fail.
To support replication of creates for new constraints, the database reader (DBRDR) process considers foreign key relationships when determining the apply session to which the file will be assigned.
Configuration requirements. Allowing MIMIX to perform target constraint management is a requirement for multithreaded database apply processing, which is supported only in data groups that are associated with a resource group and application group. Data groups that do not use multithreading cannot configure MIMIX-managed constraints.
Shipped default values for a new data group automatically default to values required for target constraint management and multithreaded database apply processing.
An existing data group can be changed to use target constraint management only when its associated resource group is converted to multithreading.
A controlled end of replication processes is required before changing the configured value of target constraint management for a data group. Replication processes for the data group must be stopped (*INACTIVE), and the data group cannot have any open commit activity at the time of the configuration change.
A clear pending start of the data group is required after changing the configured value of target constraint management.
Behavior during a planned or unplanned switch: The shipped default procedures for switching application groups (SWTPLAN and SWTUNPLAN) automatically check for and attempt to enable any target node constraints disabled by MIMIX steps Enable foreign key constraints previously disabled (MXECSTB and MXECSTR). This ensures that target node files will match their source node settings when the procedure stops appropriate replication processes. In addition, before the actual switch processing occurs, steps Checks data group for constraints disabled by MIMIX (MXCKDCSTB and MXCKDCSTR) check for any remaining MIMIX-disabled constraints as one of the conditions to end the switch.
When you start replication processes on the new primary node following the switch, database apply processes for data groups configured to allow target constraint management will disable constraints on the new target node.
Behavior during a virtual switch: The shipped default procedure for a virtual switch (SWTVRT) of an application group checks for MIMIX-disabled constraints as one of the conditions that will end the switch (step Checks data group for constraints disabled by MIMIX (MXCKDCSTB and MXCKDCSTR).
When the virtual switch testing phase starts, steps Enable foreign key constraints previously disabled (MXECSTB and MXECSTR) enable any target node constraints that were disabled by MIMIX.
When the virtual switch recovery phase starts, step Disable constraints for virtual switch recovery (MXDSBCSTV) disables all foreign key constraints on the target node regardless of the data group’s value for target constraint management. When the virtual switch recovery ends and normal replication processing continues, constraints remain disabled for data groups configured to perform target constraint management. If the data group configuration does not allow target constraint management, step Enable constraints after virtual switch recovery (MXENBCSTV) enables target node constraints.
Switching in data group-only environment: When switching in environments that only use data groups, the Switch Data Group dialog (SWTDG command) provides the ability to check for the existence of constraints previously disabled by MIMIX. This condition may exist if the data group was previously associated with an application group. The default value for the Conditions that end switch (ENDSWT parameter) will automatically check for this condition in a planned switch request. You can also explicitly specify the value Disabled Constraints (*DSBCST).