[SQLP] 버퍼 LOCK

 

(1) 버퍼 LOCK

- 두 개 이상의 프로세스가 동시에 버퍼 내용을 읽고 쓴다면 문제가 생길 수 있기 때문에, 캐시된 버퍼 블록을 읽거나 변경하려는 프로세스는 먼저 버퍼 헤더로부터 버퍼 LOCK을 획득해야 함

- 버퍼 LOCK을 획득했다면 래치를 곧바로 해제

- Share 모드 LOCK : 버퍼 내용을 읽기만 할 때

- Exclusive 모드 LOCK : 버퍼 내용을 변경하고자 할 때(한 시점에 하나의 프로세스만 얻을 수 있음)

- 해시 체인 래치를 획득하고 목적한 버퍼를 찾았는데 다른 프로세스가 버퍼 LOCK을 Exclusive 모드로 점유하고 있다면, 버퍼 헤더에 있는 버퍼 LOCK 대기자 목록에 자신을 등록하고 일단 래치를 해제

- 대기자 목록에서 waiting → 버퍼 LOCK 해제됨 → 버퍼 LOCK 획득 → 원하는 작업 진행(해당 버퍼가 속한 체인 래치를 다시 한번 획득)

 

(2) 버퍼 핸들

- 버퍼 Pin : 버퍼 LOCK을 설정하는 것은 자신이 현재 그 버퍼를 사용중임을 표시해 두는 것으로서, 그 버퍼 헤더에 Pin을 걸었다고도 표현(버퍼 LOCK의 다른말) => Pinned 버퍼

- 변경 시 : 하나의 프로세스만 Pin 설정

- 읽기 시 : 여러 개 프로세스 동시에 Pin 설정가능

- 버퍼 핸들 : 버퍼 헤더에 Pin을 설정하려고 사용하는 오브젝트; 버퍼 핸들을 얻어 버퍼 헤더에 있는 소유자 목록에 연결시키는 방식으로 Pin을 설정

- 버퍼 핸들을 얻으려면 또 다른 래치가 필요 : 캐시 버퍼 핸들 래치

 

(3) 버퍼 LOCK의 필요성

- 사용자 데이터를 변경할 때 DML LOCK을 통해 보호하도록 되어 있지만, 오라클은 하나의 레코드를 갱신하더라도 블록 단위로 I/O를 수행하기 때문에 또 다른 LOCK을 획득해야 함

- 블록 자체로의 진입을 직렬화

 

(4) 버퍼 Pinning

- 버퍼를 읽고 다너 버퍼 Pin을 즉각 해제하지 않고 데이터베이스 Call이 진행되는 동안 유지하는 기능

- 같은 블록을 반복적으로 읽을 때 버퍼 Pinning을 통해 래치 획득 과정 생략 시, 논리적인 블록 읽기 횟수를 줄일 수 있음

- 같은 블록을 재방문할 가능성이 큰 몇몇 오퍼레이션을 수행할 때만 사용

- Call이 끝나고 사용자에게 결과를 반환하고 나면 Pin은 해제

- 버퍼 Pinning을 통한 블록 I/O 감소효과는 SQL을 튜닝하는 데 있어 중요