잡동사니 보물섬

 인덱스 기본 구조 

  - 리프 노드상의 인덱스 레코드와 테이블 레코드 간에는 1:1 관계

  - 리프 노드상의 키 값과 테이블 레코드 키 값은 서로 일치 

  - 브랜치 노드상의 레코드 개수는 하위 레벨 블록 개수와 일치 

  - 블랜치 노드상의 키 값은 하위 노드가 갖는 값의 범위를 의미  

 rowid 포맷 

  - 제한된 포맷 ( 6 byte) 

      ● 파티션 되지 않은 일반 테이블에 생성한 인덱스 

      ● 파티션된 테이블에 생성한 로컬 파티션 인덱스 

    데이터파일 번호 + 블록 번호 + 로우 번호 

  - 확장된 포맷 (10 byte) 

      ● 파티션 테이블에 생성한 글로벌 파티션 인덱스 

      ● 파티션 테이블에 생성한 비파티션 인덱스 

    데이터 오브젝트 번호 + 데이터파일 번호 + 블록 번호 + 로우 번호 

http://cafe.naver.com/dbstudydapsqlp/2220

 -- 이곳에서 문제 참조 함 

내 답안) 

select /*+ ordered use_nl(p4) rowid(p4) */ p4.prod_nm, p.prod_id, p3.order_qty 

 from ( select /*+ no_merge ordered use_hash(o) */ p2.rid, o.order_qty 

         from ( select /*+ ordered use_nl(p1) */ p1.m_code, p1.prod_id 

                  from , t_manuf m, t_product p1 

                 where p1.m_code = m.m_code 

                  and m.m_code between 'M00001' and 'M00100' ) p2 

               , order_qty o

          where p2.prod_id = o.prod_id 

           and o.order_dt = '20160412'

           and o.order_qty > 9000 

        ) p3 

        , t_product p4 

 where p3.rid = p4.rowid 

;

-- 참조한 곳의 답안과 약간 다른데 난 실행계획의 hash 까지 좀 표현하려고 in-line view를 한번 더 씀 

-- 그런데 처음에 답을 보지 않고 답안을 작성했을 때 no_merge 힌트를 사용하지는 않았음 

    이 부분은 문제의 소지가 좀 있음 view merging 은 10g 부터 비용 기반 변환이라서 

    힌트를 사용하지 않으면 어떻게 될지 잘 모름 그런데 만약 바깥에 in-line view가 view merging 되면 

    위의 쿼리는 튜닝 되지 않았을 것임 

    그래서 no_merge 힌트는 써주는 것이 맞았을 것 같음 

http://cafe.naver.com/prodba/47529

-- 참조 질문 

select status 

       , min(time_line) from_time 

       , max(time_line) to_time 

       , max(time_line) - min(time_line) cnt 

  from ( select time_line 

               , status 

               , time_line - rownumber() over (partition by status order by time_line) grp 

          from tb 

        ) 

  group by status, grp 

  order by from_time 

;

--- 여기서 rownum 은 time_line 에 간격을 찾기 위해서 사용 한 거구나