Effectively compress a geodatabase with replicas

Summary

Replication uses internal system versions to manage the synchronization process between replicas. The need to maintain these versions can limit the number of changes moved to the business tables during a compress. The synchronization process creates, drops and reconciles, and posts these versions which can make more rows available for compress to apply to the business tables. Instructions provided describe how to perform these replica synchronizations before compress.

Note: 
Support for Visual Basic for Applications (VBA) for ArcMap and ArcCatalog ended with the ArcGIS 10.2.2 release, and Esri has not included VBA compatibility setups since version 10.5. See: ArcGIS Desktop and VBA Moving Forward

Procedure

Performing any of the following steps can result in an improvement during compress. Performing all steps in the order described below results in the biggest improvement.

1. Unregister all unused replicas. If a replica is no longer being used, unregistering also removes any unused system versions that can potentially affect compress.
2. If planning to synchronize several replicas, run the script below to determine the order in which to synchronize the replicas. This order can be applied at both steps 3 and steps 5 below. To run the script, add the code below to VBA in ArcCatalog and run it with the SDE connection selected.

Sub rec_sync_order()

  Dim pGxApp As IGxApplication
  Set pGxApp = Application
  Dim pGxObj As IGxObject
  Set pGxObj = pGxApp.SelectedObject
  Dim pName As IName
  Dim pVerWksp3 As IVersionedWorkspace3
  Dim pRnEnum As IEnumBSTR
  Dim rName As String
  Set pName = pGxObj.InternalObjectName
  Set pVerWksp3 = pName.Open
  Set pRnEnum = pVerWksp3.RecommendedSyncOrder
  pRnEnum.Reset
  rName = pRnEnum.Next
  Do Until rName = ""
    Debug.Print rName
    rName = pRnEnum.Next
  Loop
End Sub

Note:
This script only lists replicas that have changes to be synchronized. For example, if no changes have been made since the replica was created or the last synchronize, the replica would not be listed in the output for the synchronize order.

3. If planning to receive changes, run the synchronization process to receive the changes. For example, if planning to both send and receive changes, first receive the changes. Also, resolve any conflicts that result from receiving the changes.
4. If planning to reconcile and post a named replica version with the default version, perform the reconcile and post at this time. Also, perform any reconcile/post workflow that is normally performed before doing a compress.
5. If planning to send changes, run the synchronization process. If using disconnected replication, make sure to get the acknowledgement from the relative replica after it has received the changes.
6. Run the compress command or tool.