Available with Standard or Advanced license.
Geodatabase replication supports many workflow options on top of those already offered through versioning. The following are a number of scenarios accommodated through geodatabase replication.
More information on the following scenarios can also be found in the white paper An Overview of Distributing Data with Geodatabases.
Replica Tree
Geodatabase replication can be used to create replica trees, similar to version trees, allowing organizations to distribute their data across several geodatabases in a hierarchical structure.
For example, some organizations require the ability to replicate a single organization-wide geodatabase across different 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, then 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, the changes in one replica are first synchronized with the parent (or hub) replica. A second child replica can then synchronize with the parent to get these changes.
Mobile Users
Mobile users within an organization, such as a maintenance crew, require the ability to edit a portion of the ArcSDE 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, enabling the field crew to operate independently of the network. The field crew can continue to work with and modify the replicated data even though they are disconnected from the network. When a connection to the network is reestablished, any changes made to the data will be transferred back and synchronized with data maintained in the ArcSDE geodatabase.
Contractor
Some organizations need to contract out the maintenance for part of their geodatabase and have that contractor provide updates every month. The organization needs to be able to incorporate the contractor's changes without completely reloading the data. It also needs an easy way to review just the updates for the month instead of having to perform QA tests on the entire dataset.
This can be accomplished 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 ArcSDE 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 ArcSDE geodatabases. One is a production geodatabase, which is edited directly by the editors, while the other is a replica of this geodatabase and is accessed by the readers. Readers can access this data through ArcIMS or ArcGIS Servers.
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, then served to the readers.
Multigroup data management
Within 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 where several teams are working on many completely independent projects. The datasets for each project may for the most part be 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, splitting up data into appropriate projects. Each project team receives a replica of the necessary data from the central ArcSDE geodatabase. The teams then edit each replica independently of one another, possibly in separate geographic locations, and transfer those edits to the central ArcSDE geodatabase. Conversely, any edits made to the central ArcSDE geodatabase are transferred to the appropriate replica in the project teams as well.
Centralizing 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 houses a collection of data from other offices.
An example of this would be 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 article Compressing ArcSDE Geodatabases That Contain Replicas - Best Practices for more information.
