English

Bug: Performing compression while sessions are editing can result in data inconsistencies

Description

Performing a compression operation while sessions are connected and editing can result in data inconsistencies if the compress operation attempts to delete a state of the database with descendant states.

Cause

The compress operation must build an in-memory representation of the versioned state tree for determining which states can be deleted, what states can be trimmed (collapsed into one state), and what states can be moved to the base state: state 0.

Prior to ArcGIS 9.2 Service Pack 6, the process constructs the in-memory state tree graph by reading every lineage from the ArcSDE state_lineages table. Because of the duration of time required to read the entire state_lineages table from the database to the client and to construct the in-memory state tree, if users are editing, there is a greater potential of encountering this issue.

Starting with ArcGIS 9.2 Service Pack 6, the process constructs the in-memory state tree graph by reading the ArcSDE states table using the state_id and parent_state_id values to derive the relationship between states (the modification is part of the fix to address NIM010856 in ArcGIS 9.2 Service Pack 6). Because of the duration of time to read the entire states table from the database to the client, and construct the in-memory state tree is much faster and efficient than reading the entire state_lineages table, the timing to encounter this issue while users are editing is far less, but can still occur.

Once the state tree graph is present in-memory, only those states present will be candidates to be deleted or trimmed. If new states are created after the state tree has been created, the states and modifications to versioned tables should not be impacted by the compress process.

But, the compress process can mistakenly attempt to delete states that it believes are leaf states (states that are not parent states). The action of deleting a state requires the removal of all rows for the given state being deleted in any modified versioned table. This step can lead to data inconsistencies where valid rows in a versioned class' delta tables are deleted. The inconsistencies introduced will be in the form of duplicate objects, where updated rows in a specific state will no longer have their corresponding rows in the deletes table to cancel the previous states' representation.

Workaround

This issue has been resolved with the release of the ArcSDE Compress with Concurrent Editors Patch. Download the appropriate patch below:

ArcSDE 9.1 Compress with Concurrent Editors Patch

ArcSDE 9.2 Service Pack 6 Compress with Concurrent Editors Patch

ArcSDE 9.3 Service Pack 1 Compress with Concurrent Editors Patch

Note:
It is strongly advised that customers install this patch as soon as possible. If the patch cannot be installed, note the following:

  • To avoid any potential data inconsistencies, do not execute the compress command while users are editing the geodatabase. If users are connected and viewing versioned data, for example an ArcGIS Server application, then it is safe to proceed in compressing the database.
  • To check that no users are currently editing, query the ArcSDE object_locks table and verify no rows are present. If rows are present, this indicates a session is currently editing or reconciling a version.
  • If data inconsistencies have been encountered and are present, use the ArcSDE sdegdbrepair command to fix each corrupted versioned object classes.