aDBanced Team

Parse Call을 제외하고 SQL 수행 중에 발생하는 Execute Call, Fetch Call을 줄이는 방법에 대해 설명하고, 데이터베이스 Call을 User Call과 Recursive Call로 나누어 각각을 최소화하는 원리와 방안에 대해서 설명 합니다. Call 통계select * from emp; call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.01 0.03 0 0 0 0 Execute 1 0.00 0.01 0 0 0 0 Fetch 2 0.00 0.00 0 8 0 14 ------- ------ -..

Cardinality는 집합 안의 원소 개수, 오라클의 경우는 예측 Row 수라고 할 수 있습니다. 옵티마이저가 실행계획을 세우는 데 있어서 가장 중요한 것은 정확한 Cardinality의 계산이며, 동시에 그것은 실행계획이 비효율적인 가장 큰 원인이기도 합니다. 아래 실습은 기본적인 테이블을 생성 후에 ANALYZE TABLE을 하면 통계정보가 생성되며, 이후 Cardinality를 확인하는 방법과 Histogram에 따라서 정확한 값을 예측 불가능 하다는 것을 확인해보도록 하겠습니다. 즉, Histogram을 사용하지 않도록 설정합니다. Cardinality의 기본적인 개념을 먼저 파악하겠습니다. 1. Base Cardinality Base Cardinality란 Table의 전체 Row 수를 의미합..

1. 바인드 변수의 부작용과 해법1.1. 바인드 변수 사용 시 - 최초 수행 시 : 최적화를 거친 실행계획을 캐시에 적재(하드 파싱) - 실행 시점 : 캐시의 실행계획을 그대로 가져와 값을 다르게 바인딩하면서 반복 재사용(소프트파싱) - 바인딩 시점 (최적화 이후인 실행시점) - SQL 최적화 시점에 조건절 컬럼의 데이터 분포도(컬럼 히스토그램) 활용을 못함(부작용) - 옵티마이저는 평균 분포를 가정한 실행계획을 생성 - 컬럼의 데이터 분포가 균일 시 문제가 없음, 그렇지 않을 시 시행 시점에 바인딩 되는 값에 따라 최적이 아닌 실행계획 수행가능(부작용) - 등치(=) 조건이 아닌 부등호나 범위기반 검색 조건 시 고정 된 규칙을 사용하여 더 부정확한 예측의 실행계획 생성가능(부작용) 1.2 바인딩 변수 ..