정미나닷컴

NL JOIN- Random access 발생량에 의해 성능이 좌우 -- 고객의 총 수는 10만 명, 납입 방법은 세가지-- 두 테이블 모두 JOIN 컬럼에 인덱스를 갖고 있다고 가정 - 필터 조건이 없는 경우SELECT /*+ use_nl (a b) */ A.납입방법, B.* FROM 납입방법 A, 고객 BWHERE B.납입방법코드 = A.납입방법코드; - 드라이빙 테이블 : 고객 T /*+ leading(b) use_nl(a) */▶ 10만번 + 10만번 = 총 20만번의 Random access - 드라이빙 테이블 : 납입 T /*+ leading(a) use_nl(b) */▶ 3번 + 10만번 = 총 10만 3번의 Random access * 다른 필터 조건이 없는 상황에서는 작은 쪽(=1쪽) 집..

인덱스 설계 전략- 조건절에 항상 사용되거나, 자주 등장하는 컬럼들을 선정- '=' 조건으로 자주 조회되는 컬럼들을 앞쪽에 위치 -- 총 고객수 100만 명, 상품은 10만 개, 거래일자의 검색범위는 유동적인 테이블 [검색조건 1] WHERE 고객번호 = '0000001' AND 거래일자 BETWEEN '20150101' AND '20171001'; [검색조건 2] WHERE 상품번호 = '1' AND 거래일자 BETWEEN '20150101' AND '20171001'; [검색조건 3] WHERE 고객번호 = '0000001' AND 상품번호 = '1' AND 거래일자 BETWEEN '20150101' AND '20171001'; [검색조건 4] WHERE 거래일자 BETWEEN '20150101' A..

Bitmap Index (비트맵 인덱스) - Key 값에 중복이 없고, Key 값 별로 하나의 비트맵 레코드를 가짐 - 비트맵 상의 각 비트가 하나의 테이블 레코드와 매핑 row#0( 8001) flag: ------, lock: 0, len=35 col 0; len 2; (4): 42 4c 55 45 → 키 값 : BLUE col 1; len 6; (6): 01 00 9f 4c 00 00 → 시작 RowID col 2; len 6; (6): 01 01 a4 03 01 47 → 종료 RowID col 3; len 15; (15): 00 c1 ae bb fa 02 c1 a1 10 c1 94 19 c2 dc 07 → 비트맵- 시작 RowID와 종료 RowID만 갖고 있다가 테이블 액세스가 필요할 때면 각 비..

HWM (High Water Mark)- 세그먼트 영역에서 사용된 적이 있는 Block 까지의 표시점 사용 블록 사용 블록 사용 블록 * 빨간선으로 표시된 부분이 HWM - HWM는 5 Block 단위로 증가- 수동으로 축소하지 않는 이상 증가만 함- 모든 세그먼트에 하나씩 존재- HWM 이전 Block에만 데이터 저장 가능- Full Scan 시 HWM 이전의 모든 Block Access (HWM 아래로 Free Block이 많을 시 효율 저하)- Truncate 명령어로 HWM Reset 가능 (Delete는 X)- Insert 할 데이터가 HWM를 넘어가는 경우 HWM를 5 Block 뒤로 이동시킨 다음 Insert (그래도 모자랄 경우엔 새로운 익스텐트 할당)

* 오라클의 B*Tree Index는 Unbalanced 상태에 놓일 일은 없지만 Index Fragmentation에 의한 Index Skew 또는 Sparse 현상으로 인덱스 스캔 효율이 저하될 수 있음 ☑ [Oracle] 오라클 인덱스 구조 - B*Tree Index 자세히 보기 Index Skew - 인덱스 엔트리가 왼쪽 또는 오른쪽에 치우치는 현상DELETE FROM T WHERE NO

인덱스 스캔 효율 - Sequential access의 선택도 향상을 위한 방법 ☑ [Oracle] 오라클 인덱스 스캔 방식 보러가기 [인] 인덱스 매칭도 - Sequential access의 효율은 선택도에 의해 결정 (같은 결과 건수를 내는데 얼마나 적은 레코드를 읽느냐) - 인덱스 컬럼이 조건절에 모두 '=' 조건으로 사용될 때 선택도가 가장 높음 - Leaf Block을 scan하면서 읽은 레코드가 모두 테이블 access -> 비효율X - 인덱스 컬럼 중 일부가 조건절에 생략되거나 '=' 조건이 아니더라도 그것이 뒤쪽 컬럼일 때 비효율X - 인덱스 선행 컬럼이 조건절에 누락되거나 between, 부등호, like 같은 범위검색 조건이면 비효율 발생 [비:B.I.] BETWEEN 조건을 IN-LI..

IOT (Index-Organized Table)- Table Random Access가 발생하지 않도록 처음부터 인덱스 구조로 생성된 테이블- Index leaf block = data block (모든 행 데이터를 리프 블록에 저장)- 정렬상태를 유지하며 데이터를 삽입(PK 컬럼 순)CREATE TABLE INDEX_ORG_T ( A NUMBER PRIMARY KEY, B VARCHAR(10) )ORGANIZATION INDEX; -- 일반적으로 사용되는 테이블은 '힙 구조 테이블'로 ORGANIZATION HEAP; 이 생략되어 있는 것 장점- 클러스터링 팩터가 좋음- Random이 아닌 Sequential Access 방식이므로 넓은 범위 access 시 유리- PK 인덱스를 위한 별도의 세그먼트..

기본 메커니즘 - 둘 중 작은 집합(Build Input)을 읽어 Hash Area에 해시 테이블을 생성하고, 반대쪽 큰 집합(Probe Input)을 읽어 해시 테이블을 탐색하면서 JOIN하는 방식 - 해시 테이블을 생성할 때나 탐색할 때 모두 해시 함수 사용- JOIN 과정에서 발생하는 Random 액세스 부하가 없음 (각각의 집합을 읽는 과정에서는 Random 액세스 발생 가능)- 해시 테이블을 생성하는 비용이 수반되므로 Build Input이 충분히 작아야 효율적* Hash Area는 PGA 메모리에 할당되는데 Build Input이 hash_area_size를 초과하게 되면 디스크 I/O가 추가로 발생하게되므로 성능이 많이 저하됨 declare l_bucket number;beginfor out..