Note:This topic was updated for 9.3.1.
NOTE: Applies to geodatabases created with an ArcGIS Server Enterprise license only
As a geodatabase is edited over time, 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 adds (A) and deletes (D) tables for each version. As a result, versions can have different query response times.
To maintain database performance, the ArcSDE administrator must periodically run the ArcCatalog Compress command to remove unused data. Only the ArcSDE administrator can run a compress operation. Compressing performs two key tasks:
- Removes unreferenced states and their associated delta table rows
- Moves entries in the delta tables common to all versions into the base tables, reducing the amount of data the database management system (DBMS) will need to search through for each version query, thereby improving query performance and system response time
When a large volume of uncompressed changes have accumulated, compressing the database can take hours. To avoid this, compress on a regular basis. It is a good idea to compress at the end of every day or after a period of high database activity such as data loading.
During a compress, users can stay connected to the geodatabase. If any user is editing a version, the branch for that state is locked and will not take part in the compression. It's best, therefore, to have all users disconnect before starting to ensure the entire state tree can compress. It is not necessary to disconnect sessions that are read-only such as an ArcIMS session.
If you ever find yourself waiting for compress to complete because you need the computer for something else, you can end the compress at any time. This will not leave the database in an inconsistent state. You can continue compressing at a later time.
It is important to update statistics for every versioned feature class and table in the geodatabase both before and after compressing. After edits and a database compress have taken place, database statistics are no longer accurate. This hurts query performance. To learn how to update statistics, see
Updating statistics on a geodatabase licensed under ArcGIS Server Enterprise.
For more information on delta tables, states, and the compress operation, read the white paper entitled
Versioning. Go to http://support.esri.com and click the White Papers link on the Knowledge Base tab.
Tip
- Compressing geodatabases stored in user's schemas in Oracle
You compress a geodatabase stored in a user's schema in the same manner as the SDE master geodatabase. However, the compress operation must be performed by the schema owner, not the SDE user. If the SDE user tries to compress a geodatabase stored in another user's schema, the compress will fail with an insufficient permissions error.