Database objects

Objects that are used for working with the database are eligible for replication unless otherwise noted.

The support for inclusion and exclusion from replication is granular. When you create a replication strategy for database objects, you can select a subset of objects to replicate from a specific database dependency network. If you choose to exclude a portion of the dependency network, you are responsible for managing object level changes for the excluded objects between the nodes. The best practice is to fully review object dependencies for each database network of objects and include all database objects in replication if any of the objects require replication. The all or none strategy for database replication will prevent confusion or failures related to dependent objects being dissimilar on the two nodes due to a portion of the network being excluded from replication.

Since objects that depend on each other are frequently in the same library, one way to include all the objects in a database dependency network is to add the library that contains the objects to the Replication Criteria List (RCL) with an include rule.

Replication for some dependencies, such as referential integrity, is required by Db2® Mirror. The enforcement occurs at runtime.

Some dependencies are not enforced and can lead to unexpected behavior. For example, you could have DATALIB and VIEWLIB libraries and choose to only replicate the VIEWLIB objects. Db2 Mirror allows this usage, but will not synchronize the data within the DATALIB objects, nor manage the views in VIEWLIB on both nodes as the physical files in DATALIB are altered.

Other situations to be aware of include:
  • Objects referenced in SQL code bodies, such as procedures and functions, are not required to be replicated. This can cause unintended objects to be used. For example, referencing table T1 using the library list could find a completely different T1 on each node.
  • If a subset of database objects is included in replication in a library, differences and potentially failures could be encountered if long SQL names are used for objects and the system names for those objects are not specified on the create statement. For example, if the SQL table LONGTABLENAME is created without the FOR SYSTEM NAME LONGT1 clause, the database generates a system name like LONGT00001, using the first available object name on the source node. The generated name is not guaranteed to be consistent between the nodes for any object that is not replicated. Views rely on the system name for a table reference, so could end up using different tables on both nodes.

    To avoid this concern, include all database objects within a library in replication or strictly control the system names for database objects.