Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › start with connect by 走全表，怎么优化
发新帖
bamuta

5

积分

1

好友

4

主题

[ORA-600/ORA-7445] start with connect by 走全表，怎么优化

1#
发表于 2013-11-2 16:31:54 | 查看: 13690| 回复: 15
本帖最后由 bamuta 于 2013-11-2 18:55 编辑

基本环境
操作系统：windows server 2008 r2 enterprise

SQL> select * from V$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE        10.2.0.4.0        Production
TNS for 64-bit Windows: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production



开发中的库，在做测试时，发现有1SQL比较消耗资源，我想把他优化一下。

SQL如下：
SELECT r.OUT_VER_BEGIN_ID dataID
  FROM DMS_DATA_RELA r, DMS_OBJ o
WHERE r.DELETE_FLAG = '0'
   AND r.RELA_TYPE_CODE = 'parent'
   AND r.OUT_OBJ_CODE = o.OBJ_CODE
   AND o.DELETE_FLAG = '0'
   AND o.OPEN_STATE = '1'
   AND r.IN_OBJ_CODE != 'o_in'
START WITH r.IN_DATA_ID in
            (SELECT d.OUT_DATA_ID
               FROM DMS_DATA_RELA d
              where d.OUT_VER_BEGIN_ID = :1
                and d.last_curent_flag = '1')
CONNECT BY r.IN_VER_BEGIN_ID = PRIOR r.OUT_VER_BEGIN_ID

执行计划： （来自awrsqrpt)

0  SELECT STATEMENT        8045 (100)   
1     FILTER            
2       CONNECT BY WITH FILTERING            
3         FILTER            
4           COUNT            
5             HASH JOIN    717K 111M 8045 (1) 00:01:37  
6               TABLE ACCESS FULL  DMS_OBJ  41  656  3 (0) 00:00:01  
7               TABLE ACCESS FULL  DMS_DATA_RELA  717K 100M 8037 (1) 00:01:37  
8           TABLE ACCESS BY INDEX ROWID DMS_DATA_RELA  1  91  4 (0) 00:00:01  
9             INDEX RANGE SCAN  OUT_VER_BEGIN_ID_INDEX  1    3 (0) 00:00:01  
10         HASH JOIN            
11           CONNECT BY PUMP            
12           COUNT            
13             HASH JOIN    717K 111M 8045 (1) 00:01:37  
14               TABLE ACCESS FULL  DMS_OBJ  41  656  3 (0) 00:00:01  
15               TABLE ACCESS FULL  DMS_DATA_RELA  717K 100M 8037 (1) 00:01:37  

随便找个变量单独执行这条SQL试了下，大概能执行6秒。

表上记录数
SQL> select count(*) from dms_data_rela;
  COUNT(*)
----------
    858470

SQL> select count(*) from dms_obj;
  COUNT(*)
----------
        41


表上索引：（索引较多，如果不影响此条SQL的查询性能，先不考虑这些索引合不合理，因为有些非技术因素）

SQL> select index_name,column_name,table_name from dba_ind_columns where table_name ='DMS_DATA_RELA' order by index_name;
INDEX_NAME                     COLUMN_NAME          TABLE_NAME
------------------------------ -------------------- ------------------------------
CREATE_TIME_INDEX              SYS_NC00031$         DMS_DATA_RELA
DELETE_FLAG_INDEX              DELETE_FLAG          DMS_DATA_RELA
IN_DATA_ID_INDEX               IN_DATA_ID           DMS_DATA_RELA
IN_DATA_NAME_INDEX             IN_DATA_NAME         DMS_DATA_RELA
IN_DATA_SOURCE_CODE_INDEX      IN_DATA_SOURCE_CODE  DMS_DATA_RELA
IN_DATA_SOURCE_ID_INDEX        IN_DATA_SOURCE_ID    DMS_DATA_RELA
IN_OBJ_CODE_INDEX              IN_OBJ_CODE          DMS_DATA_RELA
IN_VER_BEGIN_ID_INDEX          IN_VER_BEGIN_ID      DMS_DATA_RELA
LAST_CURENT_FLAG_INDEX         LAST_CURENT_FLAG     DMS_DATA_RELA
OUT_DATA_ID_INDEX              OUT_DATA_ID          DMS_DATA_RELA
OUT_DATA_NAME_INDEX            OUT_DATA_NAME        DMS_DATA_RELA
OUT_DATA_SOURCE_ID_INDEX       OUT_DATA_SOURCE_ID   DMS_DATA_RELA
OUT_OBJ_CODE_INDEX             OUT_OBJ_CODE         DMS_DATA_RELA
OUT_VER_BEGIN_ID_INDEX         OUT_VER_BEGIN_ID     DMS_DATA_RELA
PK_DMS_DATA_RELA               RELA_ID              DMS_DATA_RELA
RELA_TYPE_CODE_INDEX           RELA_TYPE_CODE       DMS_DATA_RELA



