[친절한 SQL 튜닝]1.3 I/O 메커니즘 - 캐시 탐색 메커니즘, Latch와 Lock

캐시 탐색 메커니즘

• Direct Path I/O를 제외한 모든 블록 I/O는 메모리 버퍼캐시를 경유한다.
  • Single Block I/O, Multiblock I/O 모두 버퍼캐시를 경유한다.
• DBMS는 버퍼캐시를 해시 구조로 관리한다.

• 버퍼캐시에서 20번 블록(DBA)을 찾고자 하는 경우,
  블록 번호를 5로 나누면(mod함수를 해시 함수로 사용) 나머지값은 0
• 이 블록이 캐싱되어 있다면 버퍼 헤더가 첫 번째 해시 체인(해시값 = 0)에
  연결되어 있을 것이므로 찾을 때는 항상 첫 번째 해시 체인만 탐색하면 된다.
• ✨ 캐시 탐색은 버퍼캐시에서 블록을 찾을 때 해시 알고리즘으로 버퍼 헤더를 찾고,
  버퍼 헤더에서 얻은 포인터로 버퍼 블록을 액세스 하는 방식을 사용한다.

해시 구조의 특징

1. 같은 입력 값은 항상 동일한 해시 체인(버킷)에 연결됨
2. 서로 다른 입력값이 동일한 해시 체인(버킷)에 연결될 수 있음
3. 해시 체인 내에서는 정렬이 보장되지 않음

메모리 공유 자원에 대한 액세스 직렬화

• 버퍼캐시는 SGA 구성요소로, 버퍼캐시에 캐싱된 버퍼 블록은 모두 공유 자원이다.
• ✨ 공유 자원은 누구나 접근할 수 있으므로 동시성 문제가 발생하고,
  이를 해결하기 위해 직렬화 메커니즘이 필요하다.
  • 하나의 버퍼 블록을 두 개 이상의 프로세스가 동시에 접근
  • 하나의 자원을 한 프로레스씩 순차적으로 접근하도록 구현하기 위해
    작업 순서를 보장하는 동기화 기법이 필요 - 직렬화 메커니즘, 래치(Latch)

🔒 캐시버퍼 체인 래치(Latch)

• 대량의 데이터를 읽는 경우, 모든 블록에 대해 해시 체인을 탐색
• 해시 체인을 스캔하는 동안 다른 프로세스가 체인 구조를 변경할 가능성⭕
• 이를 방지하기 위해 해시 체인 래치가 존재하고,
  키(Key)를 획득한 경우에만 해시 체인으로 진입 가능
• 읽고자하는 블록을 찾았으면 캐시버퍼 체인 래치를 바로 해제하고,
  버퍼 Lock을 걸어서 정합성 유지

✨ 버퍼 캐시에는 캐시버퍼 체인 래치, 캐시버퍼 LRU 체인 래치가 작동한다.

🔒 버퍼 락(Lock)

• 캐시버퍼 체인 뿐만 아니라, 버퍼 블록 자체에도 직렬화 메커니즘이 존재 - 버퍼 Lock
• 하나의 해시 체인에는 여러 버퍼 헤더가 존재할 수 있기에,
  읽고자하나는 블록을 찾았으면 캐시버퍼 체인 래치를 해제해야 한다.
• 그런데, 래치를 해제한 상태로 버퍼블록 데이터를 액세스하는 도중 후행 프로세스가
  같은 블록에 액세스 한다면 데이터 정합성 문제가 발생하므로 버퍼Lock을 사용한다.
• 버퍼 Lock은 캐시버퍼 체인 래치를 해제하기 전에 버퍼 헤더에 Lock을 설정함으로써
  버퍼 블록 자체에 대한 직렬화 문제를 해결한다.

로우 Lock vs 버퍼 Lock

같은 로우는 로우 Lock에 의해 보호될 텐데 버퍼 Lock이 왜 필요할까?

나중에 알아보자 …

직렬화 메커니즘과 SQL 튜닝

• 잘못 작성된 SQL → 많은 논리적 I/O 발생
  • 불필요한 Full Scan, 비효율적인 인덱스 접근 등
• 논리적 I/O가 많다는 건 → 메모리에서 많은 블록을 탐색한다는 의미
  • 이때 여러 세션이 동일한 캐시 블록이나 인덱스 블록을 반복적으로 읽는 경우
  • Buffer Cache 또는 Library Cache에서 경합 발생 - 캐시 경합(Cache Contention)
• 이런 경합 상황에서 직렬화 메커니즘이 개입됨
  • 락(Latch) 또는 Mutex로 자원 접근을 직렬화하려고 함
  • 그 결과 CPU 사용률 급증, 대기 시간 증가, 성능 저하 발생

정리

SQL이 비효율적이면 논리적 I/O가 증가하고, 캐시 경합으로 이어지며,
결국 직렬화 메커니즘이 개입하면서 시스템 성능이 급격히 저하될 수 있다.

따라서 단순히 캐시만 늘리는 게 아니라,
쿼리 자체를 논리적으로 효율화해서 경합을 예방하는 구조로 설계되어야 한다.

ref. https://product.kyobobook.co.kr/detail/S000001975837