What is the correct workflow to achieve a full compress in a versioned geodatabase using replicas?
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:
- 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.
- Reconcile/post all child versions to the Default version.
If Using Replication: Do this on both child and parent geodatabases.
- Delete child versions. These versions can be recreated after the full compress has been performed.
- If Using Replication: Check and compare if there are any schema changes in either geodatabase.
- If Using Replication: Synchronize replicas from the child to the parent geodatabase (receive changes from the relative replica geodatabase to this geodatabase).
- 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.
- 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.
- Recalculate Statistics and Rebuild Indexes only on the delta and system tables. (Refer to the Versioning Vocabulary for an explanation of “delta tables”.)
- 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).
- 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”.)
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.
Compressing a versioned geodatabase is discussed in more detail in the course: “Implementing Versioned Workflows in a Multiuser Geodatabase”.