ArcGIS Server Banner

About compressing a geodatabase

About compressing a geodatabase

Release 9.3 E-mail This TopicPrintable VersionGive Us feedback

To understand compression, you must first understand how versioning works. If you are unfamiliar with this concept, see Understanding versioning in the "Data management workflows, transactions, and versioning" section of the help.

As edits are made to a versioned ArcSDE geodatabase, the number of states (a version's lineage) and rows in the delta tables (the adds and deletes tables) grows significantly. This can slow database performance.

A version's lineage grows whenever edits are saved. Each save made in an edit session creates a state in the lineage that is not trimmed until the database is compressed. To avoid performance degradation, you will need to periodically compress your versioned geodatabase.

The compress command removes the states that are no longer referenced by a version and can move rows in the delta tables to the base table. A compress operation can only be performed by the ArcSDE administrator and operates against all states in the geodatabase, regardless of the version owner. After running a compress on a geodatabase, you should update the database statistics. See the section "Update statistics using Analyze in ArcCatalog" in the topic Updating statistics on a geodatabase licensed under ArcGIS Server Enterprise.

This topic covers the following information:

What happens during a compress operation

The compress operation first scans into memory the instance's state tree configuration. Using this information, compress 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 the state being deleted.

The next step the compress operation performs is to collapse 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, is to move rows from the delta tables into the base tables.

For each step of the operation, database transactions are started and stopped for each table being compressed. The transaction verifies each table is consistent during each step of the process.

The compress operation can be stopped or killed 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. You probably would never need to stop a compress while it is executing on an ArcSDE geodatabase for SQL Server Express but might do so on an ArcSDE geodatabase on one of the other supported DBMSs. One reason you might do this is if you run the compress while users are connected to the geodatabase, then discover the compress is consuming a large amount of system resources, you might want to stop the compress operation and run it again when fewer or no users are connected.

Achieving a full compress

Performance improvement will be greatest if the compress operation leaves no rows in the delta tables and the state tree is trimmed back to zero. To achieve this

See the topics Compressing an ArcSDE geodatabase licensed under ArcGIS Server Enterprise and Compressing a geodatabase on an ArcSDE database server to learn how to perform a compress operation.

It may not always be possible to reconcile, post, delete versions, and disconnect all users before a compress operation. For instance, if you are tracking history using versions or need to maintain design versions for a project, the historic and design versions remain pinned to a state within the state tree; therefore, these states will not be removed during a compress of the geodatabase. You can successfully compress without doing all these steps, and you will still see some performance improvements.

*ArcIMS does not acquire locks on states and, therefore, would not influence the compress. ArcGIS clients, including ArcIMS map services, do acquire locks and, therefore, will influence the compress operation.

You can see the results of each compress operation in the COMPRESS_LOG table in the geodatabase (SDE_compress_log in SQL Server and PostgreSQL databases). You can also check the VERSIONS table (SDE_versions in SQL Server and PostgreSQL databases) to see if the state ID for the DEFAULT version has returned to zero. If it has and there are no other outstanding versions, a full compression has been achieved.

Frequency of compress operations

The frequency with which you need to perform a compress operation is based on the amount of editing that takes place 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.

NOTE: It is important not to wait too long between compress operations; the greater the amount of editing activity that takes place, the longer it will take to compress the geodatabase. If you don't compress the geodatabase at least once a week, the compress could take several hours to complete when you do finally run it.

After compressing a geodatabase

You should update the statistics on your geodatabase after you have run a compress operation. For information on updating statistics, see About updating geodatabase statistics.

Notes about compressing a geodatabase in DB2

Since the compress transaction can be large, be sure to create enough logical logs and have enough log file space to handle the transaction.

Notes about compressing a geodatabase in Informix

Notes about compressing a geodatabase in Oracle

It is possible for compress transactions to be quite large. Therefore, for Oracle databases configured with automatic undo space management, make sure the ArcSDE administrator's UNDO_POOL is not set too low and that enough undo table space exists to complete the compress operation.

If you are manually controlling the undo space using rollback statements, you should create a separate rollback table space that is large enough to hold the transactions of the compress operation and assign one rollback segment to it. The size of the table space and rollback segment required depends on the number of states that will be deleted during the compress, but as a rule of thumb, you should start with a rollback segment of at least 300 MB. However, a much larger rollback segment may be required if data edits occur often or you compress infrequently.

You will need to set the name of the rollback segment in the COMPRESS_ROLLBACK_SEGMENT storage parameter of the DEFAULTS DBTUNE configuration keyword.

NOTE: This storage parameter doesn't exist under the DEFAULTS configuration keyword until you add it. If this parameter is not set, the next available online rollback segment will be used. If the rollback segment is not large enough, the compress operation will fail since the transaction will be forced to roll back.

Oracle recommends that you use automatic undo management. Starting with Oracle9i, automatic undo management is done by allocating space in the form of an undo table space instead of allocating rollback segments of different sizes.

Tip

Notes about compressing a geodatabase SQL Server

NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only

You need to rebuild your business tables’ clustered indexes after running a full compress, because business table fragmentation can occur with a full compress.

For information on compressing ArcSDE geodatabases for SQL Server Express, see Compressing a geodatabase on an ArcSDE database server.

See Also

  • Compressing a geodatabase on an ArcSDE database server
  • Compressing an ArcSDE geodatabase licensed under ArcGIS Server Enterprise