ArcGIS的Compress、Compact、Analyze命令（转）

ArcGIS的Compress、Compact、Analyze命令

(转自http://www.gisall.com/html/19/121719-3167.html)

ArcGIS的Compress命令有两种，一种是对ArcSDE数据的压缩命令，一种是针对FileGDB数据的压缩命令。

ArcSDE数据的Compress

使用方式

以下相关命令的使用方式类比参考

1：ArcCatalog方式。

1．在ArcCatalog中，单击View菜单，指向Toolbars，并单击Customize。

2．复选toolbars列表中的Context Menus。

3．单击Context Menus菜单。

4．单击Remote Database Context Menu旁边的箭头。

5．单击定制对话框中的Commands选项卡。

6．单击Geodatabase tools。

7．单击并从Commands列表中拖动Compress Database命令到Remote Database Context Menu的子菜单中。

该命令出现在弹出式菜单中。

8．单击定制对话框的Close按钮

2：ArcToolbox方式

Database-Compress

3：代码方式

IVersionedWorkspace.Compress

4：命令行

compress_management 'Database Connections\Connection to deerfoot.sde'

5：脚本语言

import arcgisscripting

gp = arcgisscripting.create()

gp.toolbox = "management"

gp.compress("Database Connections\Connection to deerfoot.sde"

 

6：SDE命令

sdeversion -o compress [-N]

[-u <DB_user_name>] [-p <DB_User_password>] [-q]

[-i <service>] [-s <server_name>] [-D <database>]

版本原理简单介绍

利用ArcGIS版本进行管理，在版本注册（without the option to move edits to base）针对某个要素类会产生一组Delta表（A表增加表、D表删除表），数据的编辑信息其实是记录在Delta表中，然后在SDE元数据库中的States表中记录编辑的状态，State_lineages表记录一个要素的横向变化。利用State_ID来对这些表进行相互关联。但是在用户在操作过程中会多次协调、提交，在子版本没有提交Default版本的情况下删除子版本等等，这些都会在数据库中的产生大量的冗余或者无效数据，如果时间累计，则会造成数据的查询分析效率低下。

适用范围

利用ArcGIS版本原理来管理SDE数据库，并且对数据进行频繁的编辑（增加、删除、修改）

压缩前准备

<!--[if !supportLists]-->Ø <!--[endif]-->按照工作需求，尽量对版本进行协调和提交

<!--[if !supportLists]-->Ø <!--[endif]-->删除已经协调过的版本

压缩（Compress）命令在没有首先进行版本调和、提交和删除版本的情况下也可以执行，但压缩效率可能不明显。

压缩目标

1：删除未引用的状态和多余的数据（States）

<!--[if !supportLists]-->Ø <!--[endif]-->某个版本进行删除之后，该版本的相关操作状态

<!--[if !supportLists]-->Ø <!--[endif]-->重复进行版本协调、提交产生的状态等

减少存储空间

2：将所有版本的Delta表数据转移到Base表中(without the option to move edits to base)

减少检索时间

压缩建议

建议定期对版本数据进行压缩。如果累计时间太久，数据量巨大，则压缩时间也会相应加长

压缩注意事项

<!--[if !supportLists]-->Ø <!--[endif]-->只有ArcSDE管理员才能执行Compress操作，不能压缩其他用户的数据

<!--[if !supportLists]-->Ø <!--[endif]-->一旦数据库进行压缩之后，删除数据不能恢复。

<!--[if !supportLists]-->Ø <!--[endif]-->压缩完数据库之后，建议使用Analyze工具进行数据库统计，这样就会加快显示和查询的性能

<!--[if !supportLists]-->Ø <!--[endif]-->压缩时用户可以连接，但是如果有用户进行编辑，则被锁定不参与压缩。

FGDB数据的Compress

数据类型

支持：Geodatabase、数据集、要素类、普通表等

半支持：Raster Dataset、Raster Catalog通过GP工具才能实现

不支持： Schematic、Cadastral fabric、 Survey dataset

应用范围

成熟的数据（不需要经常编辑的数据）

压缩原理

将数据压缩为Read-Only格式

压缩效果

可以减少文件的存储空间

可以感觉到在查询和显示方面有轻微的性能改进，但其他操作略有减缓

压缩限制

压缩后的数据不能进行数据编辑。

可以编辑的：要素类名称（别名）、属性索引、元数据

压缩说明

压缩为无损的，不会有信息丢失

压缩依据

<!--[if !supportLists]-->Ø <!--[endif]-->要素类中构成要素点的平均数

<!--[if !supportLists]-->n <!--[endif]-->点和简单线压缩比要高于多点构成的线或者面

<!--[if !supportLists]-->Ø <!--[endif]-->字段类型

<!--[if !supportLists]-->n <!--[endif]-->文本、整型、日期型等压缩比要高于浮点型和双精度类型

<!--[if !supportLists]-->Ø <!--[endif]-->分辨率（resolution)

<!--[if !supportLists]-->n <!--[endif]-->分辨率高的压缩比高于分辨率低的

压缩注意

压缩的数据可以进行创建、复制、粘贴等功能。那么就数据就会包括已压缩的数据和未压缩的数据的混合状态。但是如果需要编辑数据，需要重新解压缩数据。

如果压缩关系类的一侧，不能编辑另一测。混合状态可以创建拓扑，但仅限于未压缩的数据。

Compacting file and personal geodatabases

原因

当第一次将数据加载到FGDB或者PGDB中时，文件中的记录是顺序排列的，但是如果以后删除或者添加要素，则文件中的记录就没有顺序了，会存在很多没有利用的空间，这将加大文件存储的空间，使得数据访问起来速度很慢。

作用

Compacting是将文件记录整理、重新归类，以减少存储空间。

范围

如果经常添加或者删除数据，就必须定期对数据实现Compact，这能够减少文件大小，提高访问速度。

注意

如果数据被独占不能进行Compact功能

Analyze

适用范围

数据集

业务表、要素表、A表、D表、历史表、栅格表

单独表分析使用Arctoolbox工具

分析原理

更新表的统计信息以及这些表的索引的统计信息

适用情况

在数据加载、数据删除、数据更新、数据压缩等操作

适用目的

提高数据库检索查询的效率

其他

如果该要素数据集包含几何网络，则该网络的表也进行了更新。

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

(以下转自http://blog.csdn.net/linghe301/article/details/6399036)

这两天一同事研究版本，讨论及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：在压缩前和压缩后更新地理数据库中每个版本化要素类和表的统计数据是很重要的。执行编辑并压缩数据库之后，数据库统计数据将不再准确。这会对查询性能造成不利影响。