Reconciling a version is slow or requires a long time to complete

Description

When performing a reconcile, occasionally the reconcile process is slow or requires a long time to complete.

When performing a reconcile, it is important to understand the process of what the reconcile performs internally and why an organization's workflow may have a significant impact on a reconcile's performance.

Note:
This article pertains to ArcGIS versions 8.x and 9.x. Later versions of ArcGIS may contain different functionality, as well as different names and locations for menus, commands and geoprocessing tools.

Cause

During a reconcile, all the edits performed in the source version, the version being edited and reconciled against a target version, the target version being the primary version or DEFAULT version, are copied to the target version and any conflicts are detected and presented by way of the conflict resolution dialog box.

The time it takes to perform the reconcile depends on the number of edits. To better understand why it depends on the number of edits, understand the versioned geodatabase's state tree.

Every edit that occurs in a versioned geodatabase is uniquely identified by a state_id. The collection of states in a versioned geodatabase is termed a state tree, and each state participates in a lineage of states that originates from state 0, the base state. Each lineage in the state tree represent different edit sessions or different versions.

The state tree's only relationship to a version is the state for which the version references. However, the version hierarchy influences which versions can be reconciled with each other. A reconcile can only be performed on a version to a direct predecessor, such as the primary version or the version preceding the primary, etc.

This does not show, however, the complete story of how versions relate to geodatabase states. In the following example, note that version Editor2 is a secondary version, created from the Trans_mnt version, but the structure of the state tree and how versions correspond to specific states is not visible.

In this hierarchy, Editor1 can reconcile to Trans_mnt or DEFAULT.

When reconciling a version with a target version, all the edits in the source version's lineage, which are not common to the target version's lineage, are copied to a new state in the target version's lineage. In the following example, Trans_mnt and Editor1 have a common predecessor state, state 40.

Here we can see the lineages for the versions are:

• Trans_mnt: 0, 40, 41, 52
• Editor1: 0, 40, 78, 92, 97
• Editor2: 0, 40, 56

The highest state is common in both version's lineage. The non-conflicting edits for states 78, 92 and 97 are each copied to the target version's lineage. The unique states for Editor1's lineage (78, 92 and 97) are copied to a new state on the Trans_mnt's lineage. The new state in the geodatabase is state 99.

The above diagram does not state how many edits are in states 78, 92 and 97. If there is only one edit for a feature class per state, then the reconcile state, 99, only contains the three edits performed in states 78, 92 and 97, resulting in 3 new rows in the feature classes adds and deletes tables.

However, if the 50,000 features are updated for state 92, then, during the reconcile process, all 50,000 edits must be copied to state 99 and inserted into the feature classes adds and deletes tables. Therefore, there would be 50,000 edits for state 92 and another 50,000 edits for state 99.

Additionally, the geodatabase must identify changes between the version's two lineages to identify conflicts during a reconcile. Conflicts are categorized into the following groups:

• Updates/Update conflicts.
• Update/Delete conflicts.
• Delete/Update conflicts.

Edits that are not conflicting or related to those objects that are in conflict are copied to the target version's reconcile state. Edits that are in conflict are displayed in the conflict resolution dialog.

The number of edits in the source version's lineage impacts the reconcile's performance.

Workflows must adequately account for these situations.

Solution or Workaround

When working a versioned geodatabase, the workflow for creating and reconciling versions is very important. With multiple secondary versions from one primary version, the order of reconciling and posting the secondary versions to the primary version is also important.

If the target version has not been modified since the source version was created and edited, the reconcile process does not have to copy any modifications, since each version shares the same lineage. In these cases, if the user posts after performing the reconcile, the source and target version are updated to reference the same database state.

In the following example, the Trans_mnt version, or the primary version, has not been modified since the Editor1 and Editor2 versions were created. The Trans_mnt version is referencing state 40, which is the common predecessor state for both Editor1 and Editor2 versions.

The following is an example of the state tree before reconcile. Note the lineages for the versions are:

• Trans_mnt: 0, 40
• Editor1: 0, 40, 78, 92, 97
• Editor2: 0, 40, 56

Notice the Trans_mnt version references state 40. The Editor1 version’s lineage is: 0, 40, 78, 92, 97.

When Editor1 is reconciled with the Trans_mnt version, there is no need to copy all of the edits from Editor1's current lineage to a new state for the Trans_mnt version.

The following is an example of the state tree after reconcile. The Editor1 version is reconciled with the Trans_mnt version. In this case, the Trans_mnt version is referencing a state that is along the same lineage as Editor1 so there is no need to copy the edits to a the reconcile state.

If 50,000 updates were performed in state 92, the edits are not copied to state 99 because they already exist in the version's lineage. In this case, the reconcile is very fast, as there are no conflicts to discover and there are no edits to copy to a target version's state.

When the Post command is clicked, the Editor1 and Trans_mnt versions reference the same state: state 99.

As the workflow continues, the Editor2 version is reconciled and posted to Trans_mnt.

For this reconcile, the Trans_mnt or primary version has been modified and references a new state, for example, state 99, which lies on a different lineage than the Editor2 version. To reconcile the edits from the Editor2 version, all the edits from state 56 are copied to a new state on the Trans_mnt lineage.

When there are multiple secondary versions created from the same primary version, the reconcile operations invariably result in the edits from one lineage being copied to another lineage. To minimize the amount of data being copied, reconcile and post the version with the largest number of edits first, which reduces the number of records that are copied and stored in the feature classes' adds and deletes tables.

Understanding the workflow considerations for reconcile is especially important when performing a very large number of edits in a secondary version or bulk editing. For a version that is used for bulk editing, always attempt to reconcile this version to its target before the target version is modified.