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 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 replicas are no longer the same. You can use geoprocessing tools to compare replica schemas and identify differences.
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, 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 is a list of schema changes and whether they can be applied to the relative replica:
| 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/Feature Class |
Added fields and domains applied to fields in tables and feature classes are synchronized. |
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
You can choose to allow replicas to make schema changes independently of one another. Geodatabase replication is designed to permit most schema differences between replicas, allowing data synchronization to continue to work in most cases.
When you apply a schema change to one replica but not the other, you should anticipate 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, it will not be applied 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 replicas. For example, you may want to add a field to a table. If you do this, ensure that you make the same schema change in all cases. If there is a difference (for example, a field is a string in one replica 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.
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:
- Lock down the system—Ensure that people using the system are working with the appropriate permissions. It may be necessary to write applications that prevent certain types of unplanned schema changes, such as adding or dropping a column.
- 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, you may want to use a top-down approach in which the changes are applied at the root replica and propagated downward.