Msg 성장일기

[ 소트 수행 과정 ] 소트는 기본적으로 PGA에 할당한 Sort Area에서 이루어진다. Sort Area에서 작업을 완료할 수 있는지에 따라 소트를 두가지 유형으로 나눈다. 1. 메모리 소트(In-Memory Sort) : 전체 데이터의 정렬 작업을 메모리 내에서 완료하는 것을 말하며, 'Internal Sort'라고도 한다. 2. 디스크 소트(To-Disk Sort) : 할당받은 Sort Area 내에서 정렬을 완료하지 못해 디스크 공간까지 사용하는 경우를 말하며, 'External Sort'라고도 한다. 소트할 대상 집합을 SGA 버퍼캐시를 통해 읽어들이고 일차적으로 Sort Area에서 정렬을 시도한다. Sort Area 내에서 데이터 정렬을 마무리하는 것이 최적이지만, 양이 많을 때는 정렬된 ..

1.NL조인 (Nested Loop, 중첩 루프문) ↳ NL조인은 인덱스를 이용한 조인이다. (Outer와 Inner 양쪽 테이블 모두 인덱스를 이용한다.) 사원 X1 인덱스에서 입사일자 >= '19960101'인 첫번째 레코드 찾음 인덱스 ROWID로 사원 테이블 찾아감 사원 테이블에서 읽은 사원 번호로 고객_X1 인덱스를 탐색 고객_X1 인덱스에서 읽은 ROWID로 고객 테이블 레코드를 찾아감 -> 해당 사원 번호보다 작을 때 까지 고객_X1 인덱스 스캔 진행 위 루프를 사원 X1 인덱스에서 입사일자 >= '19960101'인 데이터에 대해서 지속적으로 반복 NL조인 실행계획 : 아래는 NL 조인 실행 계획 예시이다. 사원이 Outer에 해당하고 고객이 Inner에 해당한다 NESTED LOOPS T..

SQL 각각에 최적화된 인덱스를 마음껏 생성할 수 있다면, SQL 튜닝과 인덱스 설계만큼 쉬운 일도 없을 것이다. 하지만 인덱스가 너무 많으면 아래와 같은 문제가 발생한다. 더보기 1. DML 성능 저하 (→ TPS 저하) 2. 데이터베이스 사이즈 증가(→ 디스크 공간 낭비) 3. 데이터베이스 관리 및 운영 비용 상승 결합 인덱스 구성 시 중요한 기준 1. 조건절에 항상 사용하거나 자주 사용하는 컬럼을 선정한다. 2. '=' 조건으로 자주 조회하는 컬럼을 앞쪽에 둔다. → 위 2가지의 판단 기준은 인덱스 스캔 효율성이다. 그 외 고려해야할 판단 기준은 다음과 같다. → 수행빈도, 업무상 중요도, 클러스터링 팩터, 데이터량, 저장공간, DML 부하 등 수행빈도가 매우 높은 SQL이라면, 테스트 과정에 당장..

인덱스 스캔 효율성을 설명하기에 앞서 이해해야 할 용어 두가지가 있다. 바로 '액세스 조건','필터 조건'이다. 인덱스 액세스 조건 : 인덱스 스캔 범위를 결정하는 조건절, 인덱스 수직적 탐색을 통해 스캔 시작점을 결정하는 데 영향을 미치고, 인덱스 리프 블록을 스캐하다가 어디서 멈출지를 결정하는 데 열향을 미치는 조건절 인덱스 필터 조건 : 테이블로의 액세스할지를 결정하는 조건절, 쿼리 수행 다음 단계로 전달하거나 최종 결과집합에 포함할지를 결정한다. * 테이블과 달리 인덱스에는 '같은 값'을 갖는 레코드들이 서로 군집해 있다. '같은 값'을 찾을 때 '='연산자를 사용하므로 인덱스 컬럼을 앞쪽부터 누락없이 '='연산자로 조회하면 조건절을 만족하는 레코드는 모두 모여 있다. ┖ 선행컬럼이 모두 '=' ..

