[Practical owi] lock & latch

Editor's Notes

• #3: Latch 래치(latch)란? SGA 내부에 정보가 존재하며, 로컬 인스턴스에서만 볼 수 있다. 래치(latch)는 인스턴스 레벨로 작동 단순한 CPU 명령어를 사용하여 구현되었다. (구현이 쉽고 가벼움) Willing-to-wait과 no-wait 두 가지 모드로 요청이 가능하다. 아주 짧은 시간만 지속된다. (microsecond 단위) 래치는 데드락이 발생되지 않도록 구현되었다.(래치의 데드락 발생시 ora-600 에러 발생) 래치는 기본적으로 exclusive 모드로 동작한다. (9i 이후 버전은 cache buffers chains 래치는 경합을 줄이기 위해 shared 모드를 지원함) 슬라이드 내용 – [래치(latch)의 획득 과정] Process A가 래치 획득 시도 해당 래치를 점유한 Process가 존재하지 않으므로 래치 획득 래치가 보호하고 있는 SGA 리소스 Area1, Area2를 사용 Process B가 래치 획득 시도 Process A가 래치를 점유하고 있으므로 래치 획득 실패
• #4: Latch가 보호하는 Resource 래치(latch)가 보호하는 리소스는 SGA 내의 모든 메모리 영역이다.예) 버퍼 캐시, shared pool, 라이브러리 캐시, 로그 버퍼, …. SGA 영역을 탐색하는 모든 행위는 래치 획득 후에만 가능하다. 래치는 SGA 메모리 영역을 보호하는 메모리 구조체이므로, 새로운 SGA 메모리 영역이 추가되면, 이를 보호하는 래치도 추가 된다. 메모리 영역의 속성에 따라 하나의 래치 혹은 여러 개의 래치로 보호된다. 독립 래치와 부모 래치의 정보는 V$LATCH_PARENT에서 확인할 수 있다. 자식 래치의 정보는 V$LATCH_CHILDREN 에서 확인할 수 있다. [참고] Cache buffers chains 래치버퍼 캐시 의 크기가 16M 이상 1G 이하까지의 cache buffers chains 래치의 개수는 1024개 이다.버퍼 캐시의 크기가 증가함에 따라 단계적으로 증가 한다.cache buffers chains 래치의 개수는 _DB_BLOCK_HASH_LATCHES 파라미터 값을 이용하여 조절이 가능하다. Shared pool 래치Shared pool 래치는 하나의 shared pool에 하나만 존재한다. 오라클 9i이상부터는 CPU_COUNT 파라미터 값이 4 이상이고 shared pool의 크기가 250M 이상인 경우 _ KGHDSIDX_COUNT 파라미터 값만큼 서브 풀(sub pool)을 생성하여 shared pool을 관리할 수 있다. 그러므로 오라클 9i 이전 버전에서는 하나의 shared pool 래치를 오라클 9i 이상부터는 다수의 shared pool 래치를 사용할 수 있다. 라이브러리 캐시 래치(library cache latch)CPU_COUNT 파라미터 값보다 큰 소수 중 가장 작은 수만큼 라이브러리 캐시 래치를 사용한다.가령 CPU 개수가 4인 시스템에서는 5개의 라이브러리 캐시 래치를 사용한다.
• #5: Latch 획득 Mechanism Willing-to-wait 모드의 Latch 획득 Mechanism Spin에 의한 획득 방식 Short wait 래치(latch) Exponential backoff sleep algorithm(기하급수적 증가) 사용 1, 1, 2, 2, 4, 4, 8, 8, 16, 16, 32, 32, …. (1/100초 단위) 슬립(sleep)할 수 있는 최대 시간은 _MAX_EXPONENTIAL_SLEEP 파라미터의 수치까지 증가 (default 2초) 하나 이상의 래치를 소유하고 있는 프로세스가 슬립 하게 되면 _MAX_SLEEP_HOLDING_LATCH 파라미터에 정의된 수치만큼만 슬립 가능(default 0.04초) 순서 보장 안됨 CPU가 하나일 경우에는 스핀(spin)을 수행하지 않음 Spin 방식을 사용하는 래치(대부분의 래치) cache buffers chains 래치 cache buffers lru chain 래치 row cache objects 래치 …. Posting에 의한 획득 방식 Long wait 래치 대기목록(wait list)에 등록해 두고 래치 홀더(holder)가 깨워줄 때까지 대기 순서 보장 안됨 Posting 방식을 사용하는 래치 shared pool 래치 라이브러리 캐시 래치(library cache latch)
• #6: Spin에 의한 latch 획득 슬라이드 내용 – [spin에 의한 래치(latch) 획득 과정] Process A 래치 획득 시도 해당 래치를 점유한 Process가 존재하지 않으므로 래치 획득 Process B 래치 획득 시도 Process A가 래치를 점유하고 있으므로 래치 획득 실패 Process B는 _SPIN_COUNT의 수 만큼 스핀을 수행(스핀을 수행한 후 다시 래치 획득 시도) spin으로 인한 CPU 사용률 증가 만일 여러 번의 스핀을 반복한 후에도 래치를 획득하지 못할 경우, Process B는 슬립(sleep) 상태로 전환 Process B는 일정시간이 지나면 깨어나서 다시 래치 획득 시도
• #7: Posting에 의한 Latch 획득 슬라이드 내용 – [posting에 의한 래치(latch) 획득 과정] Process A 래치 획득 시도 해당 래치를 점유한 프로세스가 존재하지 않으므로 래치 획득 Process B 래치 획득 시도 Process A가 래치를 점유하고 있으므로 래치 획득 실패 Process B를 대기목록(wait list)에 등록 Process A가 자원을 해제할때 대기목록으로 알려 줌 대기목록에서 대기하던 프로세스 중 하나가 래치를 획득(순서보장을 하지 않기 때문에 대기목록에 존재하지 않는 프로세스가 래치를 획득할 수도 있음)
• #8: Event 정의 latch free 대기이벤트란? 프로세스가 willing-to-wait 모드로 _SPIN_COUNT 만큼 스핀을 수행하고도 래치(latch) 획득에 실패하여 슬립(sleep)한다는 것을 의미 래치는 속성상 획득 횟수와 대기 횟수가 매우 높음 대기시간(TIME_WAITED)이 가장 변별력 있는 경합 여부 판단 기준 오라클 10g 중요한 래치들에 대해서는 별도의 대기 이벤트 명 부여 그 외는 latch free 대기 이벤트
• #9: Dynamic Performance Views V$LATCH : 래치(latch)의 종류별 통계 값 GETS : willing-to-wait 모드에서 슬립 하기 전에 래치 요청 횟수 MISSES : willing-to-wait 모드에서 슬립 하기 전에 래치 획득 실패 횟수 SPIN_GETS : willing-to-wait 모드에서 슬립 하기 전의 스핀단계에서의 래치 획득 성공 횟수 SLEEPS : willing-to-wait 모두에서의 슬립 횟수 IMMEDIATE_GETS : no-wait 모드에서 래치 획득 성공 횟수 IMMEDIATE_MISSES : no-wait 모드에서 래치 획득 실패 횟수 SLEEP1 ~ SLEEP4 : 1~3 회의 슬립횟수와 4회 이상의 슬립 횟수. 오라클 10gR2부터는 V$EVENT_HISTOGRAM 뷰로 대체 WAITERS_WOKEN : posting 에 의한 래치 획득 방식을 사용할 경우 세션이 깨어난 횟수. 오라클 10gR2부터는 사용되지 않음. WAIT_TIME : 래치를 획득하기 위해 대기한 시간(microsecond 단위) V$LATCH_PARENT : 독립 래치와 부모 래치의 통계 V$LATCH_CHILDREN : 자식 래치 별 통계 값 V$LATCH_HOLDER : 래치 홀더(holder)에 대한 정보 V$LATCH_MISSES 래치 획득 실패가 발생한 오라클 커널 코드의 위치에 대한 정보를 제공
• #10: Lock 개요 락(lock) 이란? 데이터베이스 내부에 정보가 존재하며, 모든 인스턴스에서 볼 수 있다. 락(lock)은 데이터베이스 레벨에서 작동 문맥 교환을 포함한 일련의 명령어들을 사용하여 구현되었다.(구현이 복잡하고 무거움) 6가지 모드로 요청이 가능하다.(null, row share, row exclusive, share, share row exclusive, exclusive) 모드간의 호환성 관계 존재 매우 복잡한 작업에 대한 동기화 작업도 가능 트랜잭션 동안 지속된다. 프로세스가 락 획득을 실패한 후, 해당 요청은 큐(queue)로 관리되며, 요청한 순서대로 서비스 된다.(nowait 모드는 예외임) 락은 큐(queue)방식을 사용하며, 데드락이 발생될 가능성이 높다. 데드락이 발생 될 때마다 트레이스 파일이 생성된다. 슬라이드 내용 – [락(lock)의 획득 과정] Process A가 락획득 시도 해당 락을 점유한 프로세스가 존재하지 않으므로 락 획득 해당 오브젝트 사용 Process B가 락 획득 시도 Process A가 락을 점유하고 있으므로 락 획득 대기
• #11: Lock이 보호하는 Resource Latch가 보호하는 Resource 외의 모든 Database Object Enqueue 락(lock) 테이블스페이스 테이블 트랜잭션 … Library cache lock 라이브러리 캐시 오브젝트(library cache object : LCO)의 스팩(specification) Library cache pin 라이브러리 캐시 오브젝트의 실행정보(contents) Row cache lock 로우 캐시 오브젝트(row cache object : RCO)
• #12: Lock 분류 Enqueue 락(lock) Shared pool 내에 enqueue 구조를 사용해서 통합 관리되는 락 오라클 10g부터는 대부분의 enqueue 락에 대해 개별 대기이벤트가 등록되므로 V$EVENT_NAME 뷰를 조회하면 어떤 종류의 enqueue 락이 존재하는지 알 수 있다. Enqueue 락 종류 User Type : TX, TM, UL System Type : US, HW, SQ, SV, TT, WF, … 기타 락(lock) Enqueue 구조를 사용하지 않는 락 자체 메모리 영역에 보유프로세스목록(owner list)과 대기프로세스목록(waiter list)으로 관리 된다. 기타 락 종류 library cache lock library cache pin row cache lock buffer lock
• #13: Lock 획득 Mode 6가지의 모드 지원 이들 모드를 이용해 복잡한 작업도 보호 가능 Null (N)리소스(resource)에 대한 변경이 있을 경우 락(lock) 홀더(holder)에게 변경 사실 전달 Sub-Shared (RS / SS)리소스의 일부분에 대한 shared 락이 필요한 경우 Sub-Exclusive (RX / SX)리소스의 일부분에 대한 exclusive 락이 필요한 경우 Shared (S)리소스에 대한 변경을 막을 경우 Shared-Sub-Exclusive (SRX / SSX)리소스의 일부분에 대해서는 exclusive 락이, 리소스 전체에 대해서는 shared 락이 필요한 경우 Exclusive (X)리소스에 대한 변경이 필요한 경우
• #14: Lock Mode 호환성 락 모드 호환성 : SQL 문과 TM 락 Statement Mode RS RX S SRX X SELECT N Y Y Y Y Y INSERT RX Y Y N N N UPDATE RX Y* Y* N N N DELETE RX Y* Y* N N N SELECT.. FOR UPDATE RS Y* Y* Y* Y* N
• #15: Lock 획득 Mechanism 슬라이드 내용 – [락(lock) 획득 Mechanism] Process A가 shared 모드로 락(lock) 획득 시도 해당 락을 점유한 프로세스가 존재하지 않으므로 Process A가 shared 모드로 락 획득 Process A를 보유프로세스목록(owner list)에 등록 Process W가 exclusive 모드로 락 획득 시도 Process A가 shared 모드로 락을 획득하고 있으므로 락 획득 실패 Process W는 대기프로세스목록(waiter list)에 등록 보유프로세스목록에 등록되어 있는 프로세스가 작업을 완료하면 대기프로세스목록에 존재하는 다른 프로세스를 깨움 대기프로세스목록에 등록된 프로세스는 타임아웃 시간이 경과 후에도 깨워주지 않으면 스스로 깨어나서 데드락이 발생했는지 여부를 확인한 후 다시 대기상태로 빠짐 타임아웃 데드락을 피하기 위해 대기목록의 프로세스는 3초마다 스스로 깨어남 데드락 체크 후 다시 대기목록으로 돌아감 데드락이 확인되면, 락 요청은 취소되고 현재 SQL문이 롤백 타임아웃시간 Enqueue 락(lock): 3초 Buffer lock : 일반적인 경우에는1초, 연속적으로 buffer lock을 획득하기 위해 대기하는 시간은 3초 Row cache lock : 60초 Library cache lock / library cache pin : 일반 프로세스는 3초, PMON 프로세스는 1초
• #16: Event 정의 Enqueue 대기이벤트란? 프로세스가 enqueue 락(lock)을 획득하는데 실패해서 대기프로세스목록(waiter list)에서 기다린다(sleep)는 의미 락(lock)을 보유중인 프로세스는 락을 해제하면 다음 프로세스를 깨워줌 오라클 10g 대부분의 enqueue 락에 대해 개별 대기이벤트 명 부여 경합 발생 상황에 따라 세분화된 대기이벤트 명 부여
• #17: 기타 Lock 관련 Event library cache lock 라이브러리 캐시 오브젝트(library cache object : LCO)를 접근하거나 변경하는 경우, 핸들(handle)에 대해 획득 하는 락 라이브러리 캐시 오브젝트의 스팩(specification)을 보호 타임아웃 - 일반 프로세스 3초, PMON 프로세스 1초 library cache pin 라이브러리 캐시 오브젝트를 접근하거나 변경하는 경우, 라이브러리 캐시 오브젝트에 대해 획득하는 락 라이브러리 캐시 오브젝트의 실행정보(contents)를 보호 타임아웃 - 일반 프로세스 3초, PMON 프로세스 1초 row cache lock 로우 캐시 오브젝트(row cache object : RCO)를 변경하고자 할 때 획득하는 락 여러 프로세스가 동시에 로우 캐시 오브젝트를 변경하면 경합 발생 타임아웃 - 60초 buffer busy waits Buffer lock 획득 시 경합 발생 오라클 10g에서는 2개의 이벤트로 분화 buffer busy waits read by other session 타임아웃 - 일반적 경우 1초, 연속적으로 대기할 경우에는 3초
• #18: Dynamic Performance Views V$LOCK : enqueue 락 문제 완벽 분석 가능 SID : 락을 보유 중이거나 요청 중인 세션의 아이디. LMODE > 0 이면 락을 보유중인 세션.REQUEST > 0 이면 락을 요청 중인 세션. TYPE : enqueue 락의 리소스 타입(예 : TM, TX, UL, US, CI, TC, ….) ID1 : 리소스 아이디1 ID2 : 리소스 아이디2. TYPE+ID1+ID2 가 락이 보호하는 리소스 구분자 LMODE : 락을 보유하고 있는 경우의 모드(1~6. 락 모드 참조) REQUEST : 락을 요청중인 경우의 모드(1~6. 락 모드 참조) CTIME : 현재의 락 모드가 허용된 이후의 시간(second). 즉, 락을 보유하거나 요청한 이후부터의 시간 BLOCK : 현재의 락이 다른 락을 블로킹하고 있는지 여부. 1 = 다른 락을 블로킹 중, 0 = 다른 락을 블로킹하지 않음 V$ENQUEUE_LOCK : 블로킹 현상이 발생한 경우만 조회 가능 V$LOCKED_OBJECT : TM 락을 획득한 세션과 오브젝트 정보 DBA_DML_LOCKS : TM 락에 대한 정보 DBA_DDL_LOCKS : library cache lock에 대한 정보 DBA_KGLLOCK : library cache lock + library cache pin에 대한 정보 X$KGLLK : library cache lock에 대한 정보 X$KGLPN : library cache pin에 대한 정보 V$ROWCACHE_PARENT : row cache lock에 대한 정보