'hint'에 해당되는 글 2건

  1. 2010.07.02 [Oracle] Timestamp의 Index Hint 특성 (4)
  2. 2008.12.04 [Oracle] Hint 사용 (1)
Database2010. 7. 2. 14:26
Oracle Table에 Timestamp Column에 Index 설정 후 해당 인덱스를 사용하여 Ordering 결과를 얻기 위해 Hint 를 주었을 경우 아무 조건절이 없으면 Order가 안되는 신기한 상황 발생.. ㅡ_ㅡ (기술 문서를 안 읽어봐서 정확한 이유는 확인하지 못했으나 당연히 될줄 알았던 것이 안되니 당황)

테이블 스키마와 인덱스 스키마는 아래와 같은 상황





일단 테스트

        SELECT 
           /*+ INDEX_DESC(T_MORI I_MORI_START_TIME) */
           MORI_NO, TITLE, TITLE_IMG, 
           MORI_TYPE, START_TIME, END_TIME, 
           SUBTITLE, SUBTITLE_IMG, MIN_CONTRACTOR, 
           MAX_CONTRACTOR, LIST_PRICE, DISCOUNT_PRICE, 
           DISCOUNT_RATE, CREATE_TIME, MODIFY_TIME, 
           AUTHOR_NO, DEPARTMENT_NO, SHORT_EXPLAIN
        FROM T_MORI
<Query 1>

위와 같이 Index Hint를 줬을 경우 START_TIME 을 기준으로 최근 시간의 결과값이 처음 나오는 결과를 기대했으나 결과는...


Index가 잘못되었나 싶어 Index Rebuild 실행도 해봤으나 결과는 동일... 다른 Index도 문제인가 싶어 Title Index를 이용한 Ordering 결과 확인

SELECT 
           /*+ INDEX_DESC(T_MORI I_MORI_TITLE) */
           MORI_NO, TITLE, TITLE_IMG, 
           MORI_TYPE, START_TIME, END_TIME, 
           SUBTITLE, SUBTITLE_IMG, MIN_CONTRACTOR, 
           MAX_CONTRACTOR, LIST_PRICE, DISCOUNT_PRICE, 
           DISCOUNT_RATE, CREATE_TIME, MODIFY_TIME, 
           AUTHOR_NO, DEPARTMENT_NO, SHORT_EXPLAIN
        FROM T_MORI
<Query 2>


기대한 결과가 정확히 나왔다...


Index가 제대로 안타는 것 같은 생각이 들어 Plan 확인.

<Query1 의 Plan 결과>

<Query2 의 Plan 결과>

이럴수가.. ㅡ_ㅡ Timestamp 컬럼에 Index를 건 것은 Hint 까지 줬음에도 불구하고 Index를 타지 않고 Full Scan을 한다. 반면 varchar2 컬럼 Index를 이용한 Select의 경우 Index를 정확히 타서 descending 까지 거쳐 결과를 추출해 내었다.. ㅡ_ㅡ

하지만 꿋꿋하게 Timestamp 값을 기준으로 결과를 얻어내기 위해 다시 테스트 돌입.

해당 컬럼에 비교값을 넣으면 어찌되었든 값을 비교해야 하므로 Index를 타지 않을까 하는 생각으로 해당 컬럼에 대한 조건값을 넣어봤음.

        SELECT 
           /*+ INDEX_DESC(T_MORI I_MORI_START_TIME) */
           MORI_NO, TITLE, TITLE_IMG, 
           MORI_TYPE, START_TIME, END_TIME, 
           SUBTITLE, SUBTITLE_IMG, MIN_CONTRACTOR, 
           MAX_CONTRACTOR, LIST_PRICE, DISCOUNT_PRICE, 
           DISCOUNT_RATE, CREATE_TIME, MODIFY_TIME, 
           AUTHOR_NO, DEPARTMENT_NO, SHORT_EXPLAIN
        FROM T_MORI
        WHERE START_TIME < '2010-10-01';






