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

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

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


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

C:\Users\Administrator>sqlplus sde/sde@orcl

SQL*Plus: Release 11.2.0.1.0 Production on 星期三 12月 21 09:21:24 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select segment_name, bytes/1024/1024 "分配表的物理空间(MB)" from user_seg
ments where segment_type='TABLE' and (segment_name='STATES' or segment_name='STA
TE_LINEAGES');

SEGMENT_NAME
--------------------------------------------------------------------------------

分配表的物理空间(MB)
----------------------
STATES
                     1

STATE_LINEAGES
                     7


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

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


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

使用方法:

SQL> select segment_name, bytes/1024/1024 "分配表的物理空间(MB)" from user_seg
ments where segment_type='TABLE' and segment_name='AA' ;

SEGMENT_NAME
--------------------------------------------------------------------------------

分配表的物理空间(MB)
----------------------
AA
                    35


SQL> truncate table aa;

表被截断。

SQL> select segment_name, bytes/1024/1024 "分配表的物理空间(MB)" from user_seg
ments 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(*)
----------
         0

SQL> 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 test


ArcSDE 10.0  for Oracle11g Build 1937 Tue Aug 16 16:08:18  2011
Attribute        Administration Utility
-----------------------------------------------------
Truncate table bigfeatureclass!
Are you sure? (Y/N): y
Successfully truncated table bigfeatureclass.

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

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

BYTES/1024/1024
---------------
          .0625


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

你可能感兴趣的:(为什么我的ArcSDE数据库执行完版本压缩(Compress)后查询分析效率仍然很低)