Latch의 발생과 경합의 원인

OracleRDBMS에선 여러가지 Lock 메커니즘을 사용하고 있다.

주로 다음과 같은 것들이 있다.

 

　・Latch
　・엔큐

　・분산 Lock

　・글로벌 Lock (OPS/RAC)

 

이 문서에서는 이것들 중에서도 Latch에 중점을 두고 기술합니다.

OracleRDBMS에 있어서 Latch의 실상과 Latch경합의 원인에 대해 설명함으로써 각각의 경합의 튜닝을 할수 있습니다.

 

1. Latch란???

Latch란 SGA안에 공유 데이터 구성을 보호하는 저레벨의 직렬화 메커니즘이다. Latch의 실상은 플랫폼에 따라 다르다. Latch은 획득 및 해방이 단시간의 행해지는 종류의 락입니다. Latch는 통상 복수의 프로세스가 같은 처리를 동시에 실행 하는 일을 방지하기 위해서 사용됩니다. Latch를 보관 유지하고 있는 프로세스가 이상종료(ABEND)했을 경우 각 Latch 관련된 크린업 프로시져에 의해 해방된다. Latch에는 데드락이 발생하지 않게 하기 위한 레벨이 관련되어 있습니다. 프로세스가 어떤 레벨의 Latch을 획득하면 그것을 보관한 상태로 그 이하 레벨의 Latch를 요구할 수가 없습니다.

 

2. Latch와 엔큐

엔큐는 Latch와는 다른 락  메카니즘입니다. 엔큐는 동시에 복수의 프로세스가 여러가지 방법으로 자원을 공유하는 일을 가능하게 합니다. Latch와 비교해 정교한 메카니즘입니다. 엔큐의 대표적인 예는 테이블에 대한 락입니다. 1개의 테이블에 대해 복수의 프로세스가 공유 모드나 공유행 배타 모드등에서 동시에 락을 획득할 수 있습니다. 엔큐를 요구했을 때 요구하는 락 모드가 이미 그 자원에 대해서 다른 세션이 취득하고 있는 락 모드와 호환성이 없는 경우 나중에 락을 요구한 프로세스는 대기 하게 됩니다만, 그 경우는 FIFO(First-In-First-Out)의 큐 대기라 합니다.

 

Oracle8i까지의 버젼에서는 대부분의 Latch에 대해 획득을 대기할 때에 대기하는 프로세스가 어떤 간격으로 sleeve와 리트라이를 반복하는 구조로 되어 있었습니다. 복수의 프로세스가 같은 Latch를 대기하고 있는 경우 해방 후에 최초로 리트라이를 한 프로세스에 획득이 허가되므로 엔큐와 같이  FIFO로의 획득은 보증되지 않습니다.

Oracle9i 이후의 버젼에서는 대부분의 Latch가 큐를 사용한 대기를 실시하도록 변경되었기 때문에 엔큐와 같게 FIFO로의 획득이 보증됩니다. 다만 각 버젼 모두 일부의 Latch로 예외적인 대기 방법을 취하는 경우가 있습니다.

 

3. Latch을 획득할 필요가 있는 케이스

SGA내의 자원을 사용할 때 프로세스는 Latch를 획득해 자원을 사용하는 동안은 Latch를 계속 보관 유지해 자원의 사용을 끝내면 Latch은 해방됩니다. 각 Latch은 Latch명에 의해 식별되어 각각이 다른 자원을 보호합니다. Latch의 조작은"test and set"등의 atomic인 명령으로 실시합니다. 다른 프로세스가 획득한 Latch에 의해 보호되는 코드를 실행하기 위해서는 그 Latch이 해방될 때까지 대기할 필요가 있습니다. 예를 들면, redo allocation, redo copy, archive control등의 Latch에 의해서 로그·버퍼나 어카이브(archive)처등의 공유되는 데이터 구조에의 동시 액세스를 막을 수 있습니다.

Latch의 획득이나 해방이 atomic인 명령으로 행해지기 때문에 1개의 프로세스만이 Latch을 획득 하는 것이 보증되어 획득/해방도 고속으로 실행됩니다. Latch을 획득하고 있는 프로세스가 이상종료(ABEND) 했을 경우 PMON에 의해 Latch은 클린 업 됩니다.

 

4. Latch의 대기 방법

Latch의 요구는 willing-to-wait 와 no wait 의 2개의 모드로 행해집니다. 통상은 willing-to-wait 모드로 요구되어 Latch을 획득할 수 있을 때까지 대기합니다. no wait 모드는 다수 있는 Latch의 하나를 획득할 수 있으면 되는 경우 등에 행해져  획득할 수 없는 경우는 다른 Latch이 요구됩니다.

 