오홍~ 나이스.. 결과가 정확히 추출되었당. 어찌되었건 테이블 전체 Select 하는 상황이 아니므로 조건절을 주어 무조건 index를 한번 Access 하도록 하여 빠른 결과를 얻을 수 있었음.

결론! Timestamp Column 속성의 index 일 경우 조건절을 주어야 index를 타고 원하는 결과를 얻을 수 있다.
이 장소를 Daum지도에서 확인해보세요.
서울특별시 송파구 석촌동 | ITH
도움말 Daum 지도
Posted by 양군이당

댓글을 달아 주세요

  1. 난 그냥 제출하신 이메일 주소로 날 구독하시기 바랍니다. 나는 미래의 게시물에 대한 알림을 수신하고 싶습니다. 좋은 블로그와 좋은 게시합니다.

    2011.10.10 12:30 [ ADDR : EDIT/ DEL : REPLY ]
  2. 이것이 내가 이곳을 방문 처음이다. 나는 특히 토론, 블로그에 많은 흥미로운 물건을 발견했습니다. 기사에 대한 의견의 t에서, 제가 여기있는 모든 즐거움을 가진 유일한 사람이 아니 그런 것 같아요! 훌륭한 작품을 계속. <h1><a href="http://kadalmesir.blogspot.com/2012/08/sepeda-motor-bebek-injeksi-kencang-dan.html">Sepeda Motor Bebek Injeksi Kencang dan Irit Jupiter Z1</a></h1>

    2012.09.11 12:33 [ ADDR : EDIT/ DEL : REPLY ]
  3. 이 게시물에이 정보를 다시 보니 반갑 네요, 내가 같은 찾고 있지만 적절한 자원은 거기에 없었어요, 고맙습니다 이제 나는 내 연구를 찾고 있던 링크를 거십시오

    2012.09.11 12:33 [ ADDR : EDIT/ DEL : REPLY ]
  4. 이 논문은 내가 더 올바른 데이터를 얻기 위해 요금을 지불 할 필요가 많은 시간을 모르면하지 않으면 ME를 용이하게합니다.

    2012.10.12 03:44 [ ADDR : EDIT/ DEL : REPLY ]

Database2008. 12. 4. 08:24
출처 살아가는 이야기 | 서기
원문 http://blog.naver.com/tinylass/130009326659

<<Optimization Approaches and Goals - Optimization  접근과 목적>>
  

/*+ ALL_ROWS */
 
  ALL_ROWS는 Full Table Scan을 선호하며 CBO(Cost Based Optimization)는 default로
  ALL_ROWS를 선택 합니다.         
        
   SQL>SELECT /*+ ALL_ROWS */  ename, hiredate FROM emp  WHERE ename like '%%%'
       
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: ALL_ROWS (Cost=1 Card=5 Bytes=80)
   1    0   TABLE ACCESS (FULL) OF 'EMP' (Cost=1 Card=5 Bytes=80)
 
 
 
/*+ CHOOSE */

  Hint Level의 CHOOSE는 RBO(Rule Based Optimization)인지 CBO(Cost Based Optimization)
  인지를 선택 합니다.

   만약 주어진 table의 통계 정보가 없다면 Rule Based 접근 방식을 사용 합니다.
 
 
 
/*+ FIRST_ROWS */

   Full Table Scan보다는 index scan을 선호하며
   Interactive Application인 경우 best response time을 제공 합니다.

   또한 sort merge join보다는 nested loop join을 선호 합니다.
 
   SQL>SELECT /*+ FIRST_ROWS */  ename FROM emp WHERE empno=7876
 
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=1 Card=1 Bytes=20)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (Cost=1 Card=1 Bytes=20)
   2    1     INDEX (RANGE SCAN) OF 'PK_EMP' (UNIQUE) (Cost=1 Card=1)
 
 
 
/*+ RULE */

   Rule Based 접근 방식을 사용하도록 지정 합니다.



<<Access Methods - 접근 방법>>
 
 
/*+ CLUSTER(table_name) */

  Cluster Scan을 선택하도록 지정한다. 따라서 clustered object들에만 적용 됩니다.
 

 
