The distribution of data involves creating copies of data for dissemination between two or more geodatabases. It allows two or more offices to work concurrently with the copies of the same data in separate locations.
Data distribution improves data availability and alleviates issues such as server contention and slow network access to a central server. This can help an organization balance the load placed on their geodatabase between users who perform edits and those who require access for read-only operations.
Distributed data is also useful when you need to take part of your geodatabase offline into the field to edit for an indefinite amount of time.
There are several ways to distribute your data across multiple geodatabases.
- Copy and paste
- Take a map offline with feature service sync capability
- Geodatabase replication
- DBMS replication
Copy and paste
Some organizations achieve a level of data distribution by saving copies of their geodatabases and sending them to other offices. These offices can then work on the data, make edits, and send a copy of their updated geodatabase back to the main office. Here, edits are compared and coordinated to ensure that the data at the two offices remains in sync. This solution can work with careful communication; however, there are many opportunities for updates to be lost, and it can be difficult to keep the two geodatabases in sync.
Geodatabase replication
Geodatabase replication is a data distribution method provided through ArcGIS. With geodatabase replication, data is distributed across two or more geodatabases by creating a replica of only a part, or of an entire dataset. When a dataset is replicated, a replica pair is created; one replica resides in the original geodatabase, and a related replica is distributed to a different geodatabase. Any changes made to these replicas in their respective geodatabases can then be synchronized so that the data in one replica matches that in its relative replica.
The three types of geodatabase replication are: checkout/check-in, one-way, and two-way
- Checkout/Check-in replication: The child replica can be either in an enterprise or file geodatabase
- One-way replication:
- One-way, parent-to-child replication: The child replica can be an enterprise or file geodatabase
- One-way, child-to-parent replication: Both child and parent replicas must be hosted in an enterprise geodatabase
- Two-way replication: The child replica must be an enterprise geodatabase
Note:
For all replica types, the parent geodatabase must be hosted in an enterprise geodatabase. Learn more about different geodatabase replication types.
Geodatabase replication is built on top of the traditional versioning environment and supports the full geodatabase data model, including topologies, networks, terrains, relationships, and so forth. In this asynchronous model, the replication is loosely coupled, meaning that each replicated geodatabase can work independently, and all changes can still be synchronized. Since it is implemented at the geodatabase level, the respective DBMS used by each related replica may differ. For example, one replica geodatabase can be built on top of SQL Server, while the other is built on top of Oracle. To get started see how to prepare data for replication.
Geodatabase replication in ArcGIS Pro supports the following geodatabase data types:
- Table
- Feature class
- Annotation
- Dimensions
- Relationship class
- Topology
- Network dataset**
- Terrain dataset
**Supported with limitations
Note:
Geodatabase replication within ArcGIS Pro only supports synchronization of data that is registered using traditional versioning. While geodatabase replication supports the full geodatabase data model, there are some datasets that cannot be edited in ArcGIS Pro, such as geometric networks. For a complete list of supported data types and limitations of geodatabase replication within ArcGIS Pro, see replication and geodatabase compatibility.
Take a map offline with feature service sync capability
The Sync capability with feature services allows you to take maps offline by clicking the Download Map button.
When the data is taken offline, the layers in the map are updated to reference a local copy of the data. This allows you to make edits and complete your work without the requirement to be connected to the network. Once network availability exists again, you can upload your local edits made to the offline feature layers using the Sync button . If you no longer need to work offline, you can remove the local geodatabase and go back online by clicking the Remove button. This process points the layers' source back to the feature service and the map display updates to show the current data for the web feature layers. See Take a map offline to learn more about how to configure this workflow.
Note:
The data source tab can be used to determine which layers are offline and which ones are not. Some types of layers in the web feature layer cannot be taken offline. These will remain connected to the web feature layer even if a local copy if the data is downloaded for other layers. When a network connection is not available, any layers that are still connected to the web feature layer will display as broken in the map. For more details, see Take feature layers offline.
Feature service sync - Taking a map offline vs. Geodatabase replication
Taking a map offline using the Feature service sync capability is feature services based whereas geodatabase replication uses local enterprise and file geodatabases. The key benefit of taking a map offline using feature service sync capabilities is the ability it provides to perform multiple synchronizations versus the checkout replica type, where changes can be synchronized only once.
DBMS replication
Various DBMS have their own replication mechanisms in place, which can be used to make copies of, and synchronize geodatabase data.
DBMS replication refers to the built-in replication mechanisms provided by the DBMS in which the geodatabase is stored. DBMS replication is not geodatabase aware. This means that geodatabase constructs, such as relationship classes and utility networks, are not known by the DBMS. However, DBMS replication can still be configured to work in a limited way with geodatabase data.
DBMS replication versus geodatabase replication
The following facts compare geodatabase replication and DBMS replication:
- Geodatabase replication synchronizes changes from specific enterprise geodatabase versions. DBMS replication, when used with an enterprise geodatabase, applies changes across all versions in the geodatabase.
- Geodatabase replication supports some advanced geodatabase objects such as topologies, relationships, and feature-linked annotation. DBMS replication does not properly replicate advanced geodatabase objects.
- Geodatabase replication allows you to replicate portions of your geodatabase, DBMS replication used with a geodatabase requires that you replicate the entire database.
- Geodatabase replication allows two-way replication. DBMS two-way replication is not supported against a geodatabase.
Related topics