Data/SQLP

1. 파티션 개요파티셔닝은 테이블 또는 인덱스를 파티션 단위로 나누어 저장하는 것을 말함.테이블을 파티셔닝하면 파티션 키에 따라 물리적으로는 별도의 세그먼트에 데이터를 저장하며, 인덱스도 마찬가지다.파티셔닝이 필요한 이유에 대해 설명해보자면 인덱스 스캔도 결국 데이터가 일정량이 넘어가는 순간 Random Access가 많아지고, 그렇다고 Full Scan 하기에는 너무 비효율적이다.관리적 측면 : 파티션 단위 백업, 추가, 삭제 변경성능적 측면 : 파티션 단위 조회 및 DML 수행, 경합 및 부하 분산2. 파티션 유형1) Range 파티셔닝파티션 키 값의 범위로 분할파티셔닝의 가장 일반적인 형태이며, 주로 날짜 컬럼을 기준으로 함 (예를 들어, 판매 데이터를 월별로 분할)2) Hash 파티셔닝파티션 키 ..

1. 인덱스 유지 비용테이블 데이터를 변경하면 관련된 인덱스에도 변경이 발생변경된 인덱스 레코드를 찾아가는 비용 + Redo, Undo 생성 비용이 발생그래서 인덱스 개수가 많을수록 DML 성능이 나빠짐Update를 수행할 때, 테이블 레코드는 직접 변경하지만 인덱스 레코드는 Delete 및 Insert 방식으로 처리됨Insert나 Delete 문일 때는 인덱스 모두에 변경을 가해 총 인덱스 개수에 따라 성능이 크게 달라짐그래서 대량의 데이터 처리가 발생할 때, 인덱스를 모두 Drop 하거나 Unusable 상태로 변경한 다음 처리하는게 빠를 수 있다.2. Insert 튜닝가. Oracle Insert 튜닝Direct Path InsertIOT(index-organized table) 는 정해진 key ..

인덱스를 이용한 소트 연산 대체가. Sort Order By 대체아래의 쿼리를 읽을 때 [region + custid] 순으로 구성된 인덱스 사용한다면 sort order by 연산을 대체할 수 있다.인덱스 미리 정렬이 되어있기 때문이라 생각하면 된다.물론 소트해야 할 대상 레코드가 무수히 많고 그 중 일부만 읽고 멈출 때 유용하다고 함인덱스를 스캔하면서 결과 집합을 끝까지 Fetch 한다면 오히려 I/O 및 리소스 사용측면서 손해임select custid, name, resno, status, tel1 from customer where region = 'A' order by custid-------------------------------------------------------------..

데이터 모델 측면에서의 검토자주 사용하는 데이터 엑세스 패턴을 고려하지 않고 물리 설계를 진행하거나, M:M 관계를 해소하지 않아 핵심 프로그램이 항상 소트 오퍼레이션을 수행하여 성능이 저하되는 경우 흔히 접할 수 있다.아래의 상황을 보면 PK 없거나, 적거나 아래의 가입상품 테이블 처럼 소수일 때, 테이블 간소화를 위해 고객별상품라인 테이블로 통합하는 상황이 있다.정합성에는 이슈가 없겠지만, 자주 조회가 일어난다면 성능이 좋을리가 없다.select 과금.고객id, 과금.상품id, 과금.과금액, 가입상품.가입일시 from 과금, ( select 고객id, 상품id, min(가입일시) 가입일시 from 고객별상품라인 group by 고객id, 상품id) 가입상품 where 과금..

1. 소트와 성능가. 메모리 소트와 디스크 소트SQL 수행 도중 Sort 연산은 메모리 공간에 Sort Area에 할당하고 정렬을 수행한다. Oracle에서는 PGA(Program Global Area) 영역에 할당한다.그러나 많은 데이터를 사용할 때는 오버 플로우로 인해 디스크 공간을 사용해야 한다.메모리 (In-Memory) 소트전체 데이터의 정렬 작업을 할당받은 소트 영역 내에서 완료하는 것을 말하며, Internal Sort 또는 Optimal Sort 라고도 한다.디스크(To-Disk) 소트할당 받는 소트 영역 내에서 정렬을 완료하지 못해 디스크 공간까지 사용하는 경우를 말하여 External Sort라 한다.나. 소트를 발생시키는 오퍼레이션Sort Aggregate전체 로우 대상 집계를 수행할..

