[버퍼 Lock]
A. 로우 Lock의 대상 로우가 달라도 Block이 동일하면 직렬화될 수 있다.
정확히는 로우 Lock 자체가 Block 단위로 직렬화되는 것은 아니다.
서로 다른 로우를 UPDATE하더라도 같은 Block에서 동시에 여러 트랜잭션이 변경을 수행할 수 있다.
하지만 하나의 Block에서 동시에 여러 트랜잭션이 변경하고, Block Header의 ITL(Interested Transaction List) 공간이 부족하면 ITL 경합이 발생하여 트랜잭션이 대기할 수 있다.
즉,
서로 다른 로우를 변경하더라도 같은 Block의 ITL이 부족하면 트랜잭션 간 대기가 발생할 수 있다.
[Redo]
A. Instance Crash 발생 후 데이터베이스 동기화
Last CheckPoint 이후부터 사고 발생 직전까지 Redo 로그로 복구
Roll Forward
- Buffer Cache에서 수정되었지만 Datafile에 반영되지 않은 Dirty Block의 변경사항을 복구
- 커밋 여부와 관계없이 Redo에 기록된 변경사항을 적용
Undo를 활용해 커밋되지 않은 트랜잭션 롤백
Roll Back
Roll Forward 과정에서 커밋되지 않은 변경사항까지 적용될 수 있기 때문에 Undo를 활용해 커밋되지 않은 트랜잭션의 변경사항을 되돌린다.
Q. Dirty Block이 DB File에 저장되면 Archive Redo Log는 삭제해도 되는 것 아닌가?
현재 Datafile에 변경사항이 반영되었다고 해서 Archive Log가 더 이상 필요하지 않은 것은 아니다.
DB Backup은 특정 시점의 Datafile을 저장한 것이다.
예를 들어,
월요일 02:00
↓
Full DB Backup
↓
월요일 ~ 화요일
↓
데이터 변경
↓
화요일 10:00
↓
Datafile Media Failure
월요일 02:00의 Backup Datafile을 복원하면 DB는 월요일 02:00 상태가 된다.
따라서 월요일 02:00 이후의 변경사항을 복구하기 위해 Archive Log가 필요하다.
Backup Datafile
+
Archive Log
↓
Backup 이후 변경사항 적용
↓
장애 시점까지 복구
Archive Log는 Datafile에 아직 반영되지 않은 데이터를 보관하기 위한 것이 아니라, 과거 Backup 이후 발생한 변경사항을 복구하기 위한 변경 이력이다.
ARCHIVELOG 모드에서는 Online Redo Log가 재사용되기 전에 해당 로그 그룹의 내용을 Archive Log로 보존한다.
Q. Media Failure는 쓰기 작업이 완료된 DB가 깨지는 것인가?
Media Failure는 Datafile 자체가 손상되거나 유실되는 상황을 의미한다.
예를 들어 디스크나 스토리지 장애로 Datafile이 손상되거나 사라질 수 있다.
이 경우 Backup Datafile을 복원한 후 Archive Log 등을 적용하여 장애 발생 시점에 가깝게 복구한다.
Backup Datafile 복원
↓
Archive Log 적용
↓
필요한 Redo 적용
↓
Media Recovery
따라서 DB에 쓰기 작업이 완료된 데이터라도 Datafile을 저장하고 있는 디스크나 스토리지 자체에 문제가 발생하면 데이터가 유실될 수 있다.
[Undo]
A. MVCC 모델이란?
Oracle은 Undo 메커니즘을 이용해 읽기 일관성(Read Consistency)을 제공한다.
Consistent Read 시 Query의 SCN과 Block의 SCN을 비교하여 Block의 변경 시점이 Query의 기준 시점보다 최신이라면 Undo를 활용해 이전 버전의 데이터를 읽는다.
트랜잭션이 오래 지속될수록 해당 트랜잭션이 필요로 하는 과거 버전의 Undo가 다른 트랜잭션에 의해 재사용될 가능성이 높아지고, 필요한 Undo가 사라진 경우 Snapshot Too Old가 발생할 수 있다.
A. Oracle UPDATE는 Consistent 모드로 읽고 Current 모드로 UPDATE한다.
UPDATE 대상 로우를 찾는 과정에서는 Consistent Read를 사용하고, 실제 변경은 Current Block에서 수행한다.
[블록 클린아웃]
A. Fast Block Cleanout
- Oracle 7.3 : Commit Cleanout 도입
- Oracle 9i : 변경된 Block이 Buffer Cache의 1/10 이하인 경우 Fast Block Cleanout 수행
- Oracle 10g : Fast Block Cleanout 이후 Full Cleanout을 최대한 지연하도록 변경
B. Delayed Block Cleanout
커밋 시점에 모든 변경 Block을 정리하지 않고, 이후 해당 Block에 접근할 때 Cleanout 수행
- 대량의 Block 변경 시 발생할 수 있음
- 이후 다른 세션이 해당 Block에 접근하면서 Cleanout 수행
[Snapshot Too Old]
Undo 세그먼트 자체가 단순히 작아서 발생한다기보다는, 장시간 실행되는 Query가 필요로 하는 과거 버전의 Undo가 재사용되어 더 이상 존재하지 않을 때 발생할 수 있다.
회피 방법
AUM(Automatic Undo Management)
AUM을 사용하면 Oracle이 Undo Segment를 자동으로 관리한다.
Undo Tablespace의 자동 확장
Undo Tablespace의 Datafile을 AUTOEXTEND로 설정하면 공간이 부족할 때 Oracle이 Datafile을 자동으로 확장할 수 있다.
다만 MAXSIZE는 DBA가 설정한 범위 내에서 적용된다.
UNDO_RETENTION
UNDO_RETENTION은 Undo Tablespace의 최대 크기를 설정하는 값이 아니라, Undo를 최소한 해당 시간 동안 유지하려고 시도하는 기준값이다.
따라서 UNDO_RETENTION을 크게 설정하는 것만으로 Snapshot Too Old가 반드시 해결되는 것은 아니다.
실제 Undo가 얼마나 오래 유지될 수 있는지는 Undo Tablespace의 크기, Undo 생성량, 장시간 실행되는 Query 등에 영향을 받는다.
애플리케이션 구현 측면
- 불필요하게 COMMIT을 자주 수행하지 않는다.
- Fetch Across Commit 패턴을 주의한다.
- 장시간 수행되는 Query를 가급적 줄인다.
- 대량 UPDATE 이후 Full Scan을 수행하면 변경된 Block을 다시 접근하면서 Delayed Block Cleanout이 발생할 수 있음을 고려한다.
[꿀팁]
Archive Log는 현재 DB의 변경사항을 저장하는 용도가 아니다.
Datafile에 이미 변경사항이 반영됐더라도 Archive Log가 필요할 수 있다.
Backup은 특정 시점의 DB 상태를 저장한 것이기 때문에, Backup 이후 발생한 변경사항을 복구하려면 Archive Log가 필요하다.
따라서 Archive Log를 삭제할 때는 현재 Datafile에 데이터가 반영됐는지가 아니라 해당 Archive Log를 필요로 하는 Backup과 복구 정책이 있는지를 먼저 확인해야 한다.
Media Failure는 DB의 논리적인 문제가 아니라 저장장치의 문제다.
트랜잭션이 정상적으로 COMMIT되어 Datafile에 데이터가 저장됐더라도, Datafile 자체가 손상되거나 유실되면 해당 데이터에 접근할 수 없다.
Backup + Archive Log를 통해 복구할 수 있도록 준비하는 것이 중요하다.
Snapshot Too Old는 Undo 공간만 늘린다고 무조건 해결되는 문제가 아니다.
장시간 수행되는 Query와 많은 Undo 발생량이 함께 존재하면 필요한 과거 버전이 재사용될 가능성이 높아진다.
따라서 Undo Tablespace 크기나 UNDO_RETENTION뿐만 아니라 장시간 Query, 불필요한 COMMIT, Fetch Across Commit 같은 애플리케이션 동작까지 함께 봐야 한다.