Replicas in a geodatabase in Db2
You can use geodatabase replication to create copies of data across two or more versioned (traditional) geodatabases so that changes to the data can be synchronized. A synchronization involves one replica sending data changes and the relative replica receiving changes.
Before you create a two-way or one-way replica, you must add a GlobalID column to the datasets to be replicated. This gives the rows in the dataset a unique value that will remain constant across geodatabases. (For details on getting a dataset ready for replication, see Preparing data for replication.)
After changes have been made in one of the replicas, you can synchronize the geodatabases, bringing the changes made in one geodatabase into its relative geodatabase. When a geodatabase is synchronized with its relative geodatabase, a table is created in the user's schema of the replica geodatabase (the one that is sending the changes to the relative geodatabase) to track the lineages of altered datasets.
Replica tables in a geodatabase in IBM Db2
Before datasets can be replicated, they must have a GlobalID column and be registered as fully versioned (not registered with the option to save edits to base). Therefore, in the database, the business tables of any datasets that are included in the replica have a GUID column and delta tables.
Replicas are tracked in the database in the GDB_ITEMS, GDB_ITEMRELATIONSHIPS, and GDB_REPLICALOG geodatabase system tables. The fact that it is a replica is recorded in the GDB_ITEMTYPES system table. See System tables of a geodatabase in Db2.
The tables are related as follows:
Dashed lines indicate implicit relationships between columns.
When synchronization is performed between two geodatabases, a temporary table is created to track dataset lineages.