Latch 에 대해서...

Latch라는건일종의 메모리 잠금입니다.

Library Cache는 한번 파싱된 SQL구문과 실행계획등등을 저장해두는 저장소입니다.

만약... BIND변수를 쓰지 않아서... 매번 하드파싱을 해야한다면... Library Cache에 메모리 공간에 지속적으로 뭔가를 쓰고 지우고하여야 할겁니다. 따라서 Latch가 필요해지지요.

아시다시피... 뭐가 되었든... 잠금을 만나면 고속도로 1차선 막히듯이 시리얼하게 흐르게 되어있습니다. 병목이 생기는거지요.

그래서 Latch 경합이 생기면 그것이 아주 성능에 좋지 않습니다.

단순히 Library Cache의 경우도 Hit Ratio만 가지고 따지는게 아니라...Latch 경합이라든지 이런걸 따져 보게 됩니다.

Latch free event 가 많이 발생하면 CPU츼 성능이 급격히 저하되고 process 가 full 이 난다.

Latch free event 에서도 cache buffers chains 가 주를 이룬다.

이 buffer cache chains latchcocntention은 주로 이 buffer chain에 의하여 관리되는 buffer수가 많거나

hot block(hot buffer)에 의한 경우로 나누어 볼 수 있다, hot블럭은아마 가장 많이 사용하는 Index 이거나

table 일것이다.

Latch라는건 일종의 메모리 Lock의 일종입니다.

우리가 흔히 보는 테이블이나 Row 단위의 잠금이 아니라...

오라클이 내부적으로 사용하는 SGA 메모리상에 걸리는 잠금입니다.

예를 들어... Shared Pool의 Library cache등에 하드파싱이 끝나고 새로운 SQL을 집어넣을 때 (즉, 메모리에 쓰기를 할 때) 잠금을 걸게 됩니다. Buffer cache에서 자주 엑세스하는 블록을 메모리에 올릴 때도 마찬가지로 Latch 가 필요합니다.

일반적으로 오라클 내부적으로 사용되는 잠금으로 유저가 관여할 수가 없으나.... 병목현상을 발견하는데 참고 사항으로 많이 사용합니다. 즉, Library Cache에 Latch 가 많이 발생하면 Bind 변수를 사용하지 않아서 Hard Parsing이 심각하게 일어나는 증거가 될 수 있습니다.

그리고 말씀하신 테이블이나 row단위 잠금은 Latch와는 다른 이야기입니다.

오라클은 다른 DBMS와는 다르게 모든걸 row단위 잠금으로 처리합니다. 타 DBMS는 row단위가 기본이기는 하지만... page나 block 단위로 잠금을 넓히는 경우가 많습니다. 잠금의 범위가 최소화되어야 한다는 관점에서 볼 때 오라클의 row 단위 잠금은 아직까지 타 DBMS가 따라오지 못하는 부분입니다.

잠금 처리에 있어서 더 중요한 것은 오라클은 Select의 경우 잠금이 전혀 일어나지 않는 다는 겁니다. 타 엔진은 select의 경우도 잠금이 걸려서 동시성을 저해하는 경우가 비일비재합니다. 이것도 오라클이 우수한 이유중의 하나입니다.

요약하면 오라클은 ROW단위 잠금을 완벽히 지원하고, SELECT의 경우 잠금을 일으키지 않습니다. 타 엔진은 잠금이 비싼 작업이므로 가급적 빨리 트랜잭션을 끝내야 하나... 오라클의 경우는 반드시 그렇지는 않습니다. (즉, 오라클은 commit을 자주 해줄 필요가 없습니다. 자주하면 더 느려집니다. 트랜잭션이 완결되었을 때 한번만 해주면 됩니다.)

잠금이 걸리는 이유는... DML 이 들어올 경우 즉, 트랜잭션이 발생하였을 경우에 생기고...

select ... for update나 .... lock table 등을 통해 명시적으로 잠금을 걸 수도 있습니다.