① SQL파싱
사용자로부터 SQL을 전달받으면 가장 먼저 SQL 파서가 파싱을 진행
② SQL최적화
옵티마이저가 SQL 최적화를 맡는다. (가장 효율적인 실행경로 선택)
③ 로우 소스 생성
SQL 옵티마이저가 선택한 실행경로를 실행 가능한 코드 또는 프로시저 형태로 포맷팅하는 단계
SQL 옵티마이저 : 사용자가 원하는 작업을 가장 효율적으로 수행할 수 있는 최적의 데이터 엑세스 경로를 선택해주는 DBMS의 핵심 엔진
최적화 단계는 다음과 같다.
- 사용자로부터 전달받은 쿼리를 수행하는 데 후보군이 될만한 실행계획들을 찾아낸다.
- 데이터 딕셔너리에 미리 수집해 둔 오브젝트 통계 및 시스템 통계정보를 이용해 각 실행계획의 예상비용 산정한다.
- 최저 비용을 나타내는 실행계획을 선택한다.
책에서 SQL 옵티마이저를 자동차 네비게이션과 유사하다고 표현한다.
네비게이션이 제공하는 도착 예상시간이 예상시간이듯,
SQL 실행계획에 표시되는 Cost도 예상치이다. (여러 통계정보를 활용하여 계산해낸 값)
네비게이션이 항상 최적의 경로를 선택을 하듯,
SQL 옵티마이저도 대부분 좋은 선택을 하지만 완벽하지 않다.
개발자가 '옵티마이저 힌트'를 통해 데이터 액세스 경로를 바꿀 수 있다.
자주사용하는 힌트 목록들이 책에 소개되어 있다.
라이브러리 캐시
사용자가 SQL 문 전달 > DBMS는 SQL 파싱 후, 해당 SQL이 라이브러리 캐시에 존재하는지 확인 >
캐시에 존재 ? 곧바로 실행 단계 : 최적화 단계
SQL을 캐시에서 찾아 곧바로 실행 단계로 넘어가는 것을 소프트 파싱,
찾이 못해 최적화 및 로우 소스 생성까지 모두 거치는 것을 하드 파싱
SQL최적화 과정은 하드하다. (최적화 과정에 엄청난 연산이 필요하기 때문)
이러한 최적화 과정을 거쳐 생성된 내부 프로시저를 한 번 사용하고 버리면 ? 아깝다.
이것이 라이브러리 캐시가 필요한 이유이다.
바인드 변수를 잘 사용하면 하드파싱을 최초 한번만 하고, 캐싱된 SQL을 수없이 재사용할 수 있다.
십중팔구 I/O 때문 (디스크 I/O)
프로세스가 디스크에서 데이터를 읽어야하면 waiting 상태에서 I/O가 완료되기를 기다린다.
이 때, 여러 프로세스가에 의해 동시에 I/O Call 발생하면 대기시간도 늘어난다. (디스크에서 데이터를 읽어와야 하는데 오래 걸린다)
데이터를 저장하려면 먼저 테이블스페이스를 생성해야 한다.
테이블스페이스는 세그먼트를 담는 컨테이너로써, 여러개의 데이터파일로 구성된다.
세그먼트는 테이블, 인덱스처럼 저장공간이 필요한 오브젝트이다.
세그먼트는 여러개의 익스텐트로 구성된다.
?
아직 이해가 잘 안됐다.
사용자가 입력한 레코드를 실제로 저장하는 공간은 데이터 블록이다.
블록이 DBMS가 데이터를 읽고 쓰는 단위이다.
테이블이나 인덱스 블록을 엑세스하는 방식 : 시퀀셜 엑세스, 랜덤 엑세스
아직 뒤에는 이해가 안된듯.. 그냥 책내용 고대로 적게된다..
추후에 완성하기 ..