Available with Standard or Advanced license.
Geodatabase replication supports many workflow options in addition to those offered through versioning. The following are scenarios accommodated through geodatabase replication.
For more information on the following scenarios, see the white paper An Overview of Distributing Data with Geodatabases.
Replica tree
You can use geodatabase replication in your organization to create replica trees, similar to version trees, to distribute data across several geodatabases in a hierarchical structure.
For example, some organizations require the ability to replicate a single organization-wide geodatabase across several offices. Each office has a replica with only the data applicable to its area and can transfer changes of this data to the main office. This allows the main office to perform analysis on data that is up to date across the entire extent. Connections within an office are fast but are much slower between offices. The regional offices can also replicate their geodatabases to local offices in the same way that the main office replicates its geodatabase to the regions.
Central hub
A replica geodatabase can be used as a central hub to host readers and editors. To keep connection speeds fast, editors can create a replica to check out data from the central hub, perform edits, and check the changes back in by synchronizing with the geodatabase.
The central hub can also be used to propagate changes between multiple child replicas. To move changes from one replica to another, first synchronize the changes in one replica with the parent (or hub) replica. A second child replica can then synchronize with the parent to get these changes.
Mobile users
Mobile users in an organization, such as a maintenance crew, require the ability to edit a portion of an enterprise geodatabase in the field. They need to disconnect completely from the organization's infrastructure, often for a prolonged period of time. When preparing for a particular work order or project, the relevant data is replicated and transferred to a portable device, such as a laptop. This device is then disconnected from the network, allowing the field crew to operate independently from the network. The field crew can continue to work with and modify the replicated data while disconnected from the network. When a connection to the network is reestablished, any changes made to the data are transferred back and synchronized with data maintained in the enterprise geodatabase.
Contractor
Some organizations use a third-party contractor to maintain part of their geodatabase and have that contractor provide updates every month. The organization must be able to incorporate the contractor's changes without completely reloading the data. It also needs an easy way to review only the updates for the month instead of performing QA tests on the entire dataset.
You can accomplish this by sending the contractor a replica of the appropriate data for updates. When the contractor sends the changes back to the organization, they can be synchronized with the data maintained in the enterprise geodatabase.
Production and publication geodatabases
An organization needs to support a group of editors as well as users accessing the system with read-only access. To satisfy the requirements of each group, the organization has two enterprise geodatabases. One is a production geodatabase, which is edited directly by the editors, and the other is a replica of this geodatabase, which is accessed by the readers. Readers can access this data through ArcGIS Server.
In this scenario, the replica in the publication geodatabase is a read-only copy of the production geodatabase. The data on the publication geodatabase does not need to be versioned. The replication can be restricted to sending data in only one direction. Edits are made on the production geodatabase and are sent from it to the publication geodatabase. These edits are transferred and synchronized with the data on the publication geodatabase and then served to the readers.
Multigroup data management
In your organization, data management may be divided among several different groups. For example, one group may be in charge of managing the utility networks, while another is tasked with managing the land base data for the same area. Another example is when several teams are working on many independent projects. The datasets for each project may be mostly from different geographic areas, but the organization wants a central repository for all projects.
Your organization can use geodatabase replication to distribute your data among various groups, dividing data into appropriate projects. Each project team receives a replica of the necessary data from the central enterprise geodatabase. The teams then edit each replica independently of one another, possibly in separate geographic locations, and transfer those edits to the central enterprise geodatabase. Conversely, any edits made to the central enterprise geodatabase are transferred to the appropriate replica in the project teams as well.
Centralized data from many sources
Another common replication practice is to have a centralized location where data is collected. Organizations set up in this manner have a central geodatabase that maintains a collection of data from other offices.
An example of this is the distribution of data between state offices and a national office. Each state office works independently, managing its own datasets and periodically sending updates to the national office. The edits from each state are synchronized into one comprehensive dataset in the national geodatabase. In this child-to-parent replication configuration, the national geodatabase is assigned the role of parent, and the state geodatabases are assigned the role of child.
See the Technical Support article Compressing Enterprise Geodatabases That Contain Replicas - Best Practices for more information.