SQL> select index_name,column_name,table_name from dba_ind_columns where table_name ='DMS_OBJ' order by index_name;
INDEX_NAME                     COLUMN_NAME          TABLE_NAME
------------------------------ -------------------- ------------------------------
PK_DMS_OBJ                     OBJ_ID               DMS_OBJ

上面SQL走全表，我找了一些资料说是在IN_VER_BEGIN_ID 列上有索引的话，会走索引，但是实际有索引，还是全表，加hint也还是全表。

我试过物化视图
CREATE MATERIALIZED VIEW mv_dms_ddr
REFRESH force
ON demand
WITH ROWID enable query rewrite AS
SELECT r.OUT_VER_BEGIN_ID, r.IN_DATA_ID, r.IN_VER_BEGIN_ID
  FROM DMS_DATA_RELA r, DMS_OBJ o
WHERE r.DELETE_FLAG = '0'
   AND r.RELA_TYPE_CODE = 'parent'
   AND r.IN_OBJ_CODE != 'o_in'
   AND r.OUT_OBJ_CODE = o.OBJ_CODE
   AND o.DELETE_FLAG = '0'
   AND o.OPEN_STATE = '1'
改写SQL
SELECT OUT_VER_BEGIN_ID dataID
FROM mv_dms_ddr
START WITH IN_DATA_ID in
            (SELECT d.OUT_DATA_ID
               FROM DMS_DATA_RELA d
              where d.OUT_VER_BEGIN_ID = :1
                and d.last_curent_flag = '1')
CONNECT BY PRIOR OUT_VER_BEGIN_ID = IN_VER_BEGIN_ID
（没用fast更新），带入变量试了，第1次慢，后面快，执行时间大概是3秒多了。有提升，但不是很理想，而且表更新也频繁，刷新方式没做on commit。 （我猜测在数据库变动频繁的情况下，是不是这个查询还是会慢，这个想法还没验证）

另外表也收集过统计信息了。

附件中有相关的awr  ,awrsql ,sqlhc。 大神们，这种SQL该怎么优化呢？

awr sqlhc.rar

36.72 KB, 下载次数: 2231
2#
发表于 2013-11-2 18:35:40
表上的列：

SQL> desc DMS_DATA_RELA
Name                           Type          Nullable Default Comments
------------------------------ ------------- -------- ------- --------
RELA_ID                        CHAR(32)                                
IN_DATA_ID                     VARCHAR2(200) Y                        
IN_DATA_NAME                   VARCHAR2(200) Y                        
IN_DATA_SOURCE_ID              VARCHAR2(200) Y                        
IN_DATA_SOURCE_CODE            VARCHAR2(200) Y                        
IN_OBJ_CODE                    VARCHAR2(200) Y                        
IN_VER_BEGIN_ID                VARCHAR2(200) Y                        
IN_VER_BEGIN_DATA_SOURCE_ID    VARCHAR2(200) Y                        
IN_VER_BEGIN_DATA_SOURCE_CODE  VARCHAR2(64)  Y                        
IN_VER_BEGIN_DATA_OBJ_CODE     VARCHAR2(64)  Y                        
OUT_DATA_ID                    VARCHAR2(200) Y                        
OUT_DATA_NAME                  VARCHAR2(200) Y                        
OUT_DATA_SOURCE_ID             VARCHAR2(200) Y                        
OUT_DATA_SOURCE_CODE           VARCHAR2(200) Y                        
OUT_OBJ_CODE                   VARCHAR2(200) Y                        
OUT_VER_BEGIN_ID               VARCHAR2(200) Y                        
OUT_VER_BEGIN_DATA_SOURCE_ID   VARCHAR2(200) Y                        
OUT_VER_BEGIN_DATA_SOURCE_CODE VARCHAR2(64)  Y                        
OUT_VER_BEGIN_DATA_OBJ_CODE    VARCHAR2(64)  Y                        
RELA_TYPE_CODE                 VARCHAR2(200) Y                        
MIDDLE_OBJ_CODE                VARCHAR2(64)  Y                        
LAST_CURENT_FLAG               CHAR(1)       Y                        
CREATE_USER_NAME               VARCHAR2(200) Y                        
CREATE_USER_REAL_NAME          VARCHAR2(200) Y                        
CREATE_TIME                    TIMESTAMP(6)  Y                        
UPDATE_USER_NAME               VARCHAR2(200) Y                        
UPDATE_USER_REAL_NAME          VARCHAR2(200) Y                        
UPDATE_TIME                    TIMESTAMP(6)  Y                        
DELETE_FLAG                    CHAR(1)       Y                        
ORDER_NUM                      NUMBER(10)    Y     

