v0o0v blog

7.1 통계정보와 비용 계산 원리 7.1.1 선택도와 카디널리티 선택도 : 전체 레코드 중 조건절에 의해 선택되는 레코드 비율 '=' 조건으로 검색 할 때 경우 선택도 = 1 / NDV NDV : 컬럼값 종류 개수(성별이라면 남/여 2) 카디널리티 : 전체 레코드 중에서 조건절에 의해 선택되는 레코드 개수 카디널리티 = 총 로우 수 * 선택도 = 총 로우 수 / NDV *옵티마이저는 카디널리티 값을 통하여 비용을 산출하고 비용을 통하여 옵티마이징 방식을 결정한다. 따라서 카디널리티값의 기초가 되는 선택도 값의 계산이 매우 중요하다. 7.1.2 통계정보 오브젝트 통계 테이블 통계 테이블 통계 조회 select num_rows -- 총 레코드 계수 ,blocks -- 테이블 블록 수 = &#3..

6장 소트 튜닝 6.1 기본 DML 튜닝 DML 성능에 영향을 미치는 요소 인덱스 인덱스가 늘어나면 Insert / Delete / Update 시 부하가 늘어난다. 특히 Update 시에는 변경과 인덱스 수조 내에서 정렬을 다시해야 하는 이중적인 부하가 발생한다. 무결성 제약 무결성 제약 중 PK/FK 제약은 Check / Not Null 보다 성능에 더 큰 영향이 있다. 실제 데이터를 조회하기 때문이다. 조건절 2/3장에서 학습한 인덱스 튜닝 원리 참고. 서브쿼리 4장에서 학습한 조인 튜닝 원리 참고. Redo 로깅 DML 수행 시마다 Redo 로그 생성하기 때문에 DML에 성능에 영향을 끼친다. Undo 로깅 DML 수행 시마다 Undo 로그 생성하기 때문에 DML에 성능에 영향을 끼친다. Lock..

5장 소트 튜닝 5.1 소트 연산에 대한 이해 소트 수행 과정 소트 연산은 메모리와 CPU를 많이 쓴다. 처리할 양이 많을 때는 디스크 I/O를 사용하기도 한다. 부분범위 처리가 불가해서 OLTP 환경에서 앱 성능을 저하시킨다. 따라서, 되도록 소트를 안하도록 SQL를 작성하고 불가피할경우 메모리내에서 수행이 완료되도록 한다. 소트 오퍼레이션 Sort Aggregate 실제 데이터를 정렬하진 않고 Sort Area 사용 SUM / MAX / MIN / COUNT Sort Order By 실제 소트 실행 Sort Group By 소팅 알고리즘을 사용해 그룹별 집계 수행 Sort Unique Unnesting된 서브쿼리가 M쪽 집합이면 메인 쿼리와 조인하기 전에 중복 레코드 제거 Sort Join 소트 머지..

4.4장 서브쿼리 조인 4.4.1 서브쿼리 변환이 필요한 이유 서브쿼리의 종류 인라인 뷰 : FROM 절에 사용한 서브쿼리 중첩된 서브쿼리 : 결과집합을 한정하기 위해 WHERE 절에 사용한 서브쿼리. 서브쿼리가 메인쿼리 컬럼을 참조할 때 상관관계 있는(Correlated) 서브쿼리라고 한다. 스칼라 서브쿼리 : 한 레코드당 정확히 하나의 값을 반환하는 서브쿼리. 주로 SELECT 절에 사용하지만 컬럼이 올 수 있는 대부분 위치에 사용가능. 메인쿼리도 하나의 쿼리 블록이며 옵티마이저는 쿼리 블럭 단위로 최적화 수행. 하지만, 서브쿼리별로 따로 최적화했다고 해서 전체 쿼리가 최적화 됐다고 할 수 없기 때문에 전체를 바라보는 관점에서 쿼리를 이해하려면 서브쿼리는 풀어내야 한다. 4.4.2 서브쿼리와 조인 메..

