- row cache lock
닥셔너리의 내용을 변경하고자 하는 프로세스는 그에 해당하는 row cache object에 대해서 row cache lock을 획 득해야 한다 대표적인 경우가 시퀀스인데, 시퀀스의 nextval을 획득하는 과정에서 딕셔너리 정보의 변경이 필요한 경우에 시퀀스에 해당하는 row cache object에 대해서 row cache lock을 SSX(Shared Sub-Exclusive) 모드로 획득해야 한다. SSX 모드 간에는 상호 호환성이 없으므로 동시에 많은 프로세스가 동일 시퀀스에 대해 nextval을 호출하는 경우 row cache lock에 대한 경합이 발생한다. Row cache lock을 획득하는 과정에서 경합이 발생하면 row cache lock 이벤트를 대기하게 된다.
Row cache lock은 Enqueue 구조를 사용하지 않으며 row cache object 정보 안에 존재하는 락 보유목록(Owner list) 과 락 대기 목록(Waiter list)을 통해서 블로킹 메커니즘을 구현한다. V$ROWCACHE 뷰와 V$ROWCACHE_PARENT 뷰를 이용하면 row cache에서의 경합에 대한 분석 이 가능하다 V$ROWCACHE 뷰는 개별 row cache object가 아닌 row cache 전체(종류)의 활동성에 대한 통계정보를 제공한다. V$ROWCACHE_PARENT 뷰를 이용하면 실제 개별 row cache object의 활동성을 파악할 수 있다. 하지만 정확하게 어떤 row cache object가 문제가 되는지를 파악하기 어렵다.
row cache 덤프를 이용하면 실제 객체에 대한 정보까지 얻을 수 있다. 캐시 (Cache) 속성을 부여하지 않은 시퀀스를 동시에 많은 프로세스가 사용하는 경우 row cache lock 이벤트 대기가 광범위하게 발생할 수 있다. 캐시를 사용하지 않은 시퀀스에 대해 nextval을 호출하면 매번 딕셔너리 정보가 변경되어야 하기 때문에 row cache lock을 SSX모드로 획득해야 한다. SSX모드 간에는 상호 호환성이 없기 때문에 이 과정에서 경합이 발생하게 된다. 캐시 속성을 부여한 시퀀스에서는 row cache lock 경합에 의한 성능문제는 생기지 않는다. 캐시 크기가 작게 설정된 경우에는 SQ 락에 의한 경합이 발생할 수 있는다.
- enq: SQ - contention, DFS lock handle(SV)
시퀀스를 관리하기 위해서 세 가지의 락을 사용한다.
1) row cache lock: Sequence.nextval을 호출하는 과정에서 딕셔너리 정보를 물리적으로 변경하는 경우에 획득한다. NOCACHE 속성올 부여한 시퀀스에서 사용된다.
2) SQ 락: 메모리에 캐시되어 있는 범위 안에서 Sequence.nextval을 호출하는 동안 획득한다. CACHE 속성을 부여만 시퀀스에서 사용된다.
3) SV 락: RAC에서 노드 간에 순서가 보장된 상태로 Sequence.nextval을 호출하는 동안 획득한다. CACHE + ORDER 속성을 부여인 시퀀스에서 사용된다. SQ 락 경합에 의한 성능 문제는 CACHE 속성을 크게 해주는 것으로 문제를 해결할 수 있다. 한꺼번에 많은 세션이 동시에 접속하는 경우에는 SYS.AUDSES$ 시퀀스의 캐시 크기를 10000 정도로 크게 늘림으로써 enq: SQ - contention 대기문제를 해결할 수 있다. SV 락을 획득하는 과정에서 경합이 발생할 경우에는 row cache lock 이벤트나 enq: SQ - contention 이벤트와는 전혀 다른 DFS lock handle이라는 이름의 이벤트를 대기하게 된다. 따라서 가능하면 CACHE + NOORDER 속성을 부여하고 충분한 크기의 캐시 크기를 부여하는 것이 바람직하다.