Successfully compress the geodatabase

Summary

Periodically compressing the geodatabase is a required maintenance procedure. Compress trims the state tree and moves rows, common to all versions, from the delta tables to the business table.

The delta tables hold all changes made to a versioned database. For each versioned feature class or object class there are 2 delta tables; the A table for inserts and updates and the D table for deletes.

Compressing the database removes all unreferenced database states and moves common rows from the delta tables into the "base" (business) table. The volume of edits (inserts, updates and deletes) for a table will affect the size of the database transaction.

The database uses a rollback segment to store copy of the data before it is changed in order to be able to roll back the transaction if something fails. If the changes can not be successfully stored in the rollback segment, then the transaction fails and is "rolled back" with an underlying database error and compress fails

To ensure the compress transaction completes (is able to be committed) it is recommended that the DBA create a separate large rollback segment for use with the compress command.

The ArcSDE dbtune table provides a parameter for defining the database rollback segment used during the compress operation. The parameter is named COMPRESS_ROLLBACK_SEGMENT and it contains the name of a rollback segment created for this purpose. The parameter is only recognized when it has been added to the DEFAULTS configuration keyword.

For more information on creating the rollback segment used for compressing the geodatabase, see The ArcSDE Configuration and Tuning Guide for Oracle, Chapter 2 ‘Essential Oracle configuring and tuning’.

The geodatabase can be compressed with either the ArcCatalog compress command or by using the ArcSDE sdeversion administration utility with the compress option.

Procedure