1장 SQL 처리 과정과 I/O
1.1 SQL 파싱과 최적화
- SQL : Structured Query Language
- 구조적 질의 언어
- 구조적 / 집합적 / 선언적
- 원하는 결과집합은 구조적/집합적으로 선언
- 결과집합을 만드는 과정은 절차적 => 프로시저 필요
- 프로시저를 최적화 하는 것이 옵티마이저
- 또한 이 과정을 SQL 최적화라고 함
- SQL 최적화
- SQL 파싱 -> SQL 최적화
- SQL 옵티마이저
- 사용자가에게 전달 받은 쿼리를 실행할 후보군 선정
- 후보군 중 가장 최저 비용을 나타내는 실행계획 선택
- 옵티마이저 힌트
- 자동으로 옵티마이저를 하지만 사용자가 힌트를 주어 의도적으로 다른 실행계획을 선택 할 수 있게 함
SQL 공유 및 재사용
- 소프트 파싱 / 하드 파싱
- 캐시되어 있지 않은 경우 SQL 파싱, 최적화, 로우 소스 생성 등을 거쳐 내부 프로시저를 생성하는데 이를 하드 파싱이라 하고 캐시된 하드 파싱을 바로 찾아 쓰는 것을 소프트 파싱이라 한다.
- 바인드 변수의 중요성
- SQL은 전체가 하나의 이름이 된다. 따라서 이름을 따로 만들 필요가 없다
- 따라서, 바인드 변수를 프로그래밍적으로 하드 코딩 하게 되면 그 수만큼 캐싱되어 쌓이게 되는 문제가 발생한다.
데이터 저장 구조 및 I/O 메커니즘
- SQL이 느린 이유
- I/O는 매우 느리다.
- 쿼리를 빠르게 하기 위해서는 I/O를 줄이고 프로세서가 일어나서 동작하는 시간을 최대한 늘여야한다.
- 데이터베이스 저장 구조
- 테이블스페이스 > 세그먼트 > 익스텐트 > 블록
- 익스텐트 단위로 공간 확장
- 실제 데이터는 블록에 저장
- 한 블록은 같은 테이블 저장
- 한 익스텐트는 같은 테이블 저장
I/O는 블록 단위로 이루어진다
액세스 방식
- 시퀀셜
- 연결된 순서대로 차례대로 읽는다
- 인덱스 리프 블록 읽을 때
- 테이블 블록 읽을 때(Full Table Scan)
- 랜덤
- 논리적, 물리적 순서를 따르지 않고 레코드 하나를 읽기 위해 한 블록씩 접근
- 시퀀셜
논리적 I/O vs 물리적 I/O
- DB 버퍼 캐시 : 디스크에서 읽은 데이터 블록의 캐시
- 라이브러리 캐시: SQL/ 실행계획/ 프로시저를 저장한 캐시
- 논리적 I/O : 읽어야 하는 총 블록
- 물리적 I/O : 읽어야 하는 총 블록 중 디스크에서 읽어 온 블록
- BCHR(Buffer Cache hit Ratio)
- 논리적 I/O 중 물리적 I/O를 제외하고 DB 버퍼 캐시에서 읽어 온 비율
- 논리적 I/O 를 줄이는 것이 성능을 올리는 방법
SQL 튜닝은 결국 논리적 I/O를 줄이는 것
싱글 블록 I/O vs 멀티 I/O
- 싱글 블록 I/O
- 한번에 하나의 블록만 읽는 것
- 인덱스 읽을 때
- 멀티 블록 I/O
- 데이터 블록 읽을 때
- 싱글 블록 I/O
- Table Full Scan vs Index Range Scan
- Table Full Scan
- 데이터 전체를 스캔해서 읽는 것
- Index Range Scan
- 인덱스를 이용한 테이블 액세스
- 두 가지 방식을 적절하게 사용하는 것이 중요
- Table Full Scan
- 캐시 탐색 메커니즘
- 메모리 버퍼 캐시 탐색 시 해시 알고리즘 사용
- 메모리 버퍼 캐시는 SGA 구성요소 이기 때문에 공유 자원
- 따라서 동시성 관리 필요
- 내부적으로 동시에 접근 불가하고 순차적으로 접근함(직렬화)
- 줄서기 담당이 래치(Latch)
'친절한SQL튜닝' 카테고리의 다른 글
5장 소트 튜닝 (0) | 2022.03.31 |
---|---|
4.4장 서브쿼리 조인 (0) | 2022.03.31 |
3장 인덱스 튜닝 (2) (0) | 2022.03.31 |
3장 인덱스 튜닝 (1) (0) | 2022.03.31 |
2장 인덱스 기본 (0) | 2022.03.31 |