回复 只看该作者 道具 举报

3#
发表于 2013-11-2 18:42:53
有人提到nested loop，我前面测过了，效果不怎么好，现在再把nl的执行计划附上。执行计划是代入变量测的。

关于NESTED LOOPS.txt

10.12 KB, 下载次数: 1719

回复 只看该作者 道具 举报

4#
发表于 2013-11-2 18:45:23
本帖最后由 bamuta 于 2013-11-2 18:50 编辑

另外也有人提到清理索引后，效果会好。      首先，索引有些非技术原因不让清理。另外我弄了1个新环境，没有过多索引，试过不同的列上建不同的索引，效果也是一样的。单就此条SQL来说，过多的索引应该影响不大。

有人问索引状态，也一并附上：
SQL> select table_name, index_name,index_type,status from user_indexes where table_name='DMS_DATA_RELA';
TABLE_NAME                     INDEX_NAME                     INDEX_TYPE                  STATUS
------------------------------ ------------------------------ --------------------------- --------
DMS_DATA_RELA                  OUT_VER_BEGIN_ID_INDEX         NORMAL                      VALID
DMS_DATA_RELA                  IN_DATA_ID_INDEX               NORMAL                      VALID
DMS_DATA_RELA                  IN_DATA_NAME_INDEX             NORMAL                      VALID
DMS_DATA_RELA                  IN_DATA_SOURCE_CODE_INDEX      NORMAL                      VALID
DMS_DATA_RELA                  IN_DATA_SOURCE_ID_INDEX        NORMAL                      VALID
DMS_DATA_RELA                  IN_OBJ_CODE_INDEX              NORMAL                      VALID
DMS_DATA_RELA                  IN_VER_BEGIN_ID_INDEX          NORMAL                      VALID
DMS_DATA_RELA                  OUT_DATA_NAME_INDEX            NORMAL                      VALID
DMS_DATA_RELA                  OUT_DATA_SOURCE_ID_INDEX       NORMAL                      VALID
DMS_DATA_RELA                  OUT_OBJ_CODE_INDEX             NORMAL                      VALID
DMS_DATA_RELA                  RELA_TYPE_CODE_INDEX           NORMAL                      VALID
DMS_DATA_RELA                  DELETE_FLAG_INDEX              NORMAL                      VALID
DMS_DATA_RELA                  LAST_CURENT_FLAG_INDEX         NORMAL                      VALID
DMS_DATA_RELA                  CREATE_TIME_INDEX              FUNCTION-BASED NORMAL       VALID
DMS_DATA_RELA                  OUT_DATA_ID_INDEX              NORMAL                      VALID
DMS_DATA_RELA                  PK_DMS_DATA_RELA               NORMAL                      VALID
16 rows selected

回复 只看该作者 道具 举报

5#
发表于 2013-11-2 19:14:24
我认为 2个HASH JOIN用的没错，因为 是返回一个较大的行源

      |*  5 |      HASH JOIN                 |                        |    717K|   111M|  8045   (1)| 00:01:37 |  1035K|  1035K|  2576/0/0|
                      |   6 |       TABLE ACCESS FULL        | DMS_OBJ                |     41 |   656 |     3   (0)| 00:00:01 |       |       |          |
                      |   7 |       TABLE ACCESS FULL        | DMS_DATA_RELA          |    717K|   100M|  8037   (1)| 00:01:37 |       |       |          |



主要在于逻辑读较高 达到1663816



action plan:

set linesize 200 pagesize 2000
alter session set STATISTICS_LEVEL = ALL;
执行你的SQL
select * from table(dbms_xplan.DISPLAY_CURSOR(null, null, 'ALLSTATS LAST'));