6. 불필요한 조인 제거1:M 관계인 두 테이블을 조인하는 쿼리문에서 조인문을 제외한 어디에서도 1쪽 테이블 참조하지 않는다면 쿼리 수행시 1쪽 테이블 읽지 않고 M쪽 테이블만 읽도록 쿼리를 변환한다. 이를 조인 제거 또는 테이블 제거라고 한다.아래의 쿼리 및 실행계획 예시를 보면 된다.select e.empno, e.ename, e.deptno, e.sal, e.hiredate from dept d, emp e where d.deptno = e.deptnoRows Row Source Operation ---- --------------------------------------------------- 14 TABLE ACCESS FULL EMP (cr=8 pr=0 pw=0 time=58 us)조인 ..

4. 조건절 Pushing옵티마이저가 뷰를 처리함에 있어 1차적으로 뷰 Merging을 고려하지만, 조건절 Pushing을 시도할 수도 있다.조건절이 가능한 빨리 처리되도록 뷰 안으로 밀어 넣는다면, 뷰 안에서의 처리량 최소 및 리턴 결과 감소로 다음 단계에서 처리를 줄일 수 있다.크게 3가지 조건절 Pushing이 있다.조건절 Pushdown: 쿼리 블록 밖에 있는 조건절을 쿼리 블록 안 쪽으로 밀어 넣는 것을 말함조건절 Pullup: 쿼리 블록 안에 있는 조건절을 쿼리 블록 밖으로 내와서 다른 쿼리 블록으로 Pushdown 하는데 사용조인 조건 Pushdown: NL 조인 수행 중에 드라이빙 테이블에서 읽은 값을 건건이 Inner 쪽 뷰 쿼리 블록 안으로 밀어넣는 것을 말한다.가. 조건절(Predic..

1. 쿼리 변환이란?옵티마이저가 SQL 분석해 의미적으로 동일하면서도 더 나은 성능이 기대되는 형태로 재작성하는 것을 말한다.쿼리 변환은 크게 2가지 방식으로 작동한다.휴리스틱 쿼리 변환: 결과만 보장된다면 무조건 쿼리 변환을 수행한다.비용기반 쿼리 변환: 변환된 쿼리의 비용이 더 낮을 때만 그것을 사용하고 그렇지 않을 때는 원본 쿼리 그대로 두고 최적화를 수행한다.2. 서브쿼리 Unnesting중첩된 서브쿼리를 풀어내는 것을 말한다.아래는 하나의 쿼리에 서브쿼리가 이중삼중으로 중첩될 수 있음을 보여준다.select * from emp a where exists ( select 'x' from dept where deptno = a.deptno ) and sal > ( sele..

애플리케이션 캐싱과 Static 및 Dynamic SQL 내용은 생략했다.1. 소프트 파싱 VS 하드 파싱시스템 공유 메모리에서 SQL 과 실행계획이 캐싱되는 영역을 Oracle 에선 라이브러리 캐시라고 한다.사용자가 SQL을 실행하면 제일 먼저 SQL Parser가 SQL 문장의 문법적 오류가 없는지를(Syntax 검사)한다.문법적 오류가 없으면 의미상 오류(Semantic 검사) 를 검사한다.예를 들어 존재하지 않거나 권한 없는 객체를 사용했는 지 등을 조사한다.그리고 나서 라이브러리 캐시에 캐싱됬는지 확인한다.소프트 파싱: SQL과 실행계획을 캐시에서 찾아 곧바로 실행 단계로 넘어가는 경우하드 파싱: SQL과 실행계획을 캐시에서 찾지 못해 최적화 과정을 거치고 나서 실행단계로 넘어가는 경우실행계획 ..

1. 옵티마이저 소개옵티마이저 종류규칙기반 옵티마이저: 미리 정해 놓은 규칙에 따라 엑세스 경로를 평가하고 실행계획을 선택, 여기 말하는 규칙이란 인덱스 구조, 연산자 조건절 등을 말한다.비용기반 옵티마이저: 비용을 기반으로 최적화를 수행한다. 이 때 비용은 레코드 개수, 블록 개수, 평균 행 길이, 컬럼 값의 수, 컬럼 값 분포, 인덱스 높이, 클러스터링 팩터 등이 있다.최적화 목표전체 처리속도 최적화: 쿼리 최종 결과 집합을 끝까지 읽는 것을 전체로, 시스템 리소스를 가장 적게 사용하는 실행계획을 선택한다.아래와 같이 옵티마이저 모드를 바꿀 수 있다.alter system set optimizer_mode = all_rows; -- 시스템 레벨 변경 alter session set optimizer_..