3장 인덱스 튜닝 3.3 인덱스 스캔 효율화 3.3.5 인덱스 선행 컬림이 등치(=) 조건이 아닐 때 생기는 비효율 인덱스 스캔 효율성은 인덱스 컬럼을 조건절에 모두 등치(=) 조건을 사용할 때 가장 좋다. 3.3.6 BETWEEN을 IN-List로 전환 선행 조건이 BETWEEN으로 비효율이 발생할 때 In-List로 바꿔주면 큰 효과를 얻을 수도 있다. 이때 주의 할 점은 IN-List 개수가 많지 않아야 한다.(수직적 탐색이 많아 질 수 있음) 3.3.7 Index Skip Scan 활용 BETWEEN을 IN-List로 변환하는 것 대신 Index Skip Scan을 활용하는 방법도 있다. 3.3.8 IN 조건은 '=' 인가 IN 조건은 '='이 아니다. 3.3.9 BE..

3장 인덱스 튜닝 3.1 테이블 엑세스 최소화 SQL 튜닝은 랜덤I/O를 줄이는 것. 랜던I/O를 최소화 하는 방법을 알아보자. 3.1.1 테이블 랜덤 액세스 아무리 데이터가 많아도 인덱스를 사용하면 금방 조회된다 어쩔때는 테이블 전체를 스캔하는 것보다 인덱스가 더 느릴때도 있다. 왜 그럴까? 이 질문에 대한 대답을 찾아보자. 인덱스를 사용하는 이유는 ROWID(테이블에 있는 레코드를 찾기 위한 주소값)를 얻는데에 있다. 즉 인덱스를 사용하면 데이터가 실제로 있는 물리 주소가 아닌 물리 주소를 찾을 수 있는 주소를 얻는다. 반대로 테이블 Full Scan 시에는 직접적인 물리 주소를 얻기 때문에 위와 같은 문제점들이 나타난다. ROWID 논리적 주소(즉 메모리 주소가 아니다) 디스크 상에서 테이블 레코드..

2장 인덱스 기본 인덱스 구조 및 탐색 데이터를 찾는 두 가지 방법 테이블 전체 스캔 인덱스 이용 온라인 트랜잭션 처리에서는 소량의 데이터를 찾기 때문에 인덱스를 사용하고 인덱스 튜닝이 중요하다 SQL 튜닝은 랜덤 I/O와의 전쟁 인덱스는 대부분 B-Tree 수직적 탐색 : 인덱스 스캔 지점을 찾는 과정 수평적 탐색 : 데이터를 찾는 과정 인덱스는 필터링이 아니다. 결합인덱스를 사용할 때 주의 사항. 인덱스 기본 사용법 색인이 정렬되어 있더라도(인덱스라도) 가공한 값이나 중간값으로는 스캔 시작점을 찾을 수 없다. Index Range Scan 인덱스 컬럼이 가공되면 전체를 스캔할 수 밖에 없다. Index Full Scan 인덱스를 range scan 하기 위한 가장 첫번째 조건은 인덱스 선두 컬럼이 조..

1장 SQL 처리 과정과 I/O 1.1 SQL 파싱과 최적화 SQL : Structured Query Language 구조적 질의 언어 구조적 / 집합적 / 선언적 원하는 결과집합은 구조적/집합적으로 선언 결과집합을 만드는 과정은 절차적 => 프로시저 필요 프로시저를 최적화 하는 것이 옵티마이저 또한 이 과정을 SQL 최적화라고 함 SQL 최적화 SQL 파싱 -> SQL 최적화 SQL 옵티마이저 사용자가에게 전달 받은 쿼리를 실행할 후보군 선정 후보군 중 가장 최저 비용을 나타내는 실행계획 선택 옵티마이저 힌트 자동으로 옵티마이저를 하지만 사용자가 힌트를 주어 의도적으로 다른 실행계획을 선택 할 수 있게 함 SQL 공유 및 재사용 소프트 파싱 / 하드 파싱 캐시되어 있지 않은 경우 SQL 파싱, 최적화,..