/*+ FULL(table_name) */

  Table을 Full Scan하길 원할 때 사용 합니다.

 

/*+ HASH(table) */

  Hash scan을 선택하도록 지정한다.
  이 hint는 HASHKEYS parameter를 가지고 만들어진 cluster내에 저장된 table에만 적용이 됩니다.
 
 

/*+ INDEX(table_name index_name) */

  지정된 index를 강제적으로 쓰게끔 지정 합니다.
 
 
 
/*+ INDEX_ASC(table_name index_name) */

  지정된 index를 오름차순으로 쓰게끔 지정 합니다.
  Default로 Index Scan은 오름차순 입니다
 

 
/*+ INDEX_DESC(table_name index_name) */
 
  지정된 index를 내림차순으로 쓰게끔 지정 합니다.
 
 
   SQL>SELECT /*+ index_desc(emp pk_emp) */  empno
           FROM   emp
           WHERE  rownum = 1 ;
        
    위 문장은 제일 큰 것 하나만 조회되므로, max function의 기능을 대신할 수 있습니다.    



 /*+ INDEX_FFS(table index) */

  Full table scan보다 빠른 Full index scan을 유도 합니다.
 
 

/*+ ROWID(table) */

  Rowid로 Table Scan을 하도록 지정 합니다.



<<Join Orders>>


/*+ ORDERED */

  From절에 기술된 테이블 순서대로 join이 일어나도록 유도 합니다.

 



<<Join Operations>>
 
 
/*+ USE_HASH (table_name) */

  각 테이블간 HASH JOIN이 일어나도록 유도 합니다.
 
 

/*+ USE_MERGE (table_name) */

  지정된 테이블들의 조인이 SORT-MERGE형식으로 일어나도록 유도 합니다.



<<Parallel Execution>>
 
 
/*+ NOPARALLEL(table_name) */
 
  NOPARALLEL hint를 사용하면, parallel query option을 사용하지 않도록 할 수 있다.
 
  SQL>SELECT /*+ NOPARALLEL */ *  FROM emp;
 
 
 
/*+ PARALLEL(table_name, degree) */
 
  PARALLEL hint를 사용하면 query에 포함된 table의 degree를 설정할 수 있습니다.
 
  예를 들어, 다음과 같이 hint를 적어 degree 4로 parallel query option을  실행하도록 할 수 있습니다.
  이 때 parallel이란 글자와 괄호( '(' )사이에 blank를 넣지 않도록 주의해야 합니다.
  
  SQL>SELECT /*+ PARALLEL(emp, 4) */   * FROM emp;
 
 
 
* DEGREE의 의미 및 결정
 
Parallel Query에서 degree란 하나의 operation 수행에 대한 server process의 개수 입니다.
이러한 degree 결정에 영향을 주는 요인들에는 다음과 같은 것들이 있습니다.
 
(1)  system의 CPU 갯수
(2)  system의 maximum process 갯수
(3)  table이 striping되어 있는 경우, 그 table이 걸쳐있는 disk의 갯수
(4)  data의 위치 (즉, memory에 cache되어 있는지, disk에 있는지)
(5)  query의 형태 (예를 들어 sorts 혹은 full table scan)
 
한 사용자만이 parallel query를 사용하는 경우, sorting이 많이 필요한
작업과 같은 CPU-bound 작업의 경우는 CPU 갯수의 1 ~ 2배의 degree가 적당하며,
sorting보다는 table scan과 같은 I/O bound 작업의 경우는 disk drive 갯수의 1 ~ 2배가 적당합니다.
 
동시에 수행되는 parallel query가 많은 경우에는 위의 각 사용자의 degree를
줄이거나 동시에 사용하는 사용자 수를 줄여야 합니다.

Posted by 양군이당
TAG hint, oracle

댓글을 달아 주세요

  1. Sid.K

    깔끔한 요약이네요. 감사합니다~~

    2009.01.15 12:56 [ ADDR : EDIT/ DEL : REPLY ]