CH1.오라클 아키텍처 - 10.대기 이벤트, 11. Shared Pool

10. 대기이벤트

(1) 대기이벤트란?
오라클 인스턴드로 조직화된 분업사회처럼 많은 프로세스(또는 쓰레드)들이 역할을 분담해서 각자 맡은 바 임무를 수행합니다. 함께 일을 하는 동안 프로세스 간 커뮤니케이션과 상호작용이 필요하고 떄로는 다른 프로세스가 일을 마칠때까지 기다려야하는 상황이 발생되기도 합니다. 그러면 오라클 프로세스는 일을 계속 진행할 수 있는 조건이 충족될 때까지 수면상태에 빠지는데 이것을 대기이벤트라고 합니다. 그때마다 오라클은 그 상태정보를 파일 또는 SGA메모리 내에 저장해둡니다. 처음 7.0버전에서 100여개 남짓하던것이 11g에는 960개가 넘는 대기이벤트가 정의되어 있습니다.

(2) 대기 이벤트는 언제 발생할까요?
크게 세가지로 요약할 수 있습니다.
1. 자신이 필요로 하는 특정 리소스가 다른 프로세스에 의해 사용중일때
예를들어 자신이 읽으려는 버퍼에 다른 프로세스가 쓰기 작업을 진행 중이라면 선행프로세스가 일을 마칠때까지 기다려야 합니다. buffer busy waits, latch free, enqueue 관련 대기이벤트가 여기에 속합니다.
2. 다른 프로세스에 의해 선행작업이 완료되기를 기다릴때
예를들어 DBWR프로세스가 dirty버퍼를 디스크에 기록할때는 먼저 LGWR프로레스가 로그버퍼에 있는 redo entry를 로그파일에 내려쓰는 작업이 선행되어야 합니다. 따라서 DBWR프로세스는 LGWR의 작업이 마칠때까지 수면상태에서 휴식을 취하는 것입니다. write complete waits, chekpoint completed, log file sync, log file switch 이벤트등이 여기에 속합니다.
3.할일이 없을때(idle)
예를들어 서버 프로세스는 쿼리 결과를 사용자에게 전송하는 동안 array단위로 일을 처리하는데 array크기 만큼 데이터를 전송하면 다음 fetch call을 받을때까지 기다립니다. 쿼리 집합 결과를 모두 전송하고 나서도 다음 parse call 또는 execute call을 받을 때까지 기다립니다. sql*net message from client , PX Deq : execution Msg 등이 여기에 속합니다.

(3) 대기이벤트는 언제 사라질까요?
선헹 프로세스가 일정시간이 되면 한번씩 깨어나 자신이 기다리던 리소스가 사용 가능해졌거나 해야 할 일이 생겻는지 확인합니다. 타임아웃 설정값은 대기 이벤트마다 모두 다릅니다. 예를들어 DBWR LGWR간 상호작용에 의한 대기 이벤트 발생 시 타임아웃은 3초로 설정됩니다. 타임아웃에 의해 깨어났는데 리소스가 아직 사용 중이거나 선행 프로세스가 일을 마치지 못했다면 다시 수면 상태로 빠집니다. 대기가 자주 발생하는 것도 문제지만 타임아웃이 자주 발생한다면 대기 이벤트에 의한 지연시간이 길어지는 것이므로 문제로 받아 들여야 합니다.

(4) 래치와 대기 이벤트 개념 명확화
래치는 얻는 과정자체가 경합을 의미하지 않습니다. 공유된 자원을 읽으려면 래치는 얻는 것이 당연한 일이므로 v$latch뷰에서 gets 횟수가 증가한다고 해서 문제될 것은 없으며 공유자원에 대한 접근 요청이 많았던 것으로 이해하면 됩니다.
v$latch 뷰의 컬럼들에 대한 설명입니다.
gets : 래치 요청 횟수
misses : 래치를 요청했는데 다른 프로세스에 의해 자원이 사용 중이어서 첫번째 시도에서 곧바로 래치를 얻지 못한 횟수
래치 miss를 만난 프로세스는 이후 spin과정에서 래치 획득에 성공하거나 spin이후에도 획득에 실패해서 대기상태에 가는 둘 중하나가 됩니다.
spin gets : 래치를 요청한 첫 번째 시도에서 곧바로 래치를 얻지는 못했지만 spin하는 과정에서 래치 획득에 성공한 횟수 sleep 전에 래치를 얻는 경우입니다.
sleeps: 첫 번째에서 얻지 못해 정해진 횟수만큼 spin 했는데도 결국 래치를 얻지 못해 대기 상태로 빠진 횟수. 이때 발생하는 것이 latch free대기 이벤트입니다.
래치는 우선권이 따로 있지 않기때문에 래치 획득에 성공할 때까지 반복적인 액세스 시도만 있을 뿐입니다. 따라서 가장 먼저 래치를 요구했던 프로세스가 가장 늦게 래치를 얻을 수 있습니다.

11.Shared Pool

(1) 딕셔너리 캐시
오라클 딕셔너리 정보를 저장해두는 캐시영역입니다. row단위로 읽고 쓰기 때문에 로우 캐시라고도 불립니다. 테이블, 인덱스 같은 오브젝트는 물론 테이블스페이스, 데이터파일, 세그먼트, 익스텐트, 제약사항,시퀀스, db link에 관한 정보들을 캐싱합니다. 예를들어 사용자가 시퀀스 객체를 하나 만들면 오라클 딕셔너리에 저장되고 로우 캐시를 거져 읽고 쓰기가 이루어집니다. 사용자가 시퀀스로 부터 새로운 값을 인출하기 위해 nextval을 호출할 때마다 로우 캐시를 통해 update가 이루어집니다. 잦은 시퀀스 사용은 로우 캐시 경합을 발생시킬 수 있으며 cache 옵션을 부여해서 해소할 수 있습니다. 20이면 nocache보다 로우 캐시를 갱신하는 횟수가 1/20으로 줄어듭니다.
v$rowcache뷰로 딕셔너리 캐시에 대한 활동성의 통계를 조회할 수 있습니다.

(2) 라이브러리 캐시
사용자가 던진 SQL과 그 실행계획을 저장해두는 캐시영역입니다. 사용자가 SQL을 통해 결과집합을 요청하면 이를 최적으로 수행하기 위한 처리 루틴이 필요한데 이를 실행계획이라고 합니다. 쿼리 구문을 분석해서 문법 오류 및 실행 권한을 체크하고 최적화 과정을 거쳐 실행계획을 만들고 SQL 실행엔진이 이해할 수 있는 형태로 포맷팅하는 전 과정을 하드 파싱이라고 합니다. 최적화는 하드 파싱을 무겁게 만드는 결정적 요인이고 같은 SQL에 대한 반복적인 하드 파싱을 최소화하기 위해 라이브러리 캐시가 생겨났습니다.