인덱스는 항상 키 컬럼 순으로 정렬된 상태를 유지한다. -> 이것을 활용하면 SQL에 Order By 또는 Group By 절이 있어도 소트 연산을 생략할 수 있다. 여기서 Top N 쿼리 특성을 결합하면, 온라인 트랜잭션 처리 시스템에서 대량 데이터를 조회할 때 매우 빠른 응답 속도를 낼 수 있다. 최소값 또는 최대값도 빨리 찾을 수 있다.
Sort Order By 생략
인덱스 선두 컬럼을 '종목코드 + 거래일시' 순으로 구성하지 않으면 소트 연산을 생략할 수 없다.
종목 코드를 만족하는 레코드를 인덱스에서 모두 읽어야하며, 그만큼 랜덤 액세스 발생
소트 연산할 수 없을때 생기는 실행계획인덱스 구성 제대로 하면 생략되는 실행계획
부분범위 처리를 활용한 튜닝 기법
요즘 DB 어플리케이션은 대부분 3-Tier 환경 (WAS, AP 서버)에서 작동한다. -> 서버 리소스를 수많은 클라이언트가 공유하는 구조이므로 클라이언트가 특정 DB 커넥션을 독점할 수 없다. 단위 작업을 마치면 DB 커넥션을 바로 커넥션 풀을 반환해야 하므로 그 전에 쿼리 조회 결과를 클라이언트에게 모두 전송하고 커서를 닫아야한다. 부분범위 처리를 할 수 없다.
부분범위 처리는 쿼리 수행 결과중 앞쪽 일부를 우선 전송하고 멈추었다가 클라이언트가 추가 전송을 요청할때마다 남은 데이터를 조금씩 나눠 전송하는 방식이므로 3Tier환경에서는 Top N 쿼리로 인해 유효하다.
Top N 쿼리
전체 결과집합 중 상위 N개 레코드만 선택하는 쿼리
인라인 뷰로 정의한 집합을 모두 읽어 거래일시 순으로 정렬한 중간 집합을 우선 만들고 거기서 상위 열개 레코드를 취하는 형태로 보기엔 인덱스를 구성해 주더라도 중간집합을 만들어야 하므로 부분범위 처리는 불가능해 보인다.
하지만 종목코드 + 거래일시 순으로 인덱스를 이용하면 옵티마이저는 소트연산을 생략하며, 인덱스를 스캔하다가 열개 레코드를 읽는 순간 멈춘다.
Sort Order By 대신 Count(STOPKEY)가 생긴다. 이는 조건절에 부합하는 레코드가 아무리 많아도 그 중 ROWNUM으로 지정한 건수만큼 결과 레코드를 얻으면 거기서 바로 멈춘다는 뜻이다. 이것을 Top N StopKey 알고리즘이라 한다.
페이징 처리
3 Tier 환경에서 대량의 결과집합을 조회할 때 페이징 처리 기법을 활용한다.
Top N 쿼리이므로 ROWNUM으로 지정한 건수만큼 결과 레코드를 얻으면 거기서 바로 멈춘다.
부분범취 처리 가능하도록 SQL을 작성한다 (인덱스 사용 가능하도록 조건절을 구성하고, 조인은 NL 조인 위주로 처리 [룩업을 위한 작은 테이블은 해시 조인 Build Input으로 처리해도됨]하고, Order By절이 있어도 생략할 수 있도록 인덱스 구성)
작성한 SQL 문을 페이징 처리용 표준 패턴 SQL Body 부분에 넣는다
예시
페이징 처리 ANTI 패턴
위의 SQL 문은 ROWNUM 조건절이 불 필요해보인다.
그래서 이렇게 처리한다.
그런데 Order By 아래쪽 ROWNUM은 단순한 조건절이 아니다. Top N Stopkey알고리즘을 작동하게 하는 열쇠이다.
sql을 바꾸니 Stopkey가 없어졌다. 전체범위를 결국 처리했다.
최소값/최대값 구하기
최소값이나 최댓값 구하는 SQL에서 Sort Aggregate 오퍼레이션이 나타난다.
인덱스는 정렬돼 있으므로 이를 이용하면 전체데이터를 안읽어도 최소 최대를 찾을 수 있다.
인덱스를 이용해 최대값 찾을때
전체 데이터를 읽지 않고 인덱스를 이용해 최소 또는 최대값을 구하려면, 조건절 컬럼과 MIN/MAX 함수 인자 컬럼이 모두 인덱스에 포함되어있어야한다. 즉 테이블 액세스가 발생하면 안된다.
인덱스를 DEPTNO + MGR + SAL 순으로 구성하면 이렇게 된다.
조건절 컬럼과 MAX 컬럼이 모두 인덱스에 포함되어있고 인덱스 선두 컬럼이 모두 =이다. FIRST ROW는 조건을 만족하는 레코드 하나를 찾았을 때 바로 멈춘다는 의미
작동안함
Top N 쿼리를 이용해 최소/최대값 구하기
MGR 컬럼이 없음
ROWNUM <= 1 조건을 이용해 Top 1 레코드를 찾는다.
Top N Stopkey 알고리즘은 모든 컬럼이 인덱스에 포함돼 있지 않아도 잘 작동한다.
이력조회
일반 테이블은 각 컬럼의 현재 값만 저장하므로 변경되기 이전 값을 알 수 없다.
이력 테이블을 따로 관리해야한다.
과거 변경이력을 관리하기 위해 이력 테이블을 두지만, 일반적으로 이 테이블에는 현재 데이터도 저장한다. 그렇게 구현해야 변경 이력을 완벽히 재생할 수 있다.
특정 장비의 최종 상태코드가 'A2'인데 이 값으로 바뀐 날짜를 알고 싶다면, 이력 테이블에서 확인해야한다. 장비 테이블에도 최종 변경일자가 있지만 이 값을 이용할 순 없다. 이 값은 상태코드 이외의 컬럼, 즉 장비명 또는 장비구분코드가 바뀔 때도 갱신된다.
가장 단순한 이력 조회
이력 데이터 조회할때 First Row Stopkey 또는 Top N Stopkey 알고리즘이 작동될 수 있게 설계, 구현해야한다
.
위 SQL은 상태코드가 현재 값으로 변경된 날짜는 상태변경이력에서 조회하고 있다.
실행계획에서 First Row Stopkey알고리즘이 작동하고있다.
PK 인덱스가 장비번호 + 변경일자 + 변경순번으로 되어있기 때문
위 SQL은 인덱스 컬럼을 가공해서 First Row Stopkey가 작동하지 않는다.
이렇게 변경하면 코드가 복잡하고 3번조회하지만 효율은 좋다.
근데 상태코드 말고도 이력 테이블에서 읽어야할 컬럼이 더 많다면?
-> INDEX_DESC 힌트
인덱스를 역순으로 읽는 힌트 index_desc , 그리고 첫번째 레코드에서 바로 멈추도록 rownum <= 1
문제는 인덱스 구성이 완벽해야 쿼리가 잘 작동한다. 구성이 바뀌면 결과 집합에 문제가 생길수있다.
오류 발생
11c부터는
이렇게 작성가능
Predicate Pushing이라는 쿼리 변환 작동하였다.
상황에 따라 달라져야하는 이력 조회 패턴
일부 장비가 아닌 전체 장비, 최종이력이 아닌 직전 이력, 특정 산태로 변경한 최종 이력 등 상황에 따라 패턴도 달라져야한다.
특히, 전체 장비의 이력을 조회할 때는 인덱스를 이용한 Stopkey 기능 작동 여부가 튜닝 핵심요소가 아니다. 인덱스 활용 패턴은 랜덤 I/O 발생량 만큼 성능도 비례해서 느려지므로 대량 데이터를 조회할 때 결코 좋은 솔루션이 되지 못한다.
전체 장비의 이력을 조회할 때는 아래와 같이 윈도우 함수를 이용한다.
Full Scan과 해시 조인을 이용하기 때문에 인덱스보다 빠르다.
KEEP 절을 활용할 수 있다.
선분이력 모델
선분 이력 모델은 간단한 쿼리로 쉽게 이력을 조회할 수 있고 성능 측면 이점도 있다.
Sort Group By
그룹핑 연산에도 인덱스를 활용할 수 있다. 아래는 region이 선두인 인덱스를 이용했다.
SQL 수행 도중 가공된 데이터 집합이 필요할때, 오라클은 PGA, Temp를 활용한다. (소트 머지, 해시, 데이터 소트, 그룹핑)
소트 수행 과정
Sort Area에서 작업을 완료할 수 있는지에 따라 소트를 두 가지 유형을 나눈다
메모리 소트 : 전체 데이터의 정렬 작업을 메모리 내에서 완료하는 것 Internal Sort
디스크 소트 : 할당받은 Sort Area 내에서 정렬을 완료하지 못해 디스크 공간가지 사용하는 경우 External Sort
디스크 소트
그림은 소트할 대상 집합을 SGA 버퍼캐시를 통해 읽어들이고, 일차적으로 Sort Area에서 정렬을 시도한다. 여기서 끝나면 최적이지만 양이 많으면 Temp 테이블스페이스에서 임시 세그먼트를 만들어 저장한다.(Sort Run : Temp 영역에 저장해 둔 중간 단계의 집합)
정렬된 최종 결과집합을 얻으려면 다시 Merge한다. Sort Run 내에서는 이미 정렬된 상태이므로 Merge는 어렵지 않다. 오름차순 정렬이면 각각에서 가장 작은 값부터 PGA로 읽어 들이다가 PGA가 찰 때마다 쿼리 수행 다음 단계로 전달하거나 클라이언트에게 전송
소트 연산은 메모리 집약적, CPU 집약적(데이터량이 많을때)이다.
디스크 I/O가 발생하는 것도 문제지만, 부분범위 처리를 불가능하게 함으로써 OLTP 환경에서 애플리케이션 성능을 저하시키는 주 요인이다. 될수있으면 소트를 발생시키지 않게, 불가피하다면 메모리내에서.
소트 오퍼레이션
Sort Aggregate
Sort Order By
Sort Group By
Sort UniQue
Sort Join
Window Sort
Sort Aggregate
전체 로우를 대상으로 집계를 수행할 때 발생
실제로 데이터를 정렬하진 않고, Sort Area를 사용한다.
Sort Area 에 SUM, MAX, MIN, COUNT 값을 위한 변수를 하나씩 할당한다
첫번째 레코드에서 읽은 SAL 값을 SUM, MAX, MIN 변수에 저장하고, Count 변수에는 1을 저장한다.
레코드를 하나씩 읽어 내려가며
SUM 변수에는 값을 누적하고
MAX 변수에는 기존보다 큰 값이 나타날 때마다 값을 대체
MIN 변수에는 기존보다 작은 값이 나타날때 마다 값을 대체
COUNT 변수에는 NULL이 아닌 레코드를 만날때마다 1씩 증가
다 읽었으면 그 값을 그대로 출력하고 AVG는 SUM 값을 COUNT 값으로 나눈 값 출력
Sort Order By
데이터를 정렬할때 나타난다.
Sort Group By
소팅 알고리즘을 위해 그룹별 집계를 수행할때 나타남.
Hash Group by
Hash Group By : 10gR2버전부터 도입 Group By 절을 뒤에 Order By 절을 명시하지 않으면 대부분 Hash Group By 방식으로 처리 읽는 레코드마다 Group By 컬럼의 해시 값으로 해시 버킷을 찾아 그룹별로 집계항목을 갱신
* 그룹핑 결과가 정렬 순서를 보장하지 않는다. 소팅 알고리즘을 사용해 그룹핑한 결과 집합은 논리적인 정렬 순서를 갖는 연결 리스트 구조이다. 정렬된 그룹핑 결과를 얻고자 한다면 실행계획에 Sort Group By라고 표시해도 반드시 Order By를 명시해야한다.
Order By 절을 추가한다고 해서 그룹핑과 정렬 작업을 각각 수행하지 않는다.
Sort UniQue
옵티마이저가 서브쿼리를 풀어 일반 조인문으로 변환하는 것을 서브쿼리 Unnesting이라고 한다. Unnesting된 서브쿼리가 M쪽 집합이라면 (1쪽 집합이라도 조인컬럼에 Unique 인덱스가 없으면) 메인쿼리와 조인하기 전에 중복 레코드부터 제거해야한다.
만약 PK/Unique 제약 또는 Unique 인덱스를 통해 Unnesting된 서브쿼리의 유일성이 보장된다면 Sort Unique 오퍼레이션은 생략된다.
---> 그러니까 일대다에서는 M쪽 집합이라면 M크기만큼 테이블을 여러번 나올수 있다는 거지
Union, Minus, Intersect 같은 집합 연산자나 Distinct를 사용할 때도 Sort Unique오퍼레이션이 나타난다.
옵티마이저는 비용을 평가하고 실행계획을 생성하므로, 전달받은 SQL을 최적화에 유리한 형태로 변환하는 쿼리 변환부터 진행한다.
-> 얘땜에 옵티마이저 엔진이 점점 무거워지고 최적화에 소요되는 시간도 점점 늘고있다.
쿼리 변환 : 옵티마이저가 SQL을 분석해 같은 결과 집합을 생성하면서도 더 나은 성능이 기대되는 형태로 재작성하는 것
스칼라 서브쿼리 : 한 레코드당 정확히 하나의 값을 반환하는 서브쿼리, 주로 SELECT-LIST에서 사용하지만 컬럼이 올수있는 대부분 위치에서 사용가능
인라인 뷰 : FROM 절에 사용한 서브쿼리
중첩된 서브쿼리 : 결과집합을 한정하기 위해 WHERE 절에 사용한 서브쿼리. 특히 서브쿼리가 메인쿼리 컬럼을 참조하는 형태를 '상관관계 있는 서브쿼리' 라고 한다.
서브쿼리와 조인
메인쿼리와 서브쿼리 간에는 부모-자식이라는 중속적으로 계층적인 관계가 존재
서브쿼리는 메인쿼리에 종속되므로 단독으로 실행할 수 없다 -> 메인쿼리 건수만큼 값을 받아 반복적으로 필터링
필터 오퍼레이션 : 서브쿼리를 필터 방식으로 처리
서브쿼리 Unnesting : 중첩된 서브쿼리를 조인 형태로 변환하는 최적화 기법
서브쿼리 Pushing : 서브쿼리를 더 효율적인 위치로 이동시키는 방법
필터 오퍼레이션 (unnest, no_unnest)
no_unnest : 서브쿼리를 풀어내지말고 그대로 수행하라고 처리하게 지시하는 옵티마이저
옵티마이저는 기본적으로 서브쿼리를 조인으로 변환 (Unnesting)하여 처리하지만 no_unnest 사용시 필터 형태로 처리
메인 쿼리는 고객 테이블에서 한달 전보다 오래된 데이터를 조회
서브 쿼리는 거래 테이블에서 현재날짜 기준으로 거래가 있는 고객 확인
필터 (Filter) 오퍼레이션은 기본적으로 NL 조인과 처리 루틴이 같다. 실행계획에서 NESTED LOOPS로 치환하고 처리 루틴을 해석하면된다.
필터와 NL조인차이?
필터 : 조건이 맞는 데이터 하나만 찾으면 바로 다음으로 넘어감, 이전에 찾았던 같은 값은 캐시에 저장해두고 재사용, 항상 메인 쿼리 먼저 실행
NL 조인 : 조건이 맞는 모든 데이터를 찾음, 캐싱안하고 매번 새로 찾음, 순어 변경 가능
고객 테이블: 홍길동, 김철수, 이영희 거래 테이블: 각 고객당 여러 건의 거래 있음
필터 사용시: 홍길동 -> 거래 있음 확인되면 바로 다음 고객으로 김철수 -> 거래 있음 확인되면 바로 다음 고객으로 이영희 -> 거래 있음 확인되면 끝
NL 조인 사용시: 홍길동 -> 모든 거래 다 찾음 김철수 -> 모든 거래 다 찾음 이영희 -> 모든 거래 다 찾음
첫번째는 필터는 메인쿼리(고객)의 한 로우가 서브쿼리(거래)의 한 로우와 조인에 성공하는 순간 진행을 멈추고 메인쿼리의 다음 로우를 처리한다. -> 메인쿼리 결과집합이 서브쿼리 M쪽 집합 수준으로 확장되는 형상 (고객번호 중복)을 막을 수 있다.
두번째는 필터는 캐싱기능을 갖는다는 점. 이는 필터 처리한 결과, 즉 서브쿼리 입력 값에 따른 반환 값(true,false)을 캐싱하는 기능. 이 기능이 작동하므로 서브쿼리를 수행하기 전에 항상 캐시부터 확인한다. 캐시에서 true/false 여부를 확인 할 수 있다면 서브쿼리를 수행하지 않아도 되므로 성능을 높이는데 큰 도움이 된다.
마지막은 필터 서브쿼리는 일반 NL조인과 달리 메인 쿼리에 종속되므로 조인 순서가 고정된다. 항상 메인 쿼리가 드라이빙 집합이다.
캐싱은 쿼리 단위로 이루어지며 쿼리를 시작할 때 PGA 메모리에 공간을 할당하고 쿼리를 수행하면서 공간을 채워나가며, 쿼리를 마치는 순간 공간을 반환한다.
서브쿼리 Unnesting
unnest는 중첩된 상태를 풀어내라 -> 서브쿼리 unnesting은 메인과 서브쿼리 간의 계층구조를 풀어 서로 같은 레벨로 만들어준다는 의미에서 서브쿼리 Flattening이라고 한다.
서브쿼리를 그대로 두면 필터 방식을 사용할 수 밖에없지만 Unnesting하면 일반 조인문처럼 다양한 최적화 기법을 사용할 수 있다.
NL 세미 조인 : NL 조인과 같은 프로세스 -> 조인에 성공하는 순간 진행을 멈추고 메인 쿼리의 다음 로우를 계속 처리한다는 점, 10g부터 캐싱기능도 갖게되었음
그럼 그냥 필터인데? -> 필터는 항상 메인 쿼리가 드라이빙 집합이지만, Unnesting된 서브쿼리는 조인 순서 바꿀수있다.
서브 쿼리를 그대로 풀어서 조인하면 메인쿼리 결과집합(고객)이 서브쿼리 M(일대다)쪽 집합(거래) 수준으로 확장 [고객당 여러 거래가 있으므로 거래 테이블이 M쪽 집합, 조인 결과가 거래 건수만큼 중복되어 나온다는 의미]될 수 있으므로 서브쿼리 집합에 대한 Sort Unique 오퍼레이션부터 수행했음을 확인할 수 있다. 서브쿼리 집합에서 고객번호 중복을 제거하기 위해 쿼리를 아래와 같이 변환하였다.
서브쿼리 Pushing (push_subq, no_push_subq)
Unnesting되지 않은 서브쿼리는 항상 필터 방식으로 처리되며, 대게 실행계획 상에서 맨 마지막 단계에서 처리된다.
상품으로부터 주문 테이블로 1000번(3)의 조인 액세스가 있었고, 조인에 성공한 주문 데이터는 60000개(2)다. 조인 과정에서 38097(5) 블록을 읽었다. 60000개 조인 결과집합은 서브쿼리 필터링을 수행하고 나서 3000(1)개로 줄었다. 총 읽은 블록수는 38103(4)다. 대부분 I/O가 조인에서 발생 -> 서브쿼리 필터링을 먼저 처리해서 조인 단계로 넘어가는 로우 수를 크게 줄일수있다면 성능은 향상된다.
서브 쿼리를 필터링한 결과가 150건(1)이므로 주문 테이블과의 조인 횟수도 150번으로 줄었고 주문 데이터도 3000개(2)만 읽었다. 총 읽은 블록수도 1903(3)로 줄었다.
즉,
Pushing 서브쿼리는 서브쿼리 필터링을 가능한 앞 단계에서 처리하도록 강제한다. 이 기능은 Unnesting 되지않은 서브쿼리에만 작동한다. -> push_subq 힌트는 no_unnest 힌트와 같이 기술한다.
뷰와 조인
최적화 단위가 쿼리 블록이므로 옵티마이저가 뷰 쿼리를 변환하지 않으면 뷰 쿼리 블록을 독립적으로 최적화한다.
이 쿼리에서 뷰를 독립적으로 최적화하련니 당월 거래 전체를 읽어 고객 번호 수준으로 Group by하는 실행계획을 수립하고 고개테이블과 조인은 그 다음에 했다.
문제는 고객 테이블에서 '전월 이후 가입한 고객'을 필터링하는 조건이 인라인 뷰 바깥에 있다 -> 인라인 뷰 안에서는 당월 거래한 '모든' 고객의 거래 데이터를 일겅야한다.
뷰를 메인 쿼리와 머징실행계획을 보니 쿼리가 이렇게 변환되었다.
실행계획을 보니, 고객 테이블을 먼저 읽고 인덱스를 이용해 전월 이후 가입만 고객만 읽고 거래 테이블과 조인할 때는 해당 고객들에 대한 당월 거래만 읽는다.
단점은 조인에 성공한 전테 집합을 Group By하고나서야 데이터를 출력할 수 잇으므로 부분범위 처리가 불가능하다 -> 전월 이후 가입한 고객이 매우 많고 당월 거래도 매우 많다면 NL조인이 별로 안좋다.
조인 조건 Pushdown : 11g 이후 조인 조건 Pushdown이 생김. 메인 쿼리를 실행하면서 조인 조건절 값을 건건이 뷰안으로 밀어 넣는 기능
이 방식을 사용하면 전월 이후 가입한 고객을 대상으로 '건건이' 당월 거래 데이터만 읽어서 조인하고 Group By를 수행한다. 중간에 멈출수도있다. 즉 부분 범위 처리가 가능한다. 뷰를 독립적으로 실행할 때처럼 당월 거래를 모두 읽지 않아도 되고, 뷰를 머징할 때 처럼 조인에 성공한 전체 집합을 Group. By 하지 않아도 된다.
push_pred는 no_merge힌트와 함께 써야한다.
스칼라 서브쿼리 조인
GET_DNAME 함수를 만들고 실행시키면 함수 안에 있는 SELECT 쿼리를 메인쿼리 건수만큼 '재귀적으로' 반복 실행한다.
이 스칼라 서브쿼리는 메인쿼리 레코드마다 정확히 하나의 값만 반환한다. 메인쿼리 건수만큼 DEPT 테이블을 반복해서 읽는다는 측면에서 함수와 비슷해 보이지만 함수처럼 재귀적으로 실행하지 않고 컨텍스트 스위칭없이 메인 쿼리와 서브쿼리를 한몸체처럼 실행한다.
스칼라 서브쿼리는 처리 과정에서 캐싱작용이 발생한다.
캐싱효과
스칼라 서브쿼리로 조인하면 오라클은 조인 횟수를 최소화하려고 입력 값과 출력 값을 내부캐시에 저장한다. 조인할 때마다 일단 캐시에서 일력값을 찾고 찾으면 저장된 출력 값을 반환한다. 캐시를 찾지못할때 조인 수행하고 결과는 버리지않고 캐시에 저장
조인할 데이터를 캐시에서 찾으면 조인 수행횟수 최소화
캐싱은 쿼리 단위로 이루어진다. 쿼리를 시작할 때 PGA메모리에 공간을 할당하고, 쿼리를 수행하면서 공간을 채워나가며, 쿼리를 마치는 순간 공간을 반환한다.
부작용
캐시 공간은 늘 부족한다. (8,9i기준 256개 엔트리 캐싱, 10g이후로는 입력과 출력 값 크기, _query_execution_cache_max_size 파라미터에의해 결정)
스칼라 서브쿼리 캐싱 효과는 입력 값의 종류가 소수여서 해시 충돌 가능성이 작을때 효과가 있다. 반대면 캐시를 매번 확인하는 비용때문에 오히려 성능이 나빠지고 CPU, 메모리만 더 쓴다.
거래 구분 코드로 20개 값이 존재한다 -> 캐시에 충분히 저장 -> 50000개 거래 읽는 동안 조인 액세스는 최초 한번만 읽어남 -> 성능 굳
고객 (100만명) -> 캐시 너무 많음 -> 메인쿼리에서 50000개 거래 읽는 동안 캐시 매번 탐색 하지만 거의 못찾음 -> 결국 조인 -> 오히려 캐시 탐색으로 성능 안좋아짐)
해결방안 -> 최근 3개월간 수백명 이내 일부 고객만 거래 발생시켜야함
매도계좌번호, 매수계좌번호가 무수히 많다면 스칼라 서브쿼리 캐싱효과 전혀 기대할수없고 오히려 성능 떨어뜨림
또한 메인 쿼리 집합이 매우 작을때 : 캐싱은 쿼리 단위로 이루어진다는 것은 쿼리 단위로 쓰고 버린다는 것. 메인쿼리 집합이 클수록 재사용성이 높아 효과가 좋지만 메인쿼리 집합이 작으면 캐시 재사용성이 낮다.
고객당 계좌가 많지 않기때문에 쓰지도 않을 캐시를 할당해서 값을 채웠다가 바로 버리는 비효율
2개 이상 값 반환
메인 쿼리가 실행계획 아래쪽에 있고 스칼라 서브쿼리 부분은 위쪽에 있다. 프로세싱은 NL조인과 같다. NL조인처럼 부분범위 처리도 가능한다. 다른점은 캐싱 효과가 있다.
근데 이렇게 하면 안된다.
이럴수도 없고
구하는 값을 문자열로 결합하고, 바깥쪽 액세스 쿼리에서 substr로 분리하는 방식도 있고 TYPE은 불편해서 잘 안씀
그럼 그냥 인라인 뷰를 사용하면 편하긴한데. 당월 거래 전체를 읽어야하거나 Group By 때문에 부분범위 처리가 안되는 문제가 있다.
11g이후로 조인 조건 Pushdown 기능이 있어 인라인 뷰를 잘 사용한다.
스칼라 서브쿼리 Unnesting
스칼라 서브쿼리도 NL 방식으로 조인하므로 캐싱 효과가 크지않으면 랜덤 I/O부담이 있다. 스칼라 서브쿼리를 일반 조인문으로 변환하거나 병렬 쿼리에선 될수있으면 서브쿼리를 사용하지 말아야한다. 병렬쿼리는 대량 데이터를 처리해야하므로 해시 조인으로 처리해야 효과적
_optimizer_unnest_scalar_sq
true : 스칼라 서브쿼리를 Unnesting할지를 옵티마이저가 결정
false : 사용자가 unnest 힌트로 유도
merge unnest같이 썼을때unnest로 일부 쿼리에 문제가 생겼을때 파라미터 false설정안하고 해결하는법
