Oracle空间函数SDO_CS.转换（值）结果非常慢

我有一个自定义视图，它从几何体列查询空间数据并提取纬度/长度值。但是，检索过程非常缓慢，检索视图数据最多需要5到10分钟

以下是我的看法：

CREATE OR REPLACE FORCE VIEW PoleData
(
   G3E_FID,
   X_COORD,
   Y_COORD,
   LATITUDE,
   LONGITUDE
)
AS
   SELECT P.g3e_fid,
          T2.X * 1000 AS x_coord,
          T2.Y * 1000 AS y_coord,
          T.Y AS latitude,
          T.X AS longitude
     FROM PolePoint P,
          TABLE (
             SDO_UTIL.GETVERTICES (SDO_CS.TRANSFORM (P.G3E_GEOMETRY, 8265))) T,
          TABLE (SDO_UTIL.GETVERTICES (P.G3E_GEOMETRY)) T2
    WHERE P.ltt_id = 0
   UNION
   SELECT P.g3e_fid,
          T2.X * 1000 AS x_coord,
          T2.Y * 1000 AS y_coord,
          T.Y AS latitude,
          T.X AS longitude
     FROM PoleDetailPoint P,
          TABLE (
             SDO_UTIL.GETVERTICES (SDO_CS.TRANSFORM (P.G3E_GEOMETRY, 8265))) T,
          TABLE (SDO_UTIL.GETVERTICES (P.G3E_GEOMETRY)) T2
    WHERE P.ltt_id = 0;

G3E\U几何图形

列属于

SDO\U几何图形

类型。PolePoint表格有1310629行，而PoleDetailPoint表格有100行。此表中的数据每天更新，而视图用于报告目的

我尝试使用

status=cleanup

参数重建空间索引。但那没什么区别

我们的版本是Oracle 11.2.0.3

---

任何关于检索此类视图/数据的提示都值得赞赏。或者我可以用来更快实现这一点的任何其他空间函数？

您是否尝试将强制转换到表元素移动到with子句中

通常，它们非常慢，特别是当优化器决定为联接表中的每一行运行它们时（以检查结果集是否已更改）

试试这个：

with t as (select * from table (sdo_util.getvertices (sdo_cs.transform (p.g3e_geometry, 8265)))),
     t2 as (select * from table (sdo_util.getvertices (p.g3e_geometry)))
select p.g3e_fid,
       t2.x * 1000 as x_coord,
       t2.y * 1000 as y_coord,
       t.y as latitude,
       t.x as longitude
  from polepoint p, t, t2
 where p.ltt_id = 0
union 
select p.g3e_fid,
       t2.x * 1000 as x_coord,
       t2.y * 1000 as y_coord,
       t.y as latitude,
       t.x as longitude
  from poledetailpoint p, t, t2
 where p.ltt_id = 0;

另外，您确定需要

“union”

（强制排序过滤器）而不是

“union all”

？（即，您是否希望得到重复的结果？如果没有，请使用

union all

）

问候

---

Olafur

尝试使用

UNION ALL

而不是

UNION

：

SELECT P.g3e_fid,
       T2.X * 1000 AS x_coord,
       T2.Y * 1000 AS y_coord,
       T.Y AS latitude,
       T.X AS longitude
  FROM PolePoint P,
       TABLE (
          SDO_UTIL.GETVERTICES (SDO_CS.TRANSFORM (P.G3E_GEOMETRY, 8265))) T,
       TABLE (SDO_UTIL.GETVERTICES (P.G3E_GEOMETRY)) T2
 WHERE P.ltt_id = 0
UNION ALL
SELECT P.g3e_fid,
       T2.X * 1000 AS x_coord,
       T2.Y * 1000 AS y_coord,
       T.Y AS latitude,
       T.X AS longitude
  FROM PoleDetailPoint P,
       TABLE (
          SDO_UTIL.GETVERTICES (SDO_CS.TRANSFORM (P.G3E_GEOMETRY, 8265))) T,
       TABLE (SDO_UTIL.GETVERTICES (P.G3E_GEOMETRY)) T2
 WHERE P.ltt_id = 0;

性能下降的另一个潜在原因是，您正在使用两个调用

SDO_UTIL.GET_顶点

，一个直接调用

p.G3E_几何体

，另一个调用调用

p.G3E_几何体的变换

，这两个顶点列表基本上是一个叉积，因此，例如，如果一个特定的

P.G3E_几何体

包含5个顶点，那么对于该5个顶点

P.G3E_几何体

的25个可能的T和T2组合中的每一个，您将得到5*5个记录。我不知道顶点顺序是否由

SDO_CS.TRANSFORM

函数维护，但如果是，您可以通过向查询的每一半添加

和t1.id=t2.id

谓词来提高性能：

SELECT P.g3e_fid,
       T2.X * 1000 AS x_coord,
       T2.Y * 1000 AS y_coord,
       T.Y AS latitude,
       T.X AS longitude
  FROM PolePoint P,
       TABLE (
          SDO_UTIL.GETVERTICES (SDO_CS.TRANSFORM (P.G3E_GEOMETRY, 8265))) T,
       TABLE (SDO_UTIL.GETVERTICES (P.G3E_GEOMETRY)) T2
 WHERE P.ltt_id = 0
   AND T.ID = T2.ID
UNION ALL
SELECT P.g3e_fid,
       T2.X * 1000 AS x_coord,
       T2.Y * 1000 AS y_coord,
       T.Y AS latitude,
       T.X AS longitude
  FROM PoleDetailPoint P,
       TABLE (
          SDO_UTIL.GETVERTICES (SDO_CS.TRANSFORM (P.G3E_GEOMETRY, 8265))) T,
       TABLE (SDO_UTIL.GETVERTICES (P.G3E_GEOMETRY)) T2
 WHERE P.ltt_id = 0
   AND T.ID = T2.ID;

---

为什么这个问题被否决了？否决投票的用户能否解释原因？如果PolePoint和PoleDetailPoint没有重叠，您可以使用

UNION ALL

而不是

UNION

，那么DB将不必对结果进行区分。您真的需要

UNION

？为什么不使用

union all

？手头没有时间和数据来处理它，但我会尝试提示第一条语句在主表和支持用于空间列的嵌套表的隐藏表之间使用哈希。我怀疑NL使用嵌套表上的索引。您能发布执行计划吗？您如何准确地查询此视图？正如弗洛林所建议的，一个解释计划将是有用的。生成这样一个：

explain plan for select*from PoleData

然后

从表中选择*（dbms\u xplan.display）。性能可能与SDO无关，它可能只是一个糟糕的执行计划。不能使用with子句将cast to table元素拉出，因为它们依赖于polepoint表。注意p.g3e_几何参考。啊，当然是的。我现在看到了。但这也解释了为什么它这么慢。表（sdo_util.getvertices（…）针对polepoint中的每一行运行2次，针对poledetailpoint中的每一行运行2次。