[Bug]ArcSDE10/10.1删除非版本数据慢的问题

环境：

中间件：ArcSDE10/10.1

数据库：Oracle

现象：用户在非版本编辑过程中，如果数据量非常大的情况下，在使用桌面删除某几条数据，速度非常慢。

一说起慢，大家都会想到是不是空间索引的问题，也会习惯性的重建空间索引，或者进行分析操作，但是做了这些之后，效果仍然不明显，那么问题的原因出在哪里呢？

----------------------------------------------------------------------------------

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

Blog:               http://blog.csdn.net/linghe301

----------------------------------------------------------------------------------

首先我们还是要说明一下ArcSDE for Oracle的空间索引。

关于ArcSDE性能优化系列之索引篇的知识可以参考：http://blog.csdn.net/linghe301/article/details/6269847

使用 ST_Geometry 存储方式创建的具有空间索引的要素类会在 Oracle 数据库中创建另一个表。此空间索引表的名称为 S<n>_IDX$，其中 <n> 是该表的几何索引值。可通过查询 SDE.ST_GEOMETRY_COLUMNS 表来获取该值。此空间索引表被创建为 Oracle 索引组织表 (IOT)。通过企业管理器查看时，ST_Geometry 属性的空间索引显示为 A<n>_IX1。值 <n> 表示存储在 LAYERS 表中的 LAYER_ID 值。


在 S<n>_IDX$ 表中还创建了另外两个索引：S<n>$_IX1 和 S<n>$_IX2。可以通过更改创建要素类时指定的 DBTUNE 配置关键字中的 S_STORAGE 参数来指定这些索引在 DBMS 中的存储方式。

从上面的描述我们可以得出，ArcSDE的要素类的高效浏览直接原因就是空间索引，但是空间索引也是有索引的，也就是说所谓的S表是空间索引表，但是空间索引表还有索引就是上面提到的S<n>$_IX1 和 S<n>$_IX2。

我们以ArcSDE10.1为例来看一下相关信息

我们看一下空间索引表的结构

SQL> desc s45_IDX$
 名称                                      是否为空? 类型
 ----------------------------------------- -------- ---------------------
 GX                                        NOT NULL NUMBER(38)
 GY                                        NOT NULL NUMBER(38)
 MINX                                      NOT NULL NUMBER(38)
 MINY                                      NOT NULL NUMBER(38)
 MAXX                                      NOT NULL NUMBER(38)
 MAXY                                      NOT NULL NUMBER(38)
 SP_ID                                     NOT NULL ROWID

然后根据这个空间索引表，我们看看这个索引表的索引是

SQL> select index_name,index_type from user_indexes where table_name='S45_IDX$';

INDEX_NAME                     INDEX_TYPE
------------------------------ ---------------------------
S45$_IX1                       IOT - TOP

我们看到，ArcSDE10/10.1的空间索引的索引只有一个表，而不是上面所述的两个表，而且这个索引表的类型是IOT的，IOT索引一般是创建主键索引

----------------------------------------------------------------------------------

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

Blog:               http://blog.csdn.net/linghe301

----------------------------------------------------------------------------------

我们看看ArcSDE10.2的空间索引的索引

SQL> select index_name,index_type from user_indexes where table_name='S4_IDX$';

INDEX_NAME                     INDEX_TYPE
------------------------------ ---------------------------
S4$_IX1                        IOT - TOP
S4$_IX2                        NORMAL

这里面我们看到创建了有两个索引对象一个是IOT一个是NORMAL

SQL> select dbms_metadata.get_ddl('INDEX','S4$_IX1','SDE') from dual;

DBMS_METADATA.GET_DDL('INDEX','S4$_IX1','SDE')
--------------------------------------------------------------------------------

  CREATE UNIQUE INDEX "SDE"."S4$_IX1" ON "SDE"."S4_IDX$" ("GX", "GY", "MAXX", "MAXY", "MINX", "MINY", "SP_ID")
  PCTFREE 0 INITRANS 4 MAXTRANS 255
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "SDE"


SQL> select dbms_metadata.get_ddl('INDEX','S4$_IX2','SDE') from dual;

DBMS_METADATA.GET_DDL('INDEX','S4$_IX2','SDE')
--------------------------------------------------------------------------------

  CREATE INDEX "SDE"."S4$_IX2" ON "SDE"."S4_IDX$" ("SP_ID")
  PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "SDE"

从这两个不同的索引类型来说，IX2（Normal）的索引的选择度要高于IX1（IOT）,而且IX2 是以索引的对象的SP_ID字段做索引的，效率是很高的。

所以，问题的根本原因就是ArcSDE10/10.1修改了源码，导致没有创建Normal类型的空间索引的索引，导致在查询空间索引的基础上效率不高的。

不过这个问题在ArcSDE10.2已经解决了。

解决方法可以参考：http://support.esri.com/en/knowledgebase/techarticles/detail/40871

补丁发布：http://support.esri.com/en/downloads/patches-servicepacks/view/productid/66/metaid/1941

----------------------------------------------------------------------------------

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

Blog:               http://blog.csdn.net/linghe301

----------------------------------------------------------------------------------

Bug NIM-084235

Nimbus ID	NIM084235
Submitted	Aug 28, 2012 4:22 PM
Severity	Critical
Applies To	ArcGIS
Version Found	10.1
Prog Language	N/A
Server Platform	All
Client Platform
Database	Oracle
Locale	N/A
Status	Resolved
Version Fixed	10.2
SP Fixed	10.2

Synopsis

St_Geometry spatial indexes do not create S###$_IX2 indexes on the IOT SP_ID column.

Additional Status Information

N/A

Alternate Solution

Create the index manually

感谢@liufeng的技术指导！

----------------------------------------------------------------------------------

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

Blog:               http://blog.csdn.net/linghe301

----------------------------------------------------------------------------------