为什么我的ArcSDE数据库执行完版本压缩（Compress）后查询分析效率仍然很低

描述：为什么我的数据经过版本注册过后，效率很慢，而没有注册版本的数据效率很快。

分析：通过电话和邮件跟用户交流，用户之前的数据库做过大量的版本编辑，估计有千万条级别甚至上亿的，但是用户做过版本压缩的操作，疑惑的是用户在执行select * from state_linages发现只有一条记录时候效率很慢，基本上定位为版本数据肯定有State_lineages表，所以效率导致很慢。在分析用户问题过程中发现，虽然State_lineages表只有一条记录，但是该表在数据库的存储大小以及索引在数据库的存储大小高达6GB以上，基本上问题就发生在这里。

以下为查询表物理大小的方法：

C:\Users\Administrator>sqlplus sde/sde@orclSQL*Plus: Release 11.2.0.1.0 Production on 星期三 12月 21 09:21:24 2011Copyright (c) 1982, 2010, Oracle.  All rights reserved.连接到:Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing optionsSQL> select segment_name, bytes/1024/1024 "分配表的物理空间（MB）" from user_segments where segment_type='TABLE' and (segment_name='STATES' or segment_name='STATE_LINEAGES');SEGMENT_NAME--------------------------------------------------------------------------------分配表的物理空间（MB）----------------------STATES                     1STATE_LINEAGES                     7

因为数据库最后是按照最小的单位级别块、段等对象来查询的，（其实经常使用PL/SQL的用户应该都在查看表的记录会看到记录最右边的一个字段ROWID，那么这个ROWID就记录了这条记录在哪个表空间、哪个表、哪个段、哪个块存储着这条信息）对一条记录的表或者说表里面的记录比较少的情况下，系统默认都是全表扫描，肯定不会走空间索引，那么这一个表中的一条数据，全面扫描的话数据库不会知道在哪个段，那个块的，那么系统在查询这个记录时候肯定会不停的搜索，扫描，6GB的空间可见效率会很低。

但是如果该表有个上千，上万甚至十万记录等，会走空间索引的，所以给人感觉还不是那么的慢。

所以用户在执行版本压缩之后，用户可以执行truncate table等操作，单首先备份好当时的记录信息。

使用方法：

SQL> select segment_name, bytes/1024/1024 "分配表的物理空间（MB）" from user_segments where segment_type='TABLE' and segment_name='AA' ;SEGMENT_NAME--------------------------------------------------------------------------------分配表的物理空间（MB）----------------------AA                    35SQL> truncate table aa;表被截断。SQL> select segment_name, bytes/1024/1024 "分配表的物理空间（MB）" from user_segments where segment_type='TABLE' and segment_name='AA' ;SEGMENT_NAME--------------------------------------------------------------------------------分配表的物理空间（MB）----------------------AA                 .0625

其实看上面的或者了解数据库的都明白delete数据和truncate table的区别了，因为delete数据，虽然数据量减少了，但是这个表所占的空间随着该表数据的增加会扩展，但是删除数据空间并不会减少，所以就出现了用户反映的情况，所以使用truncate table 对数据表以及相关索引对象等的物理存储进行紧缩，这样无疑就加快了查询和分析效率。

索引可能产生碎片,因为记录从表中删除时,相应也从表的索引中删除.表释放的空间可以再用,而索引释放的空间却不能再用.频繁进行删除操作的被索引的表,应当阶段性地重建索引,以避免在索引中造成空间碎片,影响性能.在许可的条件下,也可以阶段性地truncate表,truncate命令删除表中所有记录,也删除索引碎片.

因为版本方面主要涉及的表包含State和State_lineages表，所以要时常关注这些表的变化和大小。

进行相关的联想

根据我们描述的这个问题，其实我们也可以进行思维发散，比如我们在实际工作中，我们对数据进行删除，但是我们可能会保存这个表结构，那么很多用法我们就使用编辑工具进行删除，其实还是上面的那个问题，虽然说数据不断增加，不断删除，但是数据空间在不断的加大，那么一旦使用全表扫描时，就会对整个大的空间进行扫描，即使你的数据表已经删除了，但是还会扫描很长时间，与上面说的问题比较类似。

我们查看一个要素类，然后获得它在数据库里面的实际大小

SQL> select bytes/1024/1024 from user_segments where segment_name='BIGFEATURECLASS';BYTES/1024/1024---------------             35

然后我们进行删除，在查看一个实际大小

SQL> select count(*) from bigfeatureclass;  COUNT(*)----------         0SQL> select bytes/1024/1024 from user_segments where segment_name='BIGFEATURECLASS';BYTES/1024/1024---------------             35

我们使用Sdetable -o truncate进行删除

C:\Users\Administrator>sdetable -o truncate -t bigfeatureclass -i sde:oracle11g:orcl -u test -p testArcSDE 10.0  for Oracle11g Build 1937 Tue Aug 16 16:08:18  2011Attribute        Administration Utility-----------------------------------------------------Truncate table bigfeatureclass!Are you sure? (Y/N): ySuccessfully truncated table bigfeatureclass.

然后我们再查看该要素类的大小

SQL> select bytes/1024/1024 from user_segments where segment_name='BIGFEATURECLASS';BYTES/1024/1024---------------          .0625

 -------------------------------------------------------------------------------------------------------
版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!
-------------------------------------------------------------------------------------------------------