关于ArcSDE版本压缩（Compress）的再研究

这两天一同事研究版本，讨论及ArcSDE版本压缩了，这个版本压缩很简单啊，不就是执行以下Compress么？

但是就是这么简单的问题，我也曾经研究过相关的东西，竟然还有那么多不为人知的小秘密……

==================版本压缩原理==============

        随着时间的推移，地理数据库在经过多次编辑后，增量表会逐渐增大，并且状态的数量也会增加。表越大且状态越多，每次显示或查询版本时 ArcGIS 必须处理的数据就越多。因此，对性能的最大影响不是版本的数量，而是包含在每个版本的增量表中的更改数量。因此，各个版本就可能具有不同的查询响应时间。

版本的相关原理：http://wenku.baidu.com/view/7ad2ec7d27284b73f24250fe.html

上面描述了我们在ArcSDE版本编辑过程中会形成相当复杂的表关系，那么在进行查询或者分析势必要通过这些复杂的表关系来进行关联才能得到相关的结果，但是我们在版本编辑后，其实当子版本的数据已经协调提交到Default版本后，那些子版本的信息（主要包括相关的编辑状态已经没有什么作用了），但是如果这些信息存在，在查询或者分析数据时还是会对这些信息进行筛选，那么这就会造成长时间版本编辑后，效率越来越低下。

那么版本压缩工作就是（只有 ArcSDE 管理员（sde 或 dbo 用户）才能执行压缩操作）

1：它会移除未引用的状态及其关联增量表行

2：它会将所有版本共用的增量表条目移至基表中，这可以减少每次查询版本时数据库所需要搜素的数据量，从而提高查询性能并减少系统响应时间。

在使用过程中往往会出现怎么压缩也压不下去，实际表现在增量表的数据没有被移至到基表中或者状态表的无效信息并没有被删除。

那么是什么问题造成的呢？

1：压缩过程中，用户可以保持与地理数据库的连接。如果某个用户正在编辑一个版本，则该状态的分支将被锁定并且不会参与压缩过程。因此，最好在开始压缩前断开所有用户与地理数据库的连接，以确保可以压缩整个状态树。不必断开类型为只读的会话（例如 ArcIMS 会话）。

2：数据库里面还存在子版本

该子版本包括ArcGIS版本管理创建的子版本，也包括同步复制过程中创建的版本（这个让笔者测试非常郁闷，因为不是很好估计），其实也就是SDE用户下Versions表里面原则上只能有一条记录，也就是default版本的记录。

============压缩前的准备=========================

所以说，综上所述，如果想进行完全的压缩需要做以下事情

1：保证数据库除SDE用户外其他用户断开连接

2：所有子版本数据进行协调提交到default版本

3：删除所有子版本数据，（注意同步复制建立的版本信息）

4：删除所有的lock信息或者重新启动ArcSDE服务

============压缩注意的事情========================

1：建议用户根据自己的时间编辑量合理安排压缩频率

     用户可以查看那些状态表信息，数据量特别大的执行天天压缩的习惯，严禁出现数据库里面已经存在几千万上亿条状态值了，实在慢的不行了再进行压缩，那只能是几天几夜的压，说不定还给你报个错误，什么都晚了。

2：如果在等待压缩操作完成的过程中需要计算机去执行其他任务，您可以随时结束压缩操作。这不会导致数据库处于不一致状态。可以在以后继续压缩。

3：在压缩前和压缩后更新地理数据库中每个版本化要素类和表的统计数据是很重要的。执行编辑并压缩数据库之后，数据库统计数据将不再准确。这会对查询性能造成不利影响。