To further improve performance, the state tree can be compressed. All versions reference a state, but not all states are referenced by a version. Compressing simplifies the state tree again by removing each state that is not referenced by a version and is not the parent of multiple child states. This operation will be executed against all states in the geodatabase, regardless of owner, and can only be performed by the sde administrative user. As with trimming, compressing reduces the depth of the state tree and shortens the state lineage, which will improve query performance. All states that are referenced by a version will remain following the compress operation. As the data is edited, rows are added to the delta tables to record each change made to the version. Many of these rows are subsequently superseded by more recent changes to the data, and they are no longer required to represent the current state of a version. Compressing a versioned database also eliminates these redundant rows from the delta tables and moves all rows that are common to all versions into the base tables. This has the two-fold benefit of helping to conserve disk space and again improving query performance. All versioned geodatabases should be compressed periodically. The more dynamic the data, the more frequently the database should be compressed.

Note: At the 9.x release of ArcGIS, a compress operation no longer requires an exclusive lock to prevent inconsistent reads on the database. Compress will trim state trees and purge the delta tables for all versions that are not currently being edited. The state trees of any active edit sessions are not affected. To achieve the optimum versioned geodatabase state configuration when running the compress; that is, no rows in the delta tables and the state tree trimmed back to 0. Any outstanding changes to child versions should be reconciled and posted to the DEFAULT version and the versions themselves deleted.

However, given operating constraints imposed by organizational workflow requirements, this is not always possible. For example, organizations that must maintain historical versions will not be able to compress back to state 0. Although this state is desirable, it is not essential to good database performance. Trimming the state tree is the key to good performance; a regular database compress is recommended if the data changes frequently. Before compressing the database, reconcile and post each version with its parent version, propagating the changes through the version tree to the DEFAULT version. Then reconcile and save each version again to ensure all versions now have the latest snapshot of the now modified DEFAULT version. Finally, perform the compress; this will flush all edits for the DEFAULT version, currently in the delta tables, to the base table.

The compress can still be executed without first reconciling, posting, and (optionally) deleting each version, but without a comprehensive reduction of the state tree and purge of the delta tables, there will be no significant performance improvements.

The results of each compress operation are written to a log, SDE.compress_log, maintained in the database by ArcSDE. This log records statistics on the compression start time, end time, the number of states that have been compressed, and the status of the operation. After running a compress on the database, it is recommended that the DBMS statistics be updated by running the Analyze command.