Oracle의 버퍼락(Buffer Lock) 은 Oracle 데이터베이스에서 데이터 블록(buffer cache) 내의 충돌을 방지하기 위해 사용되는 잠금 메커니즘입니다. 일반적으로, 여러 프로세스가 동일한 블록을 액세스하려 할 때 발생하는 동시성 문제를 해결하기 위해 존재합니다. (Row Lock과 다름)
1. 버퍼락의 개념
- 버퍼 캐시(Buffer Cache): 데이터베이스에서 읽힌 데이터 블록이 저장되는 메모리 영역.
- 버퍼락(Buffer Lock): 여러 세션이 동일한 블록을 수정하려 할 때 충돌을 방지하기 위한 잠금.
- Latch vs. Lock:
- Latch: 매우 짧은 기간 동안 유지되는 경량 잠금.
- Lock: 트랜잭션이 끝날 때까지 유지될 수 있는 잠금.
참고로 오라클은 데이터를 읽는 최소 단위가 블록 단위입니다. Row한줄을 읽어도 블록단위로 읽어옵니다. (한 블록 내에는 수백개의 Row가 있을 수도 있음) 그렇기 때문에 Row Lock과 별개로 Buffer Lock 개념이 있는 겁니다. 아래쪽에 비교 분석 내용을 추가로 써놨습니다.
2. 버퍼락의 종류
Oracle은 성능을 최적화하기 위해 여러 수준의 잠금을 제공합니다.
- Exclusive Lock(X)
- 한 프로세스만 데이터 블록을 수정 가능.
- 다른 프로세스는 해당 블록을 읽거나 수정할 수 없음.
- Shared Lock(S)
- 여러 프로세스가 동시에 블록을 읽을 수 있음.
- 하지만 수정은 불가능.
- Null Lock(N)
- 트랜잭션이 데이터 블록을 읽지만 변경하지 않을 경우 사용.
3. 버퍼락 경합(Buffer Lock Contention)
버퍼락 경합이 발생하면 성능 저하가 나타날 수 있습니다. 원인과 해결책은 다음과 같습니다.
① 원인
- 동일한 블록에 대한 과도한 동시 액세스
→ 특정 핫 블록(예: 인덱스 루트 블록)에 대한 집중적인 액세스 - I/O 지연
→ 디스크에서 데이터를 읽어오는 시간이 길어짐 - 락이 해제되지 않음
→ 장시간 트랜잭션 유지로 인해 버퍼락이 오래 유지됨
② 해결책
- 데이터 블록의 핫스팟 제거
- 자주 액세스되는 블록이 있다면 파티셔닝(Partitioning) 적용.
- 적절한 인덱스 사용
- 인덱스를 최적화하여 불필요한 블록 액세스를 줄임.
- PGA/TEMP 테이블 활용
- 자주 사용하는 데이터는 PGA나 TEMP 테이블을 사용하여 블록 경쟁 감소.
- INITRANS 및 FREELISTS 조정
INITRANS값을 증가시켜 여러 트랜잭션이 동시에 블록을 수정 가능하도록 설정.FREELISTS증가로 다중 프로세스가 데이터 블록을 독립적으로 액세스 가능하게 조정.
4. 버퍼락 관련 주요 대기 이벤트
다음과 같은 대기 이벤트를 확인하여 문제를 분석할 수 있습니다.
- buffer busy waits: 특정 블록이 여러 프로세스에서 동시 접근될 때 발생.
- db file sequential read: 인덱스 스캔을 수행할 때 발생하는 대기.
- db file scattered read: 전체 테이블 스캔 시 여러 블록을 읽을 때 발생하는 대기.
SELECT event, wait_class, total_waits, time_waited
FROM v$system_event
WHERE event LIKE '%buffer%';
5. 버퍼락 튜닝 방법
- AWR(Automatic Workload Repository) 리포트 분석
- 버퍼락 관련 경합이 있는지 확인.
buffer busy waits이벤트 발생 여부 체크.
- ASH(Active Session History) 활용sql복사편집
SELECT event, COUNT(*) FROM v$active_session_history WHERE event LIKE 'buffer busy waits' GROUP BY event; - INITRANS, PCTFREE 조정
INITRANS: 트랜잭션 동시성을 높이기 위해 값 증가.PCTFREE: 블록 내 여유 공간을 조정하여 동시 업데이트가 가능하도록 함.
🔹 결론
Oracle에서 버퍼락(Buffer Lock) 은 데이터 블록의 동시 접근을 관리하기 위한 중요한 메커니즘입니다. 하지만 동시성이 높은 환경에서는 버퍼락 경합(Buffer Lock Contention) 이 성능 저하를 유발할 수 있습니다. 이를 해결하려면 AWR/ASH 분석을 통한 튜닝, INITRANS/PCTFREE 조정, 파티셔닝 적용, 적절한 인덱스 전략 등이 필요합니다.
추가적으로 Row Lock이 있는데 왜 Buffer Lock을 해야 할까요?
간단히 요약해서 말씀드리자면,
Oracle은 블록 단위로 읽기 때문입니다. Row단위로 접근하여 수정 중에 다른 프로세스가 다른 목적으로 동일한 블럭에 접근해서 값을 수정하면 안되겠죠?
서로 다른 목적의 두가지 락에 대해 비교해보겠습니다.
🔹 Row Lock vs. Buffer Lock
| 특징 | Row Lock | Buffer Lock |
|---|---|---|
| 목적 | 특정 행의 변경 충돌 방지 | 데이터 블록의 동시 접근 관리 |
| 대상 | 개별 Row(행) | 데이터 블록(Buffer Cache의 블록) |
| 발생 조건 | 트랜잭션이 특정 행을 변경할 때 | 여러 세션이 같은 블록을 읽거나 변경할 때 |
| 잠금 해제 시점 | 트랜잭션이 종료되면 해제 (Commit/Rollback) | 블록 사용이 끝나면 즉시 해제 |
| 경합 원인 | 동일한 행을 여러 트랜잭션이 동시에 수정 | 특정 블록이 자주 접근되어 충돌 발생 |
🔹 Buffer Lock이 필요한 이유
- Row Lock만으로는 동시성을 완벽히 보장할 수 없음
- Row Lock은 트랜잭션 단위로 개별 행을 보호하지만, 여러 세션이 동시에 같은 데이터 블록을 읽고 쓸 경우 버퍼 충돌(buffer contention)이 발생할 수 있음.
- 여러 사용자가 같은 블록에 있는 서로 다른 행을 수정하면, Row Lock은 개별 행을 보호하지만 Buffer Lock이 없으면 같은 블록을 동시에 수정하려고 할 때 문제 발생.
- Oracle은 데이터 블록 단위로 데이터를 관리함
- Oracle은 데이터를 블록 단위로 캐시에 적재하고, 한 블록 안에 여러 개의 행이 들어갈 수 있음.
- 따라서, 동일한 블록을 여러 세션이 동시에 수정하려 하면 버퍼락을 사용하여 블록 수준에서 보호해야 함.
- I/O 효율성을 위해 블록 단위로 관리 필요
- Row Lock은 개별 행만 보호하기 때문에, 데이터 블록 내의 충돌 문제는 해결할 수 없음.
- 같은 블록을 읽거나 수정할 때, 버퍼락이 없으면 데이터 불일치가 발생할 수 있음.
- Redo/Undo 관리 및 일관성 유지
- Oracle의 Undo 관리는 데이터 블록 단위로 수행됨.
- 만약 트랜잭션이 같은 블록의 여러 행을 동시에 변경하면, Row Lock만으로는 관리가 어려우므로 Buffer Lock을 사용하여 블록 단위로 보호.
🔹 예제: Row Lock만 있을 때 발생하는 문제
가정:
- 세션 A와 세션 B가 같은 데이터 블록 안에 있는 서로 다른 행을 수정하려고 한다.
- Row Lock만 존재한다면, 각 세션은 각각의 행을 안전하게 수정할 수 있어야 한다.
-- 세션 AUPDATE employees SET salary = salary + 100 WHERE emp_id = 101;
-- 세션 B
UPDATE employees SET salary = salary + 200 WHERE emp_id = 102;
💡 문제점:
emp_id 101과emp_id 102가 같은 블록에 저장되어 있다면, Row Lock만으로는 해결할 수 없음.- 두 트랜잭션이 동시에 실행될 경우, Buffer Lock이 없으면 같은 블록을 수정하는 동안 데이터 불일치가 발생할 수 있음.
🔹 결론
Row Lock은 행 단위의 충돌을 방지하지만, Buffer Lock은 같은 블록 내에서의 충돌을 방지하는 역할을 합니다.
- Row Lock → 행 단위 보호
- Buffer Lock → 블록 단위 보호
따라서, Oracle은 Row Lock과 Buffer Lock을 함께 사용하여 데이터 무결성을 보장하고 성능을 최적화합니다. 🚀