Library Cache Latch
우선 library cache latch에 대해 알아보면 이 latch는 library cache영역을 탐색하고 관리하는 모든 작업을 보호하는 데에 그 목적이 있다.
latch의 수는 일반적으로 shared pool latch의 수 보다는 많다. 왜냐하면 CPU개수보다 큰 소수 중 가장 작은 소수로 설정되어 있기 때문이다. 이 때문에 library cache latch를 획득하려는 프로세스가 CPU개수 보다 적다면 library cache latch 자원은 손쉽게 획득하는 대신에 shared pool latch를 가지고 경합할 확률이 높을 것이고 library cache latch의 개수보다 많은 프로세스가 획득하려 한다면 library cache latch를 가지고 경합을 하느라 shared pool latch의 경합은 상대적으로 줄어들 수 있다.
그렇다면 이러한 library cache latch 경합을 가중시키는 작업엔 어떤것이 있을까?
바로 hard parsing이나 soft parsing이 과다한 경우라 자식 LCO가 많아 anonymous list의 탐색시간이 증가하는 경우이다. 그리고 SGA영역이 page out되는 극히 드문 경우를 예로 들어 볼 수 있다.
이에 대한 해결책으로 PL/SQL block내에서 자주 실행되는 SQL에 대해서는 Static SQL을 사용하면 된다.
LCO를 pin하여 soft parsing없이도 cursor를 계속 재사용 할 수 있는 효과를 볼 수 있다.
그리고 SESSION_CACHED_CURSORS Parameter를 이용하여 3회 이상 수행된 SQL에 대해서는 PGA영역에 cursor의 주소값과 SQL text를 저장하여 cursor 탐색시 성능향상을 기대할 수 있다(library cache latch도 획득해야 하고 soft parsion도 발생하지만 library 탐색시간이 매우 짧기 때문에 성능향상이 된다).
하지만 application에서 SQL 수행시 마다 log on/off하는 경우 이 parameter는 세션이 끊어지면 소용이 없기 때문에 성능 향상을 기대하기 어렵다. 때문에 connection pool을 함께 이용하는 것이 현명한 방법이다.
그리고 마지막으로 SGA영역의 page out의 경우는 잘 발생하지 않지만 만약을 대비하여 LOCK_SGA값을 TRUE로 하여 고정시켜 놓는것이 좋다.
Library Cache Lock
library cache lock(관련 뷰: X$KGLLK 10g-DBA_DDL_LOCKS,DBA_KGLLOCK)에 대해 설명하면 이것은 handle에 대해 획득하년 lock이라 볼 수 있다.
이것의 목적은 동일 object의 접근 및 수정에 대해 다른 client들로부터 예방하는 것이다.
Lock은 3가지 모드를 갖게 되는데 shared,exclusive,null mode가 있다
shared로 획득하는 경우는 parsing과 실행단계이고 exclusive는 procedure생성이나 변경의 경우, recompile시와 table 변경의 경우가 있다. null mode는 보통 실행후에 참조하는 객체에 대해 null mode로 lock를 소유하게 된다.
Library Cache Pin
관련뷰 : X$KGLPN 10g-DBA_KGLLOCK
Heap Data에 pin을 꽂아 변경되지 않도록 보장하는데 그 목적이 있다.
이것은 반드시 library cache lock을 획득한 후에 획득해야 한다. 이것은 shared와 exclusive의 두 모드가 지원되며 이렇게 획득하는 경우를 살펴보면, shared mode로 획득하는 경우는 Heap Data를 읽을때 pin을 걸어 object들의 변경을 예방하며 exclusive mode로 획득하는 경우는 Heap Data를 수정할때이다.
Heap Data를 수정하는 경우는 procudure recompile이나 hard parsion 발생 시 excution plan을 세우는 과정에서 참조하는 LCO가 변경되면 안되기 때문에 pin을 걸어 보호한다.
이때 발생하는 library cache lock이나 library cache pin은 V$SESSION_WAIT의 P1,P2,P3 column과 X$KGLOB 뷰를 이용하여 object정보를 구할 수 있다.
P1 = handle address
P2 = lock address
P3 = mode * 100 + namespace(lock mode:1=null, 2= shared, 3=exclusive) 이기 때문에 V$SESSION_WAIT 를 조회하여 P1값을 구한 후 P1과 X$KGLOB의 kglhdadr column과 비교하여 kglnaobj column을 query해서 object의 이름을 구할 수 있다.
우선 library cache latch에 대해 알아보면 이 latch는 library cache영역을 탐색하고 관리하는 모든 작업을 보호하는 데에 그 목적이 있다.
latch의 수는 일반적으로 shared pool latch의 수 보다는 많다. 왜냐하면 CPU개수보다 큰 소수 중 가장 작은 소수로 설정되어 있기 때문이다. 이 때문에 library cache latch를 획득하려는 프로세스가 CPU개수 보다 적다면 library cache latch 자원은 손쉽게 획득하는 대신에 shared pool latch를 가지고 경합할 확률이 높을 것이고 library cache latch의 개수보다 많은 프로세스가 획득하려 한다면 library cache latch를 가지고 경합을 하느라 shared pool latch의 경합은 상대적으로 줄어들 수 있다.
그렇다면 이러한 library cache latch 경합을 가중시키는 작업엔 어떤것이 있을까?
바로 hard parsing이나 soft parsing이 과다한 경우라 자식 LCO가 많아 anonymous list의 탐색시간이 증가하는 경우이다. 그리고 SGA영역이 page out되는 극히 드문 경우를 예로 들어 볼 수 있다.
이에 대한 해결책으로 PL/SQL block내에서 자주 실행되는 SQL에 대해서는 Static SQL을 사용하면 된다.
LCO를 pin하여 soft parsing없이도 cursor를 계속 재사용 할 수 있는 효과를 볼 수 있다.
그리고 SESSION_CACHED_CURSORS Parameter를 이용하여 3회 이상 수행된 SQL에 대해서는 PGA영역에 cursor의 주소값과 SQL text를 저장하여 cursor 탐색시 성능향상을 기대할 수 있다(library cache latch도 획득해야 하고 soft parsion도 발생하지만 library 탐색시간이 매우 짧기 때문에 성능향상이 된다).
하지만 application에서 SQL 수행시 마다 log on/off하는 경우 이 parameter는 세션이 끊어지면 소용이 없기 때문에 성능 향상을 기대하기 어렵다. 때문에 connection pool을 함께 이용하는 것이 현명한 방법이다.
그리고 마지막으로 SGA영역의 page out의 경우는 잘 발생하지 않지만 만약을 대비하여 LOCK_SGA값을 TRUE로 하여 고정시켜 놓는것이 좋다.
Library Cache Lock
library cache lock(관련 뷰: X$KGLLK 10g-DBA_DDL_LOCKS,DBA_KGLLOCK)에 대해 설명하면 이것은 handle에 대해 획득하년 lock이라 볼 수 있다.
이것의 목적은 동일 object의 접근 및 수정에 대해 다른 client들로부터 예방하는 것이다.
Lock은 3가지 모드를 갖게 되는데 shared,exclusive,null mode가 있다
shared로 획득하는 경우는 parsing과 실행단계이고 exclusive는 procedure생성이나 변경의 경우, recompile시와 table 변경의 경우가 있다. null mode는 보통 실행후에 참조하는 객체에 대해 null mode로 lock를 소유하게 된다.
Library Cache Pin
관련뷰 : X$KGLPN 10g-DBA_KGLLOCK
Heap Data에 pin을 꽂아 변경되지 않도록 보장하는데 그 목적이 있다.
이것은 반드시 library cache lock을 획득한 후에 획득해야 한다. 이것은 shared와 exclusive의 두 모드가 지원되며 이렇게 획득하는 경우를 살펴보면, shared mode로 획득하는 경우는 Heap Data를 읽을때 pin을 걸어 object들의 변경을 예방하며 exclusive mode로 획득하는 경우는 Heap Data를 수정할때이다.
Heap Data를 수정하는 경우는 procudure recompile이나 hard parsion 발생 시 excution plan을 세우는 과정에서 참조하는 LCO가 변경되면 안되기 때문에 pin을 걸어 보호한다.
이때 발생하는 library cache lock이나 library cache pin은 V$SESSION_WAIT의 P1,P2,P3 column과 X$KGLOB 뷰를 이용하여 object정보를 구할 수 있다.
P1 = handle address
P2 = lock address
P3 = mode * 100 + namespace(lock mode:1=null, 2= shared, 3=exclusive) 이기 때문에 V$SESSION_WAIT 를 조회하여 P1값을 구한 후 P1과 X$KGLOB의 kglhdadr column과 비교하여 kglnaobj column을 query해서 object의 이름을 구할 수 있다.