Geodatabase compression removes unnecessary states and rows from the geodatabase system tables that track traditional versions and versioned edits.
What is geodatabase compression?
Compression removes the states that are no longer referenced by a traditional version and can move rows in the delta tables to the business table. Only the geodatabase administrator can compress the geodatabase, but compression operates against all states in the geodatabase, regardless of the version owner.
Compression is necessary because, as a geodatabase that uses traditional versioning is edited over time, the delta tables increase in size and the number of states increases. The larger the tables and the more states, the more data ArcGIS must process every time you display or query a version. Therefore, the greatest impact on performance is not the number of versions but the amount of change contained in the delta tables for each version. As a result, versions can have different query response times.
To maintain performance, the geodatabase administrator must periodically compress the geodatabase to remove unused data.
You can use the ArcGIS Desktop Compress command or the Compress geoprocessing tool or Python script.
What happens during compression?
Compression first scans into memory the instance's state tree configuration. Using this information, compression deletes all states that do not participate within a version's lineage. Deleting a state deletes all the rows from the delta tables that are associated with that state.
The next step collapses any candidate lineage of states into one state. A candidate lineage is a collection of states that can be compressed into one state without affecting the logical representation for any table in a given version.
The final step, when applicable, moves rows from the delta tables into the base (or business) tables.
For each step of the operation, database transactions start and stop for each table being compressed. The transaction verifies each table is consistent during each step of the process.
Compression can be stopped while it is executing because the operation is designed to be transactionally consistent. Therefore, if the operation encounters an error, fails, or abruptly stops, the versioned tables being compressed are still logically correct with respect to any version's representation. One reason you might stop compression is if you run it while users are connected to the geodatabase, then discover the compression is consuming a large amount of system resources. In that case, you might want to stop the operation and run it again when fewer or no users are connected to the geodatabase.
It is possible for compression transactions to be quite large. Therefore, for Oracle databases configured with automatic undo space management, make sure the geodatabase administrator's UNDO_POOL parameter is not set too low and that enough undo tablespace exists to complete the compression operation.
Fully compress a geodatabase
In a fully compressed geodatabase, there are no rows in the delta tables and the state tree is trimmed back to zero. Performance improvement is greatest if the geodatabase is fully compressed. To achieve this, do the following:
- Reconcile and post all outstanding changes in child versions to the Default version. As the geodatabase administrator, you can see in what order versions should be reconciled by opening the Reconcile Order subtab of the Versions tab on the Geodatabase Administration dialog box in ArcMap. See Version properties for information on the Reconcile Order subtab.
- Delete the decendent versions after you have reconciled and posted edits.
- Make sure no user is connected to the geodatabase.
- Compress the geodatabase.
You can see the results of each compression in ArcGIS Desktop in the COMPRESS_LOG table. You can also check the VERSIONS table to see if the state ID for the Default version has returned to zero. If it has and there are no other outstanding versions, full compression has been achieved.
It may not always be possible to reconcile, post, delete versions, and disconnect all users before compressing. For instance, if you are tracking history using versions or need to maintain design versions for a project, the historic and design versions hold a state within the state tree; therefore, these states are not removed during compression of the geodatabase. You can successfully compress without doing all these steps, and you will still see performance improvements.
Frequency of compression
How often you need to compress the geodatabase depends on the amount of editing in your geodatabase. If you have a high volume of edits, you should probably compress the geodatabase once a day. For average or low edit volumes, you should compress at least once a week.
After compressing a geodatabase
Update geodatabase statistics after you compress. The geodatabase administrator should update statistics on the versioning system tables, and individual users can update statistics on their edited datasets.