database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
ㆍOracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Oracle Q&A 41212 게시물 읽기
No. 41212
plan 에 bind 변수 사용 시 성능 문의
작성자
굽은나무
작성일
2016-08-17 10:38ⓒ
2016-08-17 11:08ⓜ
조회수
6,610

토드에서 같은 쿼리를 plan 확인 시

1번 쿼리 처럼 where에 값을 직접 설정하고 PLAN 을 한 경우와

2번처럼 변수를 바인딩하고 PLAN 계획은 같은데 COST 가 다르게 나옵니다.

왜 이런 경우가 발생하는지와 제가 이해를 못한 이유를 설명 좀 부탁 드립니다.

1번 / 2번 실행 시 같은 값으로 쿼리를 실행하면 쿼리 시간도 상당한 차이를 보입니다.

 

SETTL_TXN 은 PARTITION 테이블이며 SETTL_TXN_IDX01 은 Global Index 로 ID, REG_DT  컬럼으로 되어 있음

2번 쿼리는 INDEX 힌트를 별도로 주지 않더라도 똑같은 실행 PLAN 으로 실행됨.

 

 

1번 쿼리


SELECT /*+ INDEX(SETTL_TXN SETTL_TXN_IDX01) */

                SETTL_NO

 

FROM SETTL_TXN

WHERE ID = 'honggd'

  AND REG_DT >= TO_DATE('201608', 'YYYYMM')

  AND REG_DT < TO_DATE('201609', 'YYYYMM')

GROUP BY SETTL_NO
 

1번 PLAN

 

 

SELECT STATEMENT  ALL_ROWSCost: 49,501  Bytes: 170  Cardinality: 1  

4 HASH GROUP BY  Cost: 49,501  Bytes: 170  Cardinality: 1  

3 FILTER  

2 TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED TABLE SETTL_TXN Cost: 49,500  Bytes: 170  Cardinality: 1  Partition #: 3  Partition access computed by row location

1 INDEX RANGE SCAN INDEX SETTL_TXN_IDX01 Cost: 210  Cardinality: 31  

 

 

2번 쿼리

SELECT /*+ INDEX(SETTL_TXN SETTL_TXN_IDX01) */

                SETTL_NO

FROM SETTL_TXN

WHERE ID = :ID

   AND REG_DT >= TO_DATE(:BEGIN_REG_DT, 'YYYYMM')

  AND REG_DT < TO_DATE(:END_REG_DT, 'YYYYMM')

GROUP BY SETTL_NO

 

:ID = 'honggd'

:BEGIN_REG_DT = '201608'

:END_REG_DT = '201609'

 

2번 PLAN

 

SELECT STATEMENT  ALL_ROWSCost: 6  Bytes: 130  Cardinality: 1  

4 HASH GROUP BY  Cost: 6  Bytes: 130  Cardinality: 1  

3 FILTER  

2 TABLE ACCESS BY GLOBAL INDEX ROWID BATCHED TABLE SETTL_TXN Cost: 5  Bytes: 130  Cardinality: 1  Partition #: 3  Partition access computed by row location

1 INDEX RANGE SCAN INDEX SETTL_TXN_IDX01 Cost: 3  Cardinality: 1  

 

 

 

이 글에 대한 댓글이 총 4건 있습니다.

명시적으로 값이 들어오는 경우에는 데이터 분포도에 따라 실행계획을 만들 거구요.

bind 변수로 들어오게 되면 어떤 값이 들어올지 모르게 되므로 바인드 변수에 최초에 들어왔던 값을 기준으로 실행계획이 만들어지겠죠.

경우에 따라 조인 방식이 아예 달라지기도 하겠구요.

이 경우에는 실행계획 자체는 달라지지 않았지만

reg_dt의 범위가 지정되었으므로 cost값 계산에 영향을 미친 거겠죠.

손재균(iikii)님이 2016-08-17 10:51에 작성한 댓글입니다.
이 댓글은 2016-08-17 10:54에 마지막으로 수정되었습니다.

답변 감사합니다.

변수 값은 동일한데 실제 쿼리 시간은 상당한 차이를 보입니다.

똑같은 RBO로 처리해도 달라지는게 맞는건가요?

굽은나무님이 2016-08-17 11:13에 작성한 댓글입니다.
이 댓글은 2016-08-17 11:13에 마지막으로 수정되었습니다. Edit

실측 시간이 차이가 났다면

 

올려주신 실행 계획이 예상 실행 계획인 경우

-> trace를 통해서 실제 수행된 실행 계획을 보세요.

 

실측 실행계획인 동일하다면

 

reg_dt 컬럼은 날짜형인 게 맞는지 확인해보시고..

 

캐시에 올라간 데이터 때문에 두번째 실행에서 빨라질 수 있으니

그것 때문이 아닌지 확인해보시구요.

손재균(iikii)님이 2016-08-17 12:30에 작성한 댓글입니다.

네 답변 감사합니다.

 

굽은나무님이 2016-08-17 23:04에 작성한 댓글입니다. Edit
[Top]
No.
제목
작성자
작성일
조회
41215오라클 트리거 관련
초보디비
2016-08-19
5872
41214오라클 프로시저 구현 문의
게릴라
2016-08-19
6088
41213[문의] Hive Collect_list 함수의 Oracle 구현
Aslube
2016-08-17
7261
41212plan 에 bind 변수 사용 시 성능 문의 [4]
굽은나무
2016-08-17
6610
41211100만건의 데이터 avg [1]
질문
2016-08-11
6447
41210package 안의 프로시져 호출 에러 문의
skystrider
2016-08-08
6376
41209오라클 디비 백업 관련 문의
이성근
2016-08-06
6289
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.070초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다