如果不会收集allstats 请参考http://t.askmaclean.com/thread-3237-1-1.html

回复 只看该作者 道具 举报

6#
发表于 2013-11-2 19:33:51
本帖最后由 bamuta 于 2013-11-2 19:51 编辑
Maclean Liu(刘相兵 发表于 2013-11-2 19:14
我认为 2个HASH JOIN用的没错，因为 是返回一个较大的行源

      |*  5 |      HASH JOIN                 ...


-----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name              | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
-----------------------------------------------------------------------------------------------------------------------------------------
|*  1 |  FILTER                        |                   |      1 |        |      0 |00:02:23.58 |   42M|          |       |          |
|*  2 |   CONNECT BY WITH FILTERING    |                   |      1 |        |      0 |00:02:23.58 |   42M|     1024 |  1024 |          |
|*  3 |    FILTER                      |                   |      1 |        |      0 |00:02:23.58 |   42M|          |       |          |
|   4 |     COUNT                      |                   |      1 |        |    887K|00:00:01.78 |   45763 |       |       |          |
|*  5 |      HASH JOIN                 |                   |      1 |    829K|    887K|00:00:01.30 |   45763 |  1035K|  1035K| 1192K (0)|
|   6 |       TABLE ACCESS FULL        | DMS_OBJ           |      1 |     41 |     41 |00:00:00.01 |    7 |          |       |          |
|   7 |       TABLE ACCESS FULL        | DMS_DATA_RELA     |      1 |    829K|    887K|00:00:00.11 |   45756 |       |       |          |
|*  8 |     TABLE ACCESS BY INDEX ROWID| DMS_DATA_RELA     |    413K|      1 |      0 |00:02:20.46 |   42M|          |       |          |
|*  9 |      INDEX RANGE SCAN          | OUT_DATA_ID_INDEX |    413K|      1 |     59M|00:00:03.02 | 1835K|          |       |          |
|* 10 |    HASH JOIN                   |                   |      0 |        |      0 |00:00:00.01 |    0 |      157M|  7794K|          |
|  11 |     CONNECT BY PUMP            |                   |      0 |        |      0 |00:00:00.01 |    0 |          |       |          |
|  12 |     COUNT                      |                   |      0 |        |      0 |00:00:00.01 |    0 |          |       |          |
|* 13 |      HASH JOIN                 |                   |      0 |    829K|      0 |00:00:00.01 |    0 |      963K|   963K|          |
|  14 |       TABLE ACCESS FULL        | DMS_OBJ           |      0 |     41 |      0 |00:00:00.01 |    0 |          |       |          |
|  15 |       TABLE ACCESS FULL        | DMS_DATA_RELA     |      0 |    829K|      0 |00:00:00.01 |    0 |          |       |          |
-----------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(("R"."DELETE_FLAG"='0' AND "R"."RELA_TYPE_CODE"='parent' AND "O"."DELETE_FLAG"='0' AND "O"."OPEN_STATE"='1' AND
              "R"."IN_OBJ_CODE"<>'o_in'))
   2 - access("R"."IN_VER_BEGIN_ID"=PRIOR NULL)
   3 - filter( IS NOT NULL)
   5 - access("R"."OUT_OBJ_CODE"="O"."OBJ_CODE")
   8 - filter(("D"."OUT_VER_BEGIN_ID"='20130131036703_syspro_o_wbs' AND "D"."LAST_CURENT_FLAG"='1'))
   9 - access("D"."OUT_DATA_ID"=:B1)
  10 - access("R"."IN_VER_BEGIN_ID"=PRIOR NULL)
  13 - access("R"."OUT_OBJ_CODE"="O"."OBJ_CODE")

执行过程详见附件，附件中对齐的更清楚一些

执行计划allstats.txt

4.83 KB, 下载次数: 1673

回复 只看该作者 道具 举报

7#
发表于 2013-11-2 20:10:43
  1. |*  8 |     TABLE ACCESS BY INDEX ROWID| DMS_DATA_RELA     |    413K|      1 |      0 |00:02:20.46 |   42M|          |       |          |
  2. |*  9 |      INDEX RANGE SCAN          | OUT_DATA_ID_INDEX |    413K|      1 |     59M|00:00:03.02 | 1835K|          |       |          |

  4.    8 - filter(("D"."OUT_VER_BEGIN_ID"='20130131036703_syspro_o_wbs' AND "D"."LAST_CURENT_FLAG"='1'))
  5.    9 - access("D"."OUT_DATA_ID"=:B1)
复制代码
9 - access("D"."OUT_DATA_ID"=:B1)即

==>这个谓词让步骤9 认为之返回1行数据，所以 8-9TABLE ACCESS BY INDEX ROWID+INDEX RANGE SCAN消耗了绝大多数 buffer 42M和 时间02:20.46

总的 buffer get是 42M  ，耗时是2:23.58



试试
  1. SELECT r.OUT_VER_BEGIN_ID dataID
  2. FROM DMS_DATA_RELA r,
  3.   DMS_OBJ o
  4. WHERE r.DELETE_FLAG        = '0'
  5. AND r.RELA_TYPE_CODE       = 'parent'
  6. AND r.OUT_OBJ_CODE         = o.OBJ_CODE
  7. AND o.DELETE_FLAG          = '0'
  8. AND o.OPEN_STATE           = '1'
  9. AND r.IN_OBJ_CODE         != 'o_in'
  10.   START WITH r.IN_DATA_ID IN
  11.   (SELECT /*+ unnest FULL(d) */ d.OUT_DATA_ID
  12.   FROM DMS_DATA_RELA d
  13.   WHERE d.OUT_VER_BEGIN_ID=:1
  14.   AND d.last_curent_flag  ='1'
  15.   )
  16.   CONNECT BY r.IN_VER_BEGIN_ID = PRIOR r.OUT_VER_BEGIN_ID
复制代码

回复 只看该作者 道具 举报

8#
发表于 2013-11-4 10:14:09
Maclean Liu(刘相兵 发表于 2013-11-2 20:10
9 - access("D"."OUT_DATA_ID"=:B1)即

==>这个谓词让步骤9 认为之返回1行数据，所以 8-9TABLE ACCESS BY I ...

按老大的方法试了，大概50分钟过去了，还没有返回结果。目前没获得实践执行过的执行计划，所以用explain plan for做了1 个。详见附件。

执行计划explain plan unnest.rar

1.11 KB, 下载次数: 2263

回复 只看该作者 道具 举报

9#
发表于 2013-11-4 10:19:47
首先获得该SQL的SQL_ID

之后

set linesize 200 pagesize 1400
@?/rdbms/admin/sqltrpt   


<== 输入SQL_ID ，把完整的输出发上来

回复 只看该作者 道具 举报

10#
发表于 2013-11-4 10:26:38
Maclean Liu(刘相兵 发表于 2013-11-4 10:19
首先获得该SQL的SQL_ID

之后

执行结果在附件中

sqltrpt_result.zip

2.81 KB, 下载次数: 2121

回复 只看该作者 道具 举报

11#
发表于 2013-11-4 13:03:50
1、你输入的语句 带了我给的HINT ，不要用带 HINT的语句

回复 只看该作者 道具 举报

12#
发表于 2013-11-4 15:01:50
Maclean Liu(刘相兵 发表于 2013-11-4 13:03
1、你输入的语句 带了我给的HINT ，不要用带 HINT的语句

前面我对你的意思误解了，现在给出无hint的结果，分别用了AWR中的SQL_ID(有变量） 和将变量具体代入了值执行的SQL_ID，但最后都是：
There are no recommendations to improve the statement.

详见附件。

sqltrpt_result_nohint.rar

1.86 KB, 下载次数: 2167

回复 只看该作者 道具 举报

13#
发表于 2013-11-5 23:18:28
改SQL吧，你的业务逻辑真的需要这么大数据量的connect by查询？

回复 只看该作者 道具 举报

14#
发表于 2013-11-6 09:13:06
Maclean Liu(刘相兵 发表于 2013-11-5 23:18
改SQL吧，你的业务逻辑真的需要这么大数据量的connect by查询？

至于动业务逻辑有一定困难，就整理一下过多的索引都是困难重重，何况动业务。
谢谢刘大，一直在帮我处理。处理问题的过程所学习到的东西，比优化这个SQL本身有价值。

回复 只看该作者 道具 举报

15#
发表于 2013-11-6 17:26:11
Maclean Liu(刘相兵 发表于 2013-11-5 23:18
改SQL吧，你的业务逻辑真的需要这么大数据量的connect by查询？


我把这个SQL先做了connect by 循环，然后再与另1个表做了连接，效果超好，代入5、6个不同的值人肉对比试了下，结果正确。  但5、6个不能代表全部，所以大家瞅瞅和原来相比有没有逻辑错误。

这是修改后的SQL：

select dataID
  from (SELECT r.OUT_VER_BEGIN_ID dataID, r.out_obj_code
          FROM DMS_DATA_RELA r
         WHERE r.DELETE_FLAG = '0'
           AND r.RELA_TYPE_CODE = 'parent'
           AND r.IN_OBJ_CODE != 'o_in'
         START WITH r.IN_DATA_ID in
                    (SELECT d.OUT_DATA_ID
                       FROM DMS_DATA_RELA d
                      where d.OUT_VER_BEGIN_ID =:1
                        and d.last_curent_flag = '1')
        CONNECT BY r.IN_VER_BEGIN_ID = PRIOR r.OUT_VER_BEGIN_ID) e,
       DMS_OBJ o
where e.OUT_OBJ_CODE = o.OBJ_CODE
   AND o.DELETE_FLAG = '0'
   AND o.OPEN_STATE = '1'
执行计划：
--------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name                   | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
--------------------------------------------------------------------------------------------------------------------------------------------------
|*  1 |  HASH JOIN                         |                        |      1 |      3 |      0 |00:00:00.01 |       3 |   720K|   720K|  212K (0)|
|   2 |   VIEW                             |                        |      1 |      3 |      0 |00:00:00.01 |       3 |       |       |          |
|*  3 |    FILTER                          |                        |      1 |        |      0 |00:00:00.01 |       3 |       |       |          |
|*  4 |     CONNECT BY WITH FILTERING      |                        |      1 |        |      0 |00:00:00.01 |       3 |  1024 |  1024 |          |
|   5 |      TABLE ACCESS BY INDEX ROWID   | DMS_DATA_RELA          |      1 |        |      0 |00:00:00.01 |       3 |       |       |          |
|   6 |       NESTED LOOPS                 |                        |      1 |    862 |      0 |00:00:00.01 |       3 |       |       |          |
|   7 |        SORT UNIQUE                 |                        |      1 |      1 |      0 |00:00:00.01 |       3 |  1024 |  1024 |          |
|*  8 |         TABLE ACCESS BY INDEX ROWID| DMS_DATA_RELA          |      1 |      1 |      0 |00:00:00.01 |       3 |       |       |          |
|*  9 |          INDEX RANGE SCAN          | OUT_VER_BEGIN_ID_INDEX |      1 |      1 |      0 |00:00:00.01 |       3 |       |       |          |
|* 10 |        INDEX RANGE SCAN            | IN_DATA_ID_INDEX       |      0 |    819 |      0 |00:00:00.01 |       0 |       |       |          |
|  11 |      NESTED LOOPS                  |                        |      0 |        |      0 |00:00:00.01 |       0 |       |       |          |
|  12 |       CONNECT BY PUMP              |                        |      0 |        |      0 |00:00:00.01 |       0 |       |       |          |
|  13 |       TABLE ACCESS BY INDEX ROWID  | DMS_DATA_RELA          |      0 |      3 |      0 |00:00:00.01 |       0 |       |       |          |
|* 14 |        INDEX RANGE SCAN            | IN_VER_BEGIN_ID_INDEX  |      0 |      3 |      0 |00:00:00.01 |       0 |       |       |          |
|* 15 |   TABLE ACCESS FULL                | DMS_OBJ                |      0 |     40 |      0 |00:00:00.01 |       0 |       |       |          |
--------------------------------------------------------------------------------------------------------------------------------------------------

附件中的执行计划易读些。

我从李华值 《海量数据库解决方案》3.2.5 找到相关例子，并有这样的说明   ： ”如果查询条件中的列位于同一表中时，并没有必要优先执行表连接“

先循环后连接.txt

5.89 KB, 下载次数: 1628
已有 1 人评分威望 理由
Maclean Liu(刘相兵 + 5

总评分: 威望 + 5   查看全部评分

回复 只看该作者 道具 举报

16#
发表于 2013-11-6 18:41:04
bamuta 发表于 2013-11-6 17:26
我把这个SQL先做了connect by 循环，然后再与另1个表做了连接，效果超好，代入5、6个不同的值人肉对比试 ...

good!

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-5-19 17:29 , Processed in 0.060270 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569