Oracle에서 Latch 가 성능 저하의 원인이 아닙니다

mutex나 semaphore는 시스템에서 동기화를 위해서 제공하는 자원(리소스)이고, latch와 lock은 db에서 사

용하는 동기화 기법으로 정리됩니다. latch와 lock을 mutex 또는 semaphore로 구현을 할 수 있습니다.


첫번째 mutex를 보면, 상호배제를 구현하기 위한 동시성 제어 단위이다.

mutex는 단지 어떤 리소스에 대한 권한을 획득/비획득 이라는 2개의 상태로 나뉘어 진다.

가장 쉬운 예로 pthread_mutex_lock / unlock 함수를 들 수 있다.

둘째로 latch라는 개념은 (물론 운영체제와 같은 다른 C/S field에서는 다른 개념으로 사용할 수 있다)

이렇게 표현된다.

"물리적인 대상의 리소스에 대해 짧은 시간동안 권한(읽기/쓰기)를 획득하여 작업하고자 할 경우 사용되는 동시성 제어 단위"

DBMS 입장에서 설명을 하자면, 물리적이라는 의미는 대상이 특정 버퍼 블럭이나, 낮은 수준의 객체에 대한 것이라고 해석될 수 있다.

또한, 짧은 시간동안이라는 것은 상대적인 개념으로서 뒤에 설명될 lock보다 짧다는 것인데, 이 latch의 목적이 가능한한 빠른 연산을 목표로 하고 있기 때문에 짧다라는 표현을 쓴다.

그리고, latch는 mutex와는 달리 모드를 가질 수 있다.

대표적으로 읽기 모드와 쓰기 모드인데, 본인이 알고 있는 범위내에서는 DBMS에서의 latch는 이 두가지의 모드밖에 보지 못했다.

마지막으로 가장 중요한 또 한가지 점은 이 latch는 dead lock이 발생하지 않는다고 가정한다는 것이다.

물론 잘못된 순서로 객체에 latch를 잡는 경우에는 dead lock이 발생할 수 있지만, 이러한 상황은 개발자에 의한 버그이지 원래 latch의 목적과는 상반된다는 것이다.

따라서, latch에서는 dead lock 상황에 대한 해결책도 가지지 않는다. 일반적으로 이러한 목적을 DBMS내부에서 부합하기 위해서 latch의 대상이 되는 객체는 엄격한 순서로 연산이 이루어 지게 되어 있다.

특히, 인덱스나 레코드 페이지에 대한 순서가 어긋나면 DBMS가 정지하는 상황이 발생하고, 개발자는 혹독한 (기초도 모르는!!!) 시련을 겪게 된다.

세번째로, lock은 DBMS 에서 이렇게 표현된다.

"논리적인 대상에 대한 작업시 사용되는 동시성 제어 단위로서 비교적 긴 시간동안 발생하는 연산" 정도로 말할 수 있겠다.

우선 이 논리적인 대상이라는 의미는 단순이 메모리 대상 객체라기 보다는 테이블 혹은 레코드라는 보다 추상적인 의미가 강하고, 또한 lock이 잡히는 길이도 사용자에 의해서 상당히 긴 시간동안 발생할 수 있다.

또한, mutex는 1개, latch는 2개 정도의 모드를 가지는 반면, lock의 경우에는 S,X,IS,IX,SIX,U 등의 다양한 모드로 연산이 발생할 수 있다.

그리고, 이 lock은 dead lock이 발생하는 것을 허용하고, 또한 이러한 dead lock에 대한 내부적인 방지책을 가지고 있다.

가만히 생각해 보면, 너무나도 당연한 이야기인데, 사용자는 어떤 논리적 대상에 대한 lock을 걸 때 순서를 상관하지 않기 때문에 발생한다.

Oracle에서 Latch 가 성능 저하의 원인이 아닙니다. 증상일 뿐이죠.

예를 들어... Library cache 관련된 Latch가 나타날 경우... APP쪽에서 none-bind 를 사용한 SQL이 그만큼 많다거나 그런 원인이구요.

Buffer Cache Chain Latch 라면 뭔가 비효율적인 인덱스를 타거나 대량의 Full Scan을 하는 악성 SQL이 있다는 뜻입니다.