English

Problem: 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.

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 parent 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 ancestor, such as parent, grandparent, 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 child 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.

[O-Image] Example: Version tree
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 ancestor 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


[O-Image] State tree before reconcile
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.

[O-Image] State tree after Editor1 is reconciled to Trans_mnt
In the above diagram, it does not state how many edits are in states 78, 92 and 97. If there was only 1 edit for a feature class per state, then for 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 child versions from one parent, the order of reconciling and posting the child versions to the parent 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 parent 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 ancestor state for both Editor1 and Editor2 versions.

  1. 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


    [O-Image] State tree before reconcile
    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.
  2. 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.

    [O-Image] State tree after Editor1 reconciles
    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.
  3. When the 'Post' command is clicked, the Editor1 and Trans_mnt versions reference the same state, state 99.
    [O-Image] Post Editor1 and Trans_mnt
  4. As the workflow continues, the Editor2 version is reconciled and posted to Trans_mnt.
    [O-Image] Editor2 reconciles with Trans_mnt
    For this reconcile, the Trans_mnt or parent 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 child versions created from the same parent 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 child 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.