ABOUT LATCH
LATCH 가 뭐죠?
LATCH는 매우 간단합니다. SGA에 있는 공유 데이터가 보호될 수 있게 해주는 저레벨의 메커니즘입니다 (- _-;; 이게 간단해?). 예를 들어 사용자가 현제 DATABASE 에서 읽고 있는 데이터의 리스트를 보호하고 버퍼케시 블록에 있는 데이터의 구조를 변형되지 않게 보호하는 것 입니다.
서버 프로세스나 백그라운드 프로세스가 자료를 변경하거나 조회를 하기 위해서는 반드시 LATCH와 함께 동반해야 하고, 작업이 끝나면 반드시 LATCH를 풀어주어야 합니다.
TUNING LATCHES
LATCH는 튜닝할 필요가 없습니다(..;). LATCH에 대한 경합(CONTENTION)이 일어나게 된다면 이는 SGA에서 잘못된 리소스 사용이 일어났기 때문입니다. V$LATCH 를 조회하는 것은 문제를 해결하는데 도움이 되지 않습니다.
WAITING LATCH
LATCH는 일반적으로 0 값을 가진채로 메모리 한 구석에 박혀있습니다. 만약 LATCH가 0이 아닌 값을 갖게 된다면 이 LATCH는 다른 PROCESS가 납치해 간 것 입니다.
하나의 CPU를 사용하는 환경에서, LATCH를 다른 프로세스가 사용하고 있다면 뒤늦게 LATCH를 요청한 프로세스는 SLEEP 상태로 접어들게 됩니다.
여러개의 CPU 환경하에서는 LATCH를 다른 프로세스가 사용하고 있다면 뒤늦게 LATCH를 요청한 프로세스는 일정 횟수만큼 스핀 상태(할일없이 뱅뱅 노는거죠.)를 지나 다시 LATCH를 획득하기 위해 요청을 합니다. 그런데도 LATCH를 획득할 수 없으면 다시 스핀 상태로 돌아갑니다. 이러한 스핀상태가 여러번 지속된 후에도 LATCH를 획득할 수 없으면 그 프로세스는 SLEEP 상태로 빠저들고 말죠. 이러한 SPIN TIME은 플랫폼이나 O/S가 결정합니다.
LATCH REQUEST
LATCH를 요청하는 두가지 방법중 한가지 방법을 이용해 이를 획득합니다.
WILLING-TO-WAIT
WILLING-TO-WAIT 으로 요청했는데 LATCH가 사용하지 못한다면, 프로세스는 아주 잠시 대기한 후 다시한번 LATCH를 요청하게 됩니다. 프로세스는 LATCH를 사용할 수 있을때까지 요청과 대기를 계속해서 반복을 합니다. 이 방법은 가장 일반적인 방법입니다.
IMMEDIATE
IMMEDIATE를 이용한 LATCH 요청이 실패한다면 LATCH 획득시까지 기다리지 않고 다른 명령을 수행합니다. 예를들어 PMON(Process MONitor)이 비정상 종료된 프로세스를 청소하려 했으나 LATCH에 접근할 수 없는 상황이 발생했습니다. 그럼 PMON은 LATCH가 풀릴때까지 기다리지 않고 다음 명령을 수행하게 됩니다.
LATCH CONTENTION
V$LATCH 뷰는 Willing-to-wait 형식의 요청이 GETS, MISSES, SLEEPS, WAIT_TIME, CWAIT_TIME, SPIN_GETS 의 컬럼으로 표현됩니다. IMMEDIATE 형식의 요청은 IMMEDIATE_GETS, IMMEDIATE_MISSES로 표현됩니다.
물론 우리의 만능 STATS 팩으로도 확인할 수 있습니다!!(야호!)
GETS : Willing-to-wait 요청이 성공한 횟수
MISSES : Willing-to-wait 요청이 실패한 횟수
SLEEPS : Willing-to-wait 으로 기다리다 기다리다 지쳐 잠든 횟수
WAIT_TIME : Willing-to-wait 으로 기다린 시간 (Milisecond)
CWAIT_TIME : Spin Time 과 Sleep Time 을 합친 시간 입니다.
SPIN_GETS : LATCH의 마음을 잡기 위해 붕붕 돌다가 결국 LATCH를 획득한 횟수 입니다.
IMMEDIATE_GETS : 즉시 LATCH 요청에 성공한 횟수
IMMEDIATE_MISSES : 즉시 LATCH 요청 실패한 횟수
REDUCING CONTENTION FOR LATCHES
일반적으로, DBA는 LATCH를 튜닝할 필요가 없습니다. 허나 다음의 스텝들은 굉장히 유용합니다.
- 좀더 자료를 수집하여 LATCH가 경합이 일어나는지 확인하십시요.
- LATCH에 대한 경합이 SHARED POOL 이나 LIBRARY CAHCE에서 자주 일어나면 APPLICATION 튜닝을 고려해 보십시요.
- 정보를 수집하여 SHARED POOL 과 BUFFER CACHE의 크기를 조정하십시요.
DBA에게 중요한 LATCH
shared pool latch, and library cache latch :
이곳에서 일어나는 LATCH의 경합은 SQL, PL/SQL 문이 재사용 되지 않기 때문에 일어납니다. 이러한 일이 일어나는 이유로는 변수가 BIND 되어 있지 않거나 커서(CURSOR) 캐시가 충분하지 않기 때문입니다. 문제를 해결하기 위해서 SHARED POOL을 튜닝하거나 APPLICATION을 튜닝해야 합니다.
cache buffers lru chain latch :
이곳에서는 더티 블락(dirty blocks)이 디스크에 쓰여질때나 서버 프로세스가 쓰기 위해 블럭을 검색할때 LATCH 가 필요합니다. 이곳에서 LATCH의 경합이 발생한다면 버퍼케시에 지나치게 많은 처리량이 늘어나거나 캐시에서 너무 많은 정렬기능 (Cache-based sort), 잘못된 인덱스의 반복적 (Large index range scans) 접근을 일으키는 SQL, 혹은 너무 많은 테이블 스켄이 일어나는 경우 입니다. 또한 DBWR(DATABASE WRITER)가 잦은 데이터 블록의 변화로 자신의 페이스(PACE)를 유지하지 못할경우와 빈 버퍼를 찾기위해 잡아놓은 LATCH의 시간보다 강제로 더 길게 FOREGORUND PROCESS가 WAIT 하면 발생할 수 있습니다. 이 문제를 극복하기 위해선 BUFFER CACHE와 DATABASE WRITER OPERATION을 튜닝할 것을 고려해 보십시요.
cache buffers chain latch :
이 Latch는 사용자 프로세스가 버퍼케시에 데이터 블락을 올려 놓을때 필요합니다. 이 Latch에 대한 경합이 일어나는 이유는 특정한 블럭(hot blocks)에 반복적으로 접근하고 있기 때문입니다.
FIN
REF) Oracle9i Performance Tunning - Volume I
다음편 예고!!)
OPTIMIZER를 이용한 SQL TUNNING!! 상당히 포스트 연재가 길어질 것 같습니다. 내용이 좀 방대하군요.
댓글 없음:
댓글 쓰기