Available with Standard or Advanced license.
When a replica is created, data and schema are copied from the parent geodatabase to the child geodatabase. The data includes the rows to be replicated from the datasets in the replica. The schema consists of the fields, domains, subtypes, and the definition of the datasets in the replicated data.
Initially, the schemas are identical on both replicas, but over time, changes may be applied to each replica geodatabase schema. For example, one replica may require additional fields to complete a project, while the relative replica may need to apply a new domain to an existing field. When this happens, the schemas of the replica geodatabases are no longer the same. You can use geoprocessing tools to compare replica geodatabase schemas, identify differences, and—for some types of schema changes—synchronize the schema between the two geodatabases.
Schema changes alter the structure or definition of objects, such as tables and feature classes, in a geodatabase. For this reason, schema changes apply directly to the objects in that geodatabase; they are not isolated to specific versions.
Replica schema tools
There are three geoprocessing tools used when working with replica schema changes:
- Export Replica Schema—Creates a replica schema file with the schema of an input one- or two-way replica.
- Compare Replica Schema—Generates an .xml file that describes schema differences between a replica geodatabase and the relative replica geodatabase.
- The schema changes file generated from this tool describes what changes need to be applied to the replica geodatabase to match the relative replica geodatabase.
- Import Replica Schema—Applies replica schema differences using an input replica geodatabase and an .xml file.
The schema changes tools can be accessed from the following locations:
- In the Geoprocessing pane, you can use the search option or browse to the Distributed Geodatabase toolbox.
- In the Manage Replicas pane, you can use the Manage Replicas Menu
. 
- In the Catalog pane, you can right-click a geodatabase and access the
Distributed Geodatabase context menu.
To apply schema changes to a relative replica geodatabase, see the instructions in Manage geodatabase replicas.
Note:
Modifying the schema of a replica to match the schema of a relative replica is a separate process from data synchronization.
Valid schema changes
The following table lists types of schema changes you can import to the relative replica geodatabase using the Import Replica Schema geoprocessing tool. Values in the table indicate whether or how the schema changes are applied to the relative replica geodatabase.
| Add | Change | |
|---|---|---|
Field | Fields added to tables or feature classes are synchronized. | Changes to domains applied to fields are synchronized. |
Domain | New domains are synchronized. | Changes to domain definitions are synchronized. |
Table or feature class |
Added fields and domains applied to fields in tables and feature classes are synchronized. |
Fields, tables, or feature classes that are deleted are not synchronized with (in other words, they are not removed from) the relative replica geodatabase.
Removing datasets from a replica
A list of the datasets involved in each replica is stored in a replica geodatabase. You can view this list on the Replica Properties dialog box. See Manage geodatabase replicas for instructions to open these properties.
If you unregister one of these datasets from the replica, a warning appears. If you continue, the dataset is removed from the replica dataset list. Also note the following:
- If you unregister a table, feature class, or relationship class, you cannot add it back to the replica.
- If you unregister a topology, you cannot add it back to the replica. The replicas will still synchronize; however, synchronizing topology exceptions is not supported.
Maintaining schema differences
Geodatabase replication is designed to permit some schema differences between replica geodatabases, allowing data synchronization to continue to work in most cases.
However, when you apply a schema change to one replica geodatabase but not the other, you may encounter the following issues:
- Edits that do not synchronize—Data synchronization only imports changes for tables and fields that are common to both replicas. If an edit is made to a field that is not in the relative replica geodatabase, the edit cannot be applied in the replica geodatabase when importing changes.
- Invalid values—Changes that violate domains, subtypes, and relationship rules are applied when synchronizing changes.
- Data synchronization errors—These can happen when you manually make a schema change to both replica geodatabases. For example, if you add a field to a table, ensure that you use the same field definition in both geodatabases in the replica pair. If there is a difference—for example, a field is a string in one replica geodatabase but an integer in the other—a data synchronization error will occur.
- Unsupported changes—Some types of schema changes can cause synchronization to fail, but no warning appears if you make the change. These changes are not detectable by the geodatabase replication system. They include database-level operations such as changing permissions on tables in the database. If permissions are changed to read-only for replicated data, a failure will occur when trying to import changes from the relative replica geodatabase.
Best practices
In general, it is best to avoid schema changes. Schema changes can lead to inconsistencies among replicas, and the extra task of applying schema changes can increase performance costs. However, there are cases when schema changes must be applied. The following are best practices to help avoid schema changes:
- Apply periodic schema comparisons—Because replication is fault tolerant, synchronization processes will most likely not be interrupted by schema changes. However, a good practice is to periodically run a schema comparison to ensure that unplanned schema changes have not been applied.
- Do not synchronize until completing a maintenance task that requires a schema change.
- Apply schema changes systemwide—If schema changes need to be applied, apply them systemwide and in an organized manner. For example, use a top-down approach in which the changes are applied at the parent replica geodatabase and propagated to child replicas.