부분범위 처리 └ 사용자로부터 Fetch Call이 있을때마다 일정량씩 나누어 전송하는 것 OLTP환경에서 부분범위 처리에 의한 성능개선 원리 └ OLTP(Online Transaction Processing)은 온라인 트랜잭션을 처리하는 시스템이다. 온라인 트랜잭션은 일반적으로 소량 데이터를 읽고 갱신한다. └대량 데이터를 조회하면 많은 테이블 랜덤 액세스가 발생한다. 버퍼캐시히트율이 좋다면 빠른 성능을 보일 수 있지만 그렇지 않다면 오래 기다려야한다. select 게시글ID,제목,작성자,등록일시 from 게시판 where 게시판구분코드='A' order by 등록일시 desc └ 인덱스와 부분범위 처리 원리를 잘 활용하면 OLTP 환경에서 극적인 성능개선 효과를 얻을 수 있는 원리가 있다. └ 인덱스..

[ 인덱스 ROWID는 논리적주소 ] └ ROWID는 디스크 상에서 테이블 레코드를 찾아가기 위한 위치 정보를 담았기에 논리적 주소이다. └ 인덱스 ROWID는 포인터가 아니다. (*포인터: 메모리 주소값을 담는 변수) └ ROWID가 가리키는 테이블 블록을 버퍼캐시에서 먼저 찾아보고(위 그림 점선), 못 찾을 때만 디스크에서 블록을 읽는다. 물론 버퍼캐시에서 적재한 후에 읽는다. [ 인덱스 클러스터링 팩터(CF) ] └ 특정 컬럼을 기준으로 같은 값을 갖는 데이터가 서로 모여있는 정도를 의미한다. └ CF가 좋은 컬럼에 생성한 인덱스는 검색 효율이 매우 좋다. 이는 테이블 액세스량에 비해 블록I/O가 적게 발생함을 의미한다. 물리적으로 데이터가 근접해 있으면 찾는 속도가 빠르다. └ 읽어야 할 데이터가..

1. Index Range Scan └ BTree의 가장 일반적이고 정상적인 형태의 액세스 방식, 인덱스 루프에서 리프블록까지 수직적으로 탐색한 후에 '필요한 범위(Range)만' 스캔한다. 실행계획은 아래와 같다. 2. Index Full Scan └ 수직적 탐색없이 인덱스 리프 블록을 처음부터 끝까지 수평적으로 탐색하는 방식 Index full scan은 대개 데이터 검색을 위한 최적의 인덱스가 없을 때 차선으로 선택된다. 3. Index Skip Scan └ 오라클에서 인덱스 선두 컬럼이 조건절에 없어도 인덱스를 활용하는 새로운 스캔방식 └ 인덱스 선두 컬럼의 Distinct Value 개수가 적고 후행 컬럼의 Distinct value개수가 많을 때 유용하다. └ index skip scan은 루..

1.인덱스 구조 및 탐색 데이블에서 데이터 탐색 2가지 방법 ↳ 1) 테이블 전체를 스캔한다. ↳ 2) 인덱스를 이용한다 [ 인덱스 튜닝의 두 가지 핵심요소 ] ↳ 인덱스는 큰 테이블에서 소량 데이터를 검색할 때 주로 사용한다. 핵심요소 첫 번째, 인덱스 스캔 효율화 튜닝 -> 인덱스 스캔 과정에서 발생하는 비효율을 줄인다. 핵심요소 두 번째 , 랜덤 액세스 최소화 튜닝 -> 테이블 액세스 횟수를 줄인다. [ SQL 튜닝은 랜덤 I/O와의 전쟁 ] ↳ 데이터베이스 성능이 느린 이유는 디스크 I/O 때문이다. 읽어야 할 데이터량이 많고, 그 과정에서 디스크 I/O가 많이 발생할 때 느리다. OLTP 시스템이라면 디스크 I/O중에서 랜덤 I/O가 특히 중요하다. [B Tree 인덱스 구조] ↳ 루트와 브랜치..