OracleSpatial处理多图层的效率问题
从原始的trc文件中可以查询出一共包含多少条这种语句。
最近碰到一个OracleSpaital的效率问题，问题的描述具体如下：
某customer在矢量数据存储方案上选择了使用OracleSpaital的SDO_GEOMETRY进行存储，但是在前端软件的出图的速度上非常慢，已经让人不能接受了，回公司后，自己模拟了一个数据分别针对于SDO_GEOMETRY和ST_GEOMETRY两种存储方式进行了测试，发现SDO_GEOMETRY的确存在着很大的效率问题，以下为测试环境以及结果：
机器1：ArcGIS Server机器
OS: Linux Redhat 5.5+64bit
ArcGIS Server: 10+SP1
DBMS: oracle 10.2.0.4 服务器，实际上只使用了它的客户端功能
2cpu, 4core , 2.8G,4G physical memory
机器2：数据库服务器
OS: Linux Redhat 5.5+64bit
1 cpu 2core, 2.8 G ,4G physical memory
DBMS: Oracle10.2.0.4 服务器
ArcSDE: 9.3.1+sp2
数据情况：
一共80多个图层，大部分的图层没有数据，其中只有10个左右的图层有数据，一共的数据量为100M左右。
测试结果：
|
SDO_GEOMETRY |
ST_GEOMETRY |
|
|
时间 |
4.5s |
0.8s |
原因分析：
分别抓取了一下两种存储方式后台所执行的SQL语句，
原始跟踪文件为附件中的test_ora_sdo_geometry.trc和test_ora_st_geometry.trc, 格式化的trc分别为test_ora_sdo_geometry.txt和test_ora_st_geometry.txt.
从格式化后的跟踪文件中发现OracleSpatial所耗费的大部分时间花费在以下的SQL中。
SELECT DBMS_ASSERT.QUALIFIED_SQL_NAME( :1 ) FROM DUAL
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 2508 0.04 0.03 0 0 0 0
Execute 2508 0.26 0.24 0 0 0 0
Fetch 2508 0.25 0.26 0 0 0 2508
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 7524 0.56 0.55 0 0 0 2508
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 63 (SDE) ()
**************************************************************************************************
SELECT DBMS_ASSERT.SCHEMA_NAME( :1 )
FROM
DUAL
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1596 0.02 0.02 0 0 0 0
Execute 1596 0.16 0.15 0 0 0 0
Fetch 1596 0.16 0.16 0 0 0 1596
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4788 0.35 0.33 0 0 0 1596
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 63 (SDE) ()
****************************************************************************************************
SELECT diminfo, nvl(srid,-1)
FROM
ALL_SDO_GEOM_METADATA WHERE OWNER = :own AND TABLE_NAME = NLS_UPPER(:tab)
AND '"'||COLUMN_NAME||'"' = :col
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 228 0.00 0.00 0 0 0 0
Execute 228 0.19 0.19 0 9 0 0
Fetch 228 1.61 1.57 0 5523 0 228
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 684 1.82 1.77 0 5532 0 228
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 63 (SDE) ()
由于这些语句的(recursive depth: 1)，因此都是Oracle内部所执行的SQL，在此得解释一下何为内部执行的sql，Oracle所执行的sql语句分两种，一种为用户所提交sql，另外一种为内部sql，这些内部sql语句一般都访问的是Oracle的数据字典等等，如：
在当你提交了一条select * from test语句后，Oracle后台会执行类似于select obj from obj#等查询test表的原信息的sql语句，此类语句为oracle的内部语句，其recursive depth都为大于1的值。
上述所执行的sql从字面上看一部分是后台的验证工作，如
SELECT DBMS_ASSERT.SCHEMA_NAME是验证SDE这个schema是否有问题，另一部分是用来查询表的元信息，如
SELECT diminfo, nvl(srid,-1)
FROM
ALL_SDO_GEOM_METADATA WHERE OWNER = :own AND TABLE_NAME = NLS_UPPER(:tab)
AND '"'||COLUMN_NAME||'"' = :col。从原始的trc文件中可以查询出一共包含多少条这种语句。
192.168.100.228 [oracle udump]$ grep DBMS_ASSERT test_ora_25346.trc|wc -l
4104
192.168.100.228 [oracle udump]$ grep "SELECT diminfo" test_ora_25346.trc|wc -l 228
而是用ST_GEOMETRY存储进行存储的时候，上述的SQL语句是不会执行的，因此大大减少了响应时间。
192.168.100.228 [oracle udump]$ grep DBMS_ASSERT test_ora_25727.trc|wc -l 0
192.168.100.228 [oracle udump]$ grep "SELECT diminfo" test_ora_25727.trc|wc -l
0
最后是同样的操作，使用两种存储方式的总的时间统计。
sql sql
SDO_GEOMETRY
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1065 0.07 0.06 0 0 0 0
Execute 1097 5.11 5.04 0 101440 456 0
Fetch 1097 0.38 0.39 0 13118 0 1055
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3259 5.56 5.50 0 114558 456 1055
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 5848 0.17 0.14 0 0 0 0
Execute 7745 1.30 1.26 0 57 0 288
Fetch 8325 2.25 2.23 5 27905 0 8276
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 21918 3.73 3.65 5 27962 0 8564
ST_GEOMETRY
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 768 0.36 0.35 0 4148 0 0
Execute 788 1.09 1.05 0 29564 0 0
Fetch 788 0.15 0.17 0 2499 0 761
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2344 1.61 1.58 0 36211 0 761
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 467 0.04 0.04 0 0 0 0
Execute 577 0.28 0.27 0 0 0 32
Fetch 545 0.06 0.06 0 2162 0 328
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 1589 0.39 0.37 0 2162 0 360
最终通过与Oracle中国的工程师进行沟通，Oracle的工程师确认此为Oracle产品本身的问题，需要同美国oracle研发人员沟通解决。
不要迷恋哥，哥只是个软件。
转载自：https://blog.csdn.net/liufeng1980423/article/details/6095952
