1. latch: cache buffer chains
cache buffers chains 래치 경합이 발생하는 대표적인 경우 두 가지
1) 비효율적인 SQL
동시에 여러 프로세스가 넓은 범위의 인덱스나 넓은 범위의 테이블에 대해 스캔을 수행할 경우
cache buffers chains 래치 경합이 광범위하게 발생할 수 있다.
2) 핫블록 (Hot Block)
SQL 문의 작동방식이 소수의 특정 블록을 계속해서 스캔하는 형태로 작성되었다면, 여러 세션이 동시에 이 SQL 문을 수행하는 경우
핫블록에 의한 cache buffers chains 래치 경합이 발생한다.
우회적으로 핫블록에 의한 cache buffers chains 래치 경합을 해소하는 방법은
핫블록에 속한 로우들을 되도록이면 다른 블록으로 분산시키는 것이다.
1. PCTFREE 를 높게 주거나 작은 크기의 블록을 사용함으로써 블록 경합을 줄인다.
2. 파티셔닝(Partitioning) 기법을 사용해서 로우가 물리적으로 다른 블록으로 들어가게끔 한다.
3. 문제가 되는 블록의 로우들에 대해서만 삭제 후 재 삽입 작업을 한다.
2. latch: cache buffers lru chain
오라클은 다음과 같은 경우에 cache buffers lru chain 래치를 획득해야 한다.
1) 프로세스가 아직 메모리에 올라오지 않은 블록을 읽고자 할 경우에는 프리 버퍼를 할당받기 위해 LRU 리스트를 탐색하게 되는데,
이 과정에서 cache buffers lru chain 래치를 획득해야 한다.
2) DBWR 이 더티 버퍼를 파일에 기록하기 위해 LRUW 리스트를 탐색하고, 해당 버퍼를 LRU 리스트로 옮기는 과정에서도
cache buffers lru chain 래치를 획득해야 한다.
3. buffer busy waits /read by other session
오라클은 매우 정교하고 효과적인 로우 레벨 락 메커니즘을 제공하며,
사용자의 동시 변경으로부터 데이터를 보호하기 위해 블록 단위로 락을 거는 일은 없다고 알려져 있다.
하지만 이것은 절반만의 사실이다.
공식적으로 블록 단위의 락은 존재하지 않지만 오라클의 I/O 가 블록단위로 이루어진다는 사실 때문에 블록 단위의 락은 반드시 필요하다.
Buffer lock 을 획득하기 위해 기다리는 동안 일반적으로 buffer busy waits 이벤트를 대기하게 된다.
1) Select / Select 에 의한 read by other session
2) Select / Update 에 의한 buffer busy waits / read by other session
3) Insert / Insert 에 의한 buffer busy waits
4) Update / Update 에 의한 buffer busy waits
4. write complete waits
write complete waits 대기는 buffer busy waits 대기와 마찬가지로 buffer lock 경합에 의한 대기로 분류할 수 있다.
DBWR 은 더티 버퍼를 디스크에 기록하는 동안에 버퍼에 대해 buffer lock 을 Exclusive 하게 획득한다.
이 때 버퍼를 읽거나 변경하려는 다른 프로세스는 이 작업이 끝나기를 기다려야 하고 그동안 write complete waits 이벤트를 대기하게 된다.
서버 프로세스가 디스크에 기록 중인 버퍼를 읽을 확률이 실제로는 높지 않은데도, 이로 인한 대기를 겪는다는 것은
DBWR이 더티 버퍼를 기록하는 시간이 지나치게 길다는 것을 의미한다.
DBWR 의 성능이 느린 이유
- I/O 시스템의 성능이 느린 경우
- DBWR 의 작업량이 너무 많은 경우
FAST_START_MTTR_TARGET 을 높게 주어서 증분 체크포인트의 회수를 줄이면
write complete waits 대기가 크게 줄어들 뿐만 아니라, 그 외 다른 모든 대기현상들도 전반적으로 적게 발생하는 것을 확인할 수 있다.
만일 시스템 전체적으로 데이터 변경작업이 매우 많아서 체크포인트에 대한 부하가 생긴다고 판단되면
증분 체크포인트의 주기를 늘려줌으로써 이 문제를 해결할 수 있다.
하지만, 이 경우 복구에 더 많은 시간이 소요될 수 있다는 점에 유의하자.
5. free buffer waits
서버 프로세그가 블록을 메모리에 올리는 과정은 다음과 같다.
1. 사용자가 요청한 블록의 DBA 에 대해 해시 함수를 적용해서 적절한 해시 버킷을 찾는다.
2. 해시 버킷에 딸려 있는 해시 체인을 탐색해서 블록에 해당하는 버퍼 헤더가 존재하는지 확인한다.
3. 아직 버퍼 캐시에 존재하지 않으면 우선 LRU 리스트를 가장 덜 사용된 순서로 프리 버퍼를 찾는다.
4. LRU 리스트에서 프리 버퍼를 찾을 때 _DB_BLOCK_SCAN_MAX_PCT (기본값은 40) 파라미터 값만큼 스캔을 하고도
프리버퍼를 찾지 못하면 오라클은 스캔을 멈추고 DBWR 에게 더티 블록을 디스크에 기록하고 프리 버퍼를 확보할 것을 요청한다.
쓰기가 완료되면 해당 버퍼를 사용한다.
free buffer waits 대기가 발생하는 이유는 보통 다음과 같다.
- 비효율적인 SQL
- 지나치게 작은 버퍼 캐시
- DBWR 의 성능 저하
DBWR 성능 개선 가이드
- 로디바이스 (RAW Device) 와 AIO (Asynchrous IO) 를 사용한다. 혹은 Direct I/O 를 사용하고 더불어 복수개의 DBWR 을 사용한다.
- DBWR 의 활동량이 불필요하게 많지 않도록 한다. 즉 체크포인트 회수가 합리적으로 유지되도록 한다. 체크포인트에 의한 부하가 성능에 미치는 영향은
write complete waits 대기이벤트에서 논의한 바 있다.
- 다중 버퍼 풀 (Default, Keep, Recycle) 을 적절히 사용해서 간접적으로 DBWR 의 부하를 줄일 수 있다.
6. enq : TC - contention
인위적인 체크포인트를 수행하는 작업들 중 일부는 TC 락 (Thread Checkpoint Lock, 혹은 Tablespace Checkpoint Lock) 을 획득해야 한다.
TC 락을 획득하는 과정에서 경합이 발생하면 enq:TC-contention 이벤트를 대기하게 된다.
실제로 TC 락을 획득하는 과정은 조금 복잡하다.
1. 서버 프로세스가 우선 TC 락을 X 모드로 획득한다.
2. 서버 프로세스는 획득한 TC 락을 SSX 모드로 변경하고, 동시에 CKPT 프로세스가 SS 모드로 해당 락을 획득한다.
CKPT 는 락을 획득하고 체크포인트 작업을 수행하게 된다.
3. 서버 프로세스는 다시 TC 락을 X 모드로 획득하려고 시도하는데,
해당 락이 CKPT 에 의해 해제될 때까지 대기하게 된다.
이 때의 대기이벤트가 enqueue: TC - contention 이다.
4. 체크 포인트 작업이 완료되면 CKPT 프로세스는 TC락을 해제하고,
서버 프로세스는 TC 락을 획득함으로써 체크포인트 작업이 끝났다는 것을 알게 된다.
1) Parallel Query
PQ 에서 체크포인트가 발생하는 이유는 슬레이브 세션에 의한 direct path read 때문이다.
direct path read 는 버퍼 캐시를 거치지 않고, 데이터 파일을 직접 읽는 것을 말한다.
오라클은 다음과 같은 세가지 경우에 direct path read (또는 physical read direct 방식의 읽기) 를 사용한다.
- 메모리 영역에서 소팅 작업을 할 수 없을 때 임시 세그먼트 (Temp Segment) 영역에 정보를 저장하고 읽는 과정에서
direct path write, direct path read 가 발생한다.
- 슬레이브 세션이 데이터를 스캔하기 위해 데이터를 직접 읽어들일 때 direct path read 를 사용한다.
- I/O 시스템의 성능저하로 블록을 충분히 빠른 속도로 읽어들이지 못한다고 판단되면,
오라클은 임시 방편으로 direct path read 를 사용한다.
2) 테이블 스페이스 핫백업 (Tablespace Hot backup)
ALTER TABLESPACE ... BEGIN BACKUP 을 수행하면 오라클은 테이블 스페이스 내에 속한 모든 데이터 파일에 대해
더티 블록을 디스크에 기록 (Checkpoint) 하게 되는데 이 과정에서 enq: TC - contention 대기를 겪는다.
7. enq: CI - contention, enq: RO - contention
오라클은 특정 테이블을 Truncate 하기 전에 버퍼 캐시에 적재되어 있는 테이블 데이터의 더티 버퍼에 대해 체크포인트 작업을 수행해야 한다.
만일 Truncate 수행 도중 장애가 발생했더라도 이후 복구가 가능해야하기 때문이다.
Truncate 를 수행한 서버 프로세스는 Truncate 작업이 끝날 때까지 대기해야 하는데, 흔히 enq : CI - contention 대기 현상으로 관찰된다.