1. latch: shared pool
shared pool 래치는 shared pool 의 기본 메모리 구조인 힙을 보호하는 역할을 한다.
프리 청크를 찾기 위해 프리리스트를 탐색하고, 적절한 청크를 할당하고, 필요한 경우에 프리 청크를 분할(Split) 하는 일련의 작업들은
모두 shared pool 래치를 획득한 후에만 가능하다.
shared pool 래치를 획득하는 과정에서 경합이 발생하면 latch: shared pool 이벤트를 대기한다.
- 동시에 여러 세션이 청크를 할당받아야 하는 경우 하나의 shared pool 래치를 획득하기 위해 경쟁하기 때문에 경합이 발생하게 된다.
- 하드 파싱이 심한 경우 청크를 쪼개는 (Split) 현상이 자주 발생하고 이로 인해 프리리스트에 수많은 작은 크기의 프리 청크들이 붙는 현상이 발생한다.
이런 현상을 shared pool fragmentation
하드 파싱에 의해 shared pool 대기가 증가하는 경우 shared pool 의 크기를 늘려주는 것은 오히려 문제를 악화시킬 뿐이다.
최선의 해결책은 하드파싱이 발생하지 않도록 바인드 변수를 적절히 사용하는 것이다.
단적으로 말하면 이것만이 유일한 해결책이다.
하지만, 불행히도 현재 가동중인 어플리케이션을 수정하는 것은 쉽지 않으며, 의사결정과정에서 강한 저항에 부딪히는 경우가 많다.
다행히 오라클에서는 이러한 문제를 해결할 수 있는 몇가지 길을 열어놓고 있다.
- Shared Pool 의 크기가 큰 경우에는 서프풀로 쪼개서 관리함으로써 shared pool 래치 경합을 줄일 수 있다.
- Shared Pool 의 크기를 줄이고 동시에 dbms_shared_pool 패키지를 이용해 자주 사용하는 객체를 메모리에 상주시키는 것
- Cursor Sharing 기법을 제공한다.
2. latch: library cache
shared pool 래치가 프리 청크를 찾기 위해 프리리스트를 스캔하고, 적절한 청크를 할당하는 작업을 보호한다면,
library cache 래치는 SQL 을 수행하기 위해 Library Cache 메모리 영역을 탐색하고 관리하는 모든 작업을 보호한다.
library cache 경합은 다음과 같은 발생한다.
- 하드파싱이나 소프트파싱이 과다한 경우
- 버전 카운트 (Version count) 가 높은 경우
- SGA 영역의 페이지 아웃 (Page out) 이 발생하는 경우
1) 하드파싱이나 소프트파싱이 과다한 경우
library cache 래치 경합의 경우, 소프트파싱 (즉 바인드 변수를 잘 쓰고 있는 경우) 에서도 발생하기 쉽기 때문에
shared pool 래치 경합보다 훨씬 심각한 문제라고 볼 수 있다.
소프트 파싱에 의해 library cache 래치 경합이 발생하는 경우에 대해서는 크게 두 가지 해결책이 제시되고 있다.
- 첫째, 파싱회수 자체를 줄인다.
- 둘째, SESSION_CACHED_CURSORS 파라미터를 이용한다. 되도록이면 50 이상의 값을 설정하는 것이 바람직하다.
Thomas Kyte 는 세션 커서 캐싱 기능을 "softer soft parse" 라고 부른다.
소프트 파싱 자체의 부담을 줄여주는 파싱 방법이라는 의미로, 매우 적절한 용어라고 생각된다.
2) 버전 카운트 (Version Count) 가 높은 경우
버전 카운트가 높다는 것은 자식 LCO 탐색으로 인해 library cache 를 탐색하는 시간이 그만큼 증가한다는 의미이며
이로 인해 library cache 래치 경합이 증가할 수 있다는 것을 의미한다.
3) SGA 영역의 페이지 아웃 (Page Out) 발생하는 경우
Shared Pool 이 디스크로 페이지 아웃된 경우,
해당 영역에 대한 스캔이 발생할 때 다시 디스크의 내용을 메모리로 불러들이는 과정동안 대기해야 하므로
library cache 래치에 대한 대기시간이 증가할 수 있다.
latch: library cache 대기가 높은 시점에, O/S 에서 스왑 (Swap) 현상이 발생한다면,
페이지 아웃에 의한 성능 저하일 확률이 높다.
OS 별로 오라클에서 SGA 의 페이지 아웃을 방지하는 방법은 다음과 같다.
- HP_UX, AIX : LOCK_SGA 파라미터 값을 TRUE 로 변경한다. (기본값이 FALSE이다)
- SunOS : _USE_ISM 파라미터 값이 TRUE 인지 확인한다. (기본값이 TRUE이다)
3. library cache lock 과 library cache pin
1) library cache lock: Library Cache 객체에 접근하거나 변경할 때 library cache 핸들에 대해 획득하는 락이다.
2) library cache pin: Library Cache 객체에 대한 수행이나 변경시 library cache object (LCO) 에 대해 획득하는 락이다.
관련 성능 이슈 정리
1. library cache lock 과 library cache pin 대기에 의한 성능저하현상은 대부분 부적절한 DDL (create, alter, complie, flush, ...) 에 의해 발생한다.
2. 하드파싱이 왕성한 시스템에서도 library cache pin 대기가 나타날 수 있다.
library cache pin 뿐만 아니라 library cache 와 관련된 대기의 대부분이 과도한 하드파싱에 의해 유발된다.
최선의 해결책은 바인드 변수를 적절히 사용하는 것이며, Cursor sharing 과 같은 기법을 검토할 수 있다.
단, Cursor Sharing 은 충분한 테스트를 통해서만 실제 시스템에 적용할 것을 권장한다.