2024년 2월 2일 3교시 select 문의 처리단계 3. execute

라이브러리 캐시 락 library cache lock (exclusive): 건물을 아직 다 올리지 않았는데 안에 들어가려고 해서 발생하는 오류

라이브러리 캐시 핀 library cache pin: 인테리어 공사를 하는데 끝나기도 전에 집이 어떤지를 보려고 해서 발생하는 오류

 

3. execute

- 라이브러리 캐시 락 library cache lock 과 라이브러리 캐시 핀 library cache pin 을

  쉐어드 shared 모드로 바꿔놓고 SQL 문을 실행한다.

-  LCO 도 그 안의 실행 계획도 다 만들어진 상태에서,

  현재 LCO 의 라이브러리 캐시 핀을 exclusive 로 바꿔야 하는 경우 = 테이블이 변경되거나 drop 되는 경우

- LCO 를 shared 모드로 잡고 execute 작업 중인데

   다른 세션에서 변경사항 때문에 exclusive 로 작업이 일어나야 하는 경우에

   library cache lock 웨이트 이벤트가 발생한다. (exclusive 작업하려는 쪽에 대기 발생)

- 실행 계획이 바뀌는 경우: 테이블에 인덱스가 만들어지는 경우 / 컬럼이 추가되는 경우

  이 경우 그 테이블과 관련된 모든 실행 계획은 무효화된다.

- 실행 계획을 만들기 위해서는 테이블의 통계 정보를 수집해야 한다.

- execute 단계에서 블록 I/O가 발생한다. (DBC 로 액세스)

- DBC 로 액세스 > 내가 필요로 하는 정보를 cursor 에 담음 = 여기까지가 execute

  (자세한 내용은 다음 주 월요일에 설명해주실 예정, 그날은 DBC 에 대해 배운다.)

 

왜 execute 단계에서 shared 모드로 핀을 찍을까?

실행계획이 어긋나면 안되기 때문에.

실행계획을 통해 블록 I/O 를 일으키고 있는데 다른 세션에서 통계 수집을 해서

LCO에 핀이 exclusive 모드로 찍히면 안되므로

execute 가 끝날 때까지는 무조건 shared 모드로 핀이 찍혀있게 된다.

 

유저에게 전달할 active set 결과를 커서에 다 담았으면

fetch 가 돌아가는데

fetch 시점에 라이브러리 캐시 락은 null 모드로 바뀌고

라이브러리 캐시 핀은 해지된다.

 

4. fetch

- 액티브 셋 결과 (select 문장의 결과) 를 유저 프로세스에 전달하는 것