FAQ: What is the correct workflow to achieve a full compress in a versioned geodatabase using replicas?


Question
What is the correct workflow to achieve a full compress in a versioned geodatabase using replicas?

Answer
To achieve a full compress in a versioned geodatabase (that is, move edits from the Adds and Deletes tables to the business tables, and remove unreferenced states), perform the following workflow:

  1. Disconnect all users/services including stopping ArcGIS Server services. This operation is best performed when there are no users connected, that is, outside of normal working hours.
  2. Reconcile/post all child versions to the Default version.
    If Using Replication: Do this on both child and parent geodatabases.
  3. Delete child versions. These versions can be recreated after the full compress has been performed.
  4. If Using Replication: Check and compare if there are any schema changes in either geodatabase.
  5. If Using Replication: Synchronize replicas from the child to the parent geodatabase (receive changes from the relative replica geodatabase to this geodatabase).
  6. If Using Replication: Compress child geodatabase. This will do a full compress on the child geodatabase and set SDE_versions.state_id to 0 (or Versions.state_id to 0) for the DEFAULT version.
  7. If Using Replication: Synchronize replicas from the parent to the child geodatabase (send changes from this geodatabase to the relative replica geodatabase). Even if no changes have been made this will push the Sync_Receive Version over to the child replica and allow a full compress on the parent geodatabase.
  8. Recalculate Statistics and Rebuild Indexes only on the delta and system tables. (Refer to the Versioning Vocabulary for an explanation of “delta tables”.)
  9. Compress parent geodatabase, and notice a full compress is accomplished. The state_id of the DEFAULT version is set to 0 in the SDE_versions table (or Versions table).
  10. Recalculate Statistics and Rebuild Indexes because the delta, base, and system tables record counts have likely changed since the last compress. (Refer to the Versioning Vocabulary for an explanation of “delta tables” and “base table”.)

Note:
If the ReplicaID of any synchronization versions do not appear in the GDB_REPLICALOG table they are orphaned synchronized versions and should be deleted. For example if 57 does not appear as a ReplicaID in the GDB_REPLICALOG table, but there are synchronization versions referring to replica 57 (for example SYNC_RECEIVE_57_0 and SYNC_RECEIVE_57_1) then these synchronization versions can be deleted.

References:

The compress operation and geodatabases

Compress (Data Management)
How To: Effectively compress a geodatabase with replicas
How To: Compress a versioned database to state 0

Compressing a versioned geodatabase is discussed in more detail in the course: “Implementing Versioned Workflows in a Multiuser Geodatabase”.

Versioning Vocabulary

1 thought on “FAQ: What is the correct workflow to achieve a full compress in a versioned geodatabase using replicas?

  1. Paul Davidson

    Great post, have spent the past few months working with Esri on this exact problem. A quick read looks like you have it rather succinctly nailed down. One thing I would note at this time is that creating a Feature Service with Sync will create a replica. Even if the service is read only (Feature Access with Query and Sync only) and will be passing no data back via Sync. it seems that in this case we are able to remove these replicas without any harm to our data. Because we are in a testing mode for setting up offline maps, we are also finding many orphaned replicas. Right clicking on a .sde file that owns the replicas and then Selecting Distributed GeoDatabase>Manage Replicas will show how many SYNC_SEND replicas (and others of course) exist. These can be removed by a right click action on this ilst but can be a one by one tedious process. Also, orphaned replica versions won’t show. But can be removed via the Delete Replica geoproc tool. In the end, I have written scripts to run under ArcGIS Pro (the arcmap versions do not seem to work all the time) to find replicas and orphaned replicas, remove them, etc…. The ability to script these actions I believe was introduced to ArcPy fairly recently. Note one can do a lot of these actions from the REST endpoints but of course, orphans won’t show in these lists. This note is lacking a lot of detail and much of this addition detail is probably specific to our situation. I share it in its shortened form in case others are trying to do offline maps using Feature Services (even if read only) and are unaware of the Replicas being created behind the scenes. I’m not sure exactly when the Replicas are created but I suspect it is when the service is Queried for a data download. Cheers mate.

    Reply

Got something to say?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s