地理数据库压缩操作

地理数据库压缩操作可从对版本以及版本化编辑进行追踪的系统表中移除不必要的状态和行。

提示:

要了解压缩，首先必须了解版本化的工作原理。如果您不熟悉此概念，请参阅版本化快速浏览。

什么是压缩操作？

压缩操作可移除某版本不再引用的状态，还可将增量表中的行移动到业务表中。压缩操作只能由地理数据库管理员来执行，可对地理数据库中的所有状态进行操作，与版本所有者无关。

压缩操作很有必要，因为随着对编辑地理数据库不断进行编辑，增量表的大小和状态的数量也会不断增加。表越大、状态越多，每次显示或查询版本时 ArcGIS 所必须处理的数据就越多。因此，对性能的最大影响不是版本的数量，而是增量表中对每个版本的更改量。因此，各版本可能具有不同的查询响应时间。

要维护数据库性能，地理数据库管理员必须定期运行压缩操作来移除未使用的数据。

可以使用 ArcGIS for Desktop 的“版本压缩”命令或版本压缩地理处理工具或 Python 脚本来压缩地理数据库。有关压缩地理数据库的信息，请参阅目录树的压缩企业级地理数据库；有关地理处理工具或脚本的信息，请参阅压缩。

在版本压缩操作过程中会发生什么？

压缩操作首先会将实例的状态树配置扫描至内存。使用此信息，压缩将删除未包含在版本谱系内的所有状态。删除某个状态将从与该状态相关联的增量表中删除所有行。

压缩操作执行的下一个步骤是将状态的所有候选谱系折叠成一种状态。候选谱系是状态的集合，这些状态可在不影响给定版本中任何表的逻辑表示的情况下，版本压缩成一种状态。

最后一步（如果适用）就是将行从增量表移到基表（或业务表）中。

对于每一步操作，将会针对每个正在被压缩的表启动和停止数据库事务。事务将验证每一步操作过程中各个表的一致程度。

在执行版本压缩操作时可以将其停止，因为该操作目的在于事务处理的一致程度。因此，如果操作遇到错误、失败或突然停止，则无论对于哪种版本的表示，正在压缩的版本化表在逻辑上仍然正确。可能停止压缩操作的一个原因是，如果在用户连接到地理数据库时正在运行版本压缩操作，将发现它会消耗大量的系统资源。在这种情况下，您可能希望先停止操作，然后在连接较少用户或未连接任何用户时再运行该操作。

在运行压缩操作之后，需要重新针对基表构建聚类索引，因为压缩期间可能会产生业务表碎片。

完全压缩地理数据库

在完全压缩地理数据库过程中，增量表与状态树中不会有任何行缩减为零。如果完全压缩地理数据库，则性能会得到最大的改善。要达到此目的，需执行以下操作：

• 对子版本中所有未完成的更改进行协调并将其提交到 DEFAULT 版本。作为地理数据库管理员，您可以通过打开地理数据库管理 对话框上的版本选项卡上的协调顺序子选项卡来查看版本的默认协调顺序。有关协调顺序子选项卡的信息，请参阅版本属性。
• 在协调和提交编辑内容后，删除版本自身。
• 确保未连接任何用户。
• 执行压缩操作。

可以从地理数据库的 COMPRESS_LOG 表（在 SQL Server 和 PostgreSQL 中的地理数据库中则为 SDE_compress_log 表）中查看每个压缩操作的结果。还可以检查 VERSIONS 表（在 SQL Server 和 PostgreSQL 中的地理数据库中则为 SDE_versions 表）来查看默认版本的状态 ID 是否已归零。如果已归零，并且不存在其他未完成的版本，则表明已实现完全压缩。

并不是总能够在压缩操作前协调、提交、删除版本以及断开所有用户的连接。例如，如果正在使用版本追踪历史记录，或需要保留某个项目的设计版本，则历史版本和设计版本会保持在状态树内的某个状态；因此，在压缩地理数据库时，将不会移除这些状态。无需执行上述所有步骤即可成功进行版本压缩，并且某些性能仍会有所改善。

压缩操作的频率

执行版本压缩操作所需的频率取决于在地理数据库中进行的编辑量。如果编辑量大，则可能应当一天压缩一次地理数据库。对于中等或较小的编辑量，应至少一周压缩一次。

注:

两次压缩操作间的时间间隔不能太长，这非常重要；所进行的版本化编辑活动量越大，在压缩地理数据库时花费的时间就越长。如果未能做到至少一周压缩一次地理数据库，则当最后运行压缩时，完成此过程可能会花费几个小时。

压缩地理数据库之后

应当在运行压缩操作后，更新地理数据库中的统计数据。地理数据库管理员应更新系统表中的统计数据，各用户可以更新经过编辑的数据集中的统计数据。有关统计数据的信息，请参阅使用“分析数据集”工具更新地理数据库系统表中的统计数据或使用“分析”更新地理数据库中的统计数据。