You can use geodatabase replication to create copies of data across two or more versioned geodatabases so that changes to the data may 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 global ID 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, consult 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 ArcCatalog and ArcMap
You won't see the table used for synchronization in ArcCatalog or ArcMap; it is used behind the scenes and only during synchronization.
You can, however, identify if a geodatabase is being used as a replica geodatabase by checking its properties in ArcCatalog. Right-click the geodatabase and click Properties. On the General tab, there is a Distributed Geodatabase Status section. If the geodatabase has been replicated or replicated to, the status states, This is a replica geodatabase.
In ArcMap, you know when an MXD file contains one or more layers that have been replicated because most (or even all) of the tools on the Distributed Geodatabase toolbar are active. Also, when you open the Replica Manager, one or more replicas are listed.
Replica tables in an Oracle DBMS
Before datasets can be replicated, they must have a global ID 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 will be included in the replication have a GUID column, and delta tables exist for each of these datasets. The following is a versioned feature class, Districts, that has a global ID column.
Replicas are tracked in the database using the following ArcSDE geodatabase system tables. Click the table names to link to their descriptions.
The tables are related as follows:
When synchronization is performed between two geodatabases, the table that is created to track dataset lineages is the SDE_UUID_TEMP$ table. This table can be used by multiple sessions simultaneously. In Oracle, the SDE_UUID_TEMP$ table is created as a global temporary table. The description of this table is below.
The SDE_UUID_TEMP$ table is used to discover the lineage of a given object via its global ID value.
||The versioned table's registration ID from the TABLE_REGISTRY table
||The global ID for the altered row in the business table of the versioned dataset
The following shows how one of the replicated datasets is related to the SDE_UUID_TEMP$ table:
The SDE_UUID_TEMP$ table is not removed when the session exits because the table will likely be reused in another session.
Replica tables in an XML document
If you choose to replicate to an XML document when you create your replica, information about the replica and replicated datasets are enclosed in <GPReplica> tags as shown below. In this example, the name of the replica is toagency, and it was replicated from geodatabase version PHASE1.
Other dataset definitions
Beginning with ArcGIS 9.2, you have the ability to track transaction-time history for your data using geodatabase archiving. Transaction time represents the moment in time when an event is represented in the database. It is delimited when the feature is inserted in the database, then modified or logically deleted. Tracking a dataset's history allows you to keep a record of when and how the data has changed. It also allows you to query previous versions of the data.
Archiving tables in ArcCatalog and ArcMap
To use geodatabase archiving, you register the data as fully versioned, then enable it for archiving in ArcCatalog. (For details on how to perform this operation, see Geodatabase archiving
and its related topics.) You can tell if a dataset has already had archiving enabled if, when you right-click the dataset in ArcCatalog and click Archiving, the context menu has Disable Archiving enabled but Enable Archiving is disabled.
Archive classes cannot be viewed in ArcCatalog, but you can save a connection to a specific historical version through ArcCatalog. See the section "Connecting to a specific version of the database" in Creating spatial database connections
and the topic Working with a historical version
for instructions on how to do this. To help you view the changes made at specific times, you can create historical markers that can be used by others to view the state of the data at that specific time. For details on creating historical markers, see Working with historical markers
Archiving tables in an Oracle DBMS
When a table is enabled for archiving, an archive class is created. This is a copy of the business table and contains all the same fields plus three new fields: GDB_FROM_DATE, GDB_TO_DATE, and GDB_ARCHIVE_OID. For a description of how these fields are populated, see The archive process
The name of the archive class table is the same as the original business table name with an underscore and H appended to it. For example, if a feature class named trails is enabled for archiving, an archive class, trails_H, is created in the schema of the owner of the feature class. The archive class table is read-only, stores changes saved or posted to the DEFAULT version of the geodatabase, and is not deleted if its corresponding dataset is unregistered as versioned or deleted. If an archived dataset is unversioned or deleted, the archive class is converted to a temporal table and can still be queried. See Working with the Geodatabase History Viewer
for details on viewing different historical versions.
When changes are made to the schema of a dataset that is enabled for archiving—for example, if a field is added or deleted—these changes are automatically added to the corresponding archive class.
NOTE: Never directly alter the schema of an archive class.
Also, when a table is enabled for archiving, a record gets added to the SDE_ARCHIVES table. This record stores the registration IDs of the table that was enabled for archiving and its associated archive class table. For further information on the SDE_ARCHIVES table, see System tables of a geodatabase stored in Oracle
The following shows a business table—TRAILS—enabled for archiving, its corresponding archive class table, and records in the SDE_ARCHIVES table.
When you create historical markers to view the state of the data at a specific time, the GDB_HISTORICALMARKERS table is populated. For details on creating historical markers, see Working with historical markers
Archiving tables in an XML document
Archive classes are not exported to XML workspace documents.