Oracle8i까지의 버젼에서는 willing-to-wait로 요구한 Latch이 이미 다른 프로세스에 의해 획득되고 있었을 경우 복수 CPU 환경에 있어서는 나중에 Latch을  요구한 프로세스는 CPU를 획득한 채로 내부적으로 설정되어 있는 최대 회수까지 리트라이를 반복합니다.이 리트라이의 처리를 스핀이라고 부릅니다. 최대 회수 까지 스핀을 반복해도 Latch을 획득할 수 없는 경우 프로세스는 CPU를 해방해 sleeve 합니다. 최초의 sleeve 시간은 100분의 1초로 시간이 되면 다시 CPU를 획득해 Latch 획득을 리트라이 합니다(여기에서도 복수 CPU 환경에서는 스핀을 실시합니다).획득할 수 없으면 다시 sleeve 합니다만, sleeve 시간은  1회마다 배로 증가해 갈 것입니다.스핀을 실시하는 것으로 CPU에 부하가 걸립니다만, 복수 CPU 환경인 프로세스가 스핀중에 다른 CPU를 사용해 Latch 해방을 할 가능성이 있으므로 이러한 처리를 합니다.

Oracle9i 이후의 버젼에서는 Latch 의 대기 방법이 변경되었습니다. willing-to-wait로 요구한 Latch 이 이미 다른 프로세스에 의해 획득되고 있는 경우 복수 CPU 환경에 있어 스핀의 처리를 실시하는 점은 같습니다만, 스핀으로 획득할 수 없는 경우는 그 Latch의 대기 리스트에 그 프로세스의 정보를 추가해 sleeve 합니다. Latch이 해방되면 대기 리스트의 선두 프로세스에 통지가 행해지게 되어 있습니다.

 

5.Latch의 경합을 확인하는 방법

Latch 경합의 상황은 V$LATCH 및 V$LATCH_CHILDREN로 파악할 수 있습니다. V$LATCH의 행은 Latch명 마다의 각종 통계 정보의 값이 됩니다. Latch안에는 같은 이름을 가지는 Latch가 복수 존재하는「부모와 자식 Latch」이라고 불리는 타입의 것이 있습니다. V$LATCH에서는 그러한 통계 정보의 합계가 표시됩니다만, V$LATCH_CHILDREN에는 각 자식 Latch 마다의 통계 정보가 표시됩니다.

 

V$LATCH / V$LATCH_CHILDREN 의 주된 예 (*1) 
  

GETS	willing-to-wait 모드의 요구로 획득한 회수
MISSES	willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 회수
SPIN_GETS	willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 sleeve 하지 않고 스핀만으로 획득할 수 있던 회수
SLEEP1	willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 1회 sleeve 해 획득할 수 있던 회수
SLEEP2	willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 2회 sleeve 해 획득할 수 있던 회수
SLEEP3	willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 3회 sleeve 해 획득할 수 있던 회수
SLEEPS	willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 sleeve 한 회수의 합계
WAITERS_WOKEN	Latch 해방시에 대기하고 있는 프로세스에 통지한 회수
WAIT_TIME	(9.0-) Latch 획득까지의 대기 시간의 합계
IMMEDIATE_GETS	no wait 모드의 요구로 획득한 회수
IMMEDIATE_MISSES	no wait 모드의 요구로 획득에 실패한 회수

 

※ SLEEP4 - SLEEP11는 사용되고 있지 않습니다.

 

(*1): 릴리스 9.0.1까지의 「데이타베이스·레퍼런스」에서는 GETS/MISSES가 「대기가 되었다」의 요구, IMMEDIATE_GETS/IMMEDIATE_MISSES가 「대기 없음」의 요구라고 기재되어 있습니다만  기술 미스입니다.

 

릴리스 9.2이후는 GETS가 「대기 가능 모드로 요구된 회수」라고 기재되어 있습니다. 대기 가능    (willing-to-wait) 모드에서는 획득할 수 있을 때까지 대기하므로, 요구 회수와 획득 회수는 최종적으로는 동일해집니다만 GETS가 카운트 되는 것은 대기 가능 모드로 요구해 획득된 시점이므로, 이 문서의 기술이 엄밀한 의미에서는 올바릅니다.

 

Latch 히트율의 계산방법

---

Latch 히트율(1번째의 획득 시행으로 획득할 수 있던 비율)은 다음의 식에서 계산할 수 있습니다.

 

willing-to-wait 모드의 히트율 : (GETS - MISSES) /GETS
no wait 모드의 히트율     : IMMEDIATE_GETS/(IMMEDIATE_GETS + MMEDIATE_MISSES)

 

V$LATCH / V$LATCH_CHILDREN 에 의한 Latch 경합의 파악 

---

Oracle8i까지의 버젼에서는 willing-to-wait 모드로 요구해 대기하는 경우 각 프로세스가 sleeve    와 리트라이를 반복하기 때문에 sleeve 회수의 합계인 SLEEPS나, SPIN_GETS/SLEEP1/SLEEP2/SLEEP3의 값의 분포가 경합의 상황을 파악하는데 도움이 됩니다. 단 shared pool, library cache, library cache load lock의 3 종류의 Latch에 대해서는 Oracle9i 이후같은 큐를 사용한 대기 방법을 취하므로 WAITERS_WOKEN를 경합의 지표로 합니다.

 

Oracle9i 이후의 버젼에서는 큐를 사용한 대기를 하므로, sleeve의 합계 회수만으로는 경합의 상황을 파악하기에 불충분합니다. 대기 시간을 나타낸  WAIT_TIME열이 추가되었으므로 이것을 지표로 합니다.

 

[출처] Latch의 발생과 경합의 원인|작성자 hirokorea