地理数据库压缩操作
地理数据库压缩操作可从对版本以及版本化编辑进行跟踪的系统表中移除不必要的状态和行。
提示:要了解压缩，首先必须了解版本化的工作原理。如果您不熟悉此概念，请参阅了解版本化。
什么是压缩操作？
压缩操作可移除某版本不再引用的状态，还可将增量表中的行移动到业务表中。压缩操作只能由 ArcSDE 管理员来执行，可对地理数据库中的所有状态进行操作，与版本所有者无关。
压缩操作很有必要，因为随着对编辑地理数据库不断进行编辑，增量表的大小和状态的数量也会不断增加。表越大、状态越多，每次显示或查询版本时 ArcGIS 所必须处理的数据就越多。因此，对性能的最大影响不是版本的数量，而是增量表中对每个版本的更改量。因此，各个版本就可能具有不同的查询响应时间。
要维护数据库性能，ArcSDE 管理员必须定期运行压缩操作来移除未使用的数据。
可以使用 ArcCatalog 的“版本压缩”命令或“版本压缩”地理处理工具或 Python 脚本来压缩地理数据库。有关如何使 ArcCatalog 中的“版本压缩”命令可用的信息，请参阅将“版本压缩”命令添加到 ArcCatalog；有关地理处理工具或脚本的信息，请参阅版本压缩。
在版本压缩操作过程中会发生什么？
压缩操作首先会将实例的状态树配置扫描至内存。使用此信息，版本压缩将删除未包含在版本谱系内的所有状态。删除某个状态将从与该状态相关联的增量表中删除所有行。
压缩操作执行的下一个步骤是将状态的所有候选谱系折叠成一种状态。候选谱系是状态的集合，这些状态可在不影响给定版本中任何表的逻辑表示的情况下，版本压缩成一种状态。
最后一步（如果适用）就是将行从增量表移到业务表中。
对于每一步操作，将会针对每个正在被压缩的表启动和停止数据库事务。事务将验证每一步操作过程中各个表的一致程度。
在执行版本压缩操作时可以将其停止或终止，因为该操作目的在于事务处理的一致程度。因此，如果操作遇到错误、失败或突然停止，则无论对于哪种版本的表示，正在压缩的版本化表在逻辑上仍然正确。可能停止压缩操作的一个原因是，如果在用户连接到地理数据库时正在运行版本压缩操作，将发现它会消耗大量的系统资源。在这种情况下，您可能希望先停止压缩操作，然后在连接较少用户或未连接任何用户时再运行该操作。
因为压缩事务量可能会很大，所以要确保创建足够的逻辑日志，同时还要拥有足够的日志文件空间来处理事务。
完全压缩地理数据库
在完全压缩地理数据库过程中，增量表与状态树中不会有任何行缩减为零。如果完全压缩地理数据库，则性能会得到最大的改善。要达到此目的，需执行以下操作：
*ArcIMS 服务（不包括 ArcIMS 地图服务）不能获取状态上的锁，因此，它不会对压缩操作产生影响。ArcGIS 客户端（包括 ArcIMS 地图服务）则一定会获取锁，因此，它会对压缩操作产生影响。
可以从地理数据库的 COMPRESS_LOG 表（在 SQL Server 和 PostgreSQL 数据库中则为 SDE_compress_log 表）中查看每个压缩操作的结果。还可以检查 VERSIONS 表（在 SQL Server 和 PostgreSQL 数据库中则为 SDE_versions 表）来查看默认版本的状态 ID 是否已归零。如果已归零，并且不存在其他未完成的版本，则表明已实现完全压缩。
并不是总能够在压缩操作前协调、提交、删除版本以及断开所有用户的连接。例如，如果正在使用版本追踪历史记录，或需要保留某个项目的设计版本，则历史版本和设计版本会固定地保留到状态树内的某个状态中；因此，在压缩地理数据库时，将不会移除这些状态。无需执行上述所有步骤即可成功进行版本压缩，并且某些性能仍会有所改善。
要了解如何执行版本压缩操作，请参阅版本压缩在 ArcGIS Server Enterprise 下获得许可的 ArcSDE 地理数据库。
压缩操作的频率
执行版本压缩操作所需的频率取决于在地理数据库中进行的编辑量。如果编辑量大，则可能应当一天压缩一次地理数据库。对于中等或较小的编辑量，应至少一周压缩一次。
注：两次压缩操作间的时间间隔不能太长，这非常重要；所进行的版本化编辑活动量越大，在压缩地理数据库时花费的时间就越长。如果未能做到至少一周压缩一次地理数据库，则当最后运行压缩时，完成此过程可能会花费几个小时。
压缩地理数据库之后
应当在运行压缩操作后，更新地理数据库中的统计数据。有关更新统计数据的信息，请参阅使用“分析”更新地理数据库中的统计数据以及数据库管理系统 (DBMS) 的主题。