트랜잭션은 무엇인가?
트랜잭션은 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위, 또는 한꺼번에 모두 수행되어야 할 일련의 연산들을 의미한다.
ACID
데이터베이스 내에서 일어나는 하나의 트랜잭션의 안정성을 보장하기 위해 필요한 네 가지 성질이다.
- Atomocity (원자성)
- 한 트랜잭션의 연산들이 모두 성공하거나, 모두 실패되는 성질
- 하나의 단위로 묶여있는 여러 작업이 부분적으로 실행된다면, 데이터가 오염될 수 있음
- Consistency (일관성)
- 데이터베이스의 상태가 일관되어야 한다는 성질
- 트랜잭션 이전과 이후, 데이터베이스의 상태는 이전과 같이 유효해야 한다.
- Isolation (고립성)
- 모든 트랜잭션은 다른 트랜잭션으로부터 독립되어야 한다는 성질
- Durability (지속성)
- 트랜잭션이 성공적으로 완료되어 커밋되고 나면, 해당 트랜잭션에 의한 모든 변경은 향후에 어떤 소프트웨어나 하드웨어 장애가 발생되더라도 보존되어야 한다.
트랜잭션 종료
트랜잭션은 세 가지중 하나의 형태로 종료된다.
- 문제없이 정상적으로 수행된 경우
- 잘못된 입력, 일관성 제약조건 위배 또는 사용자의 요청에 의하여 철회되는 경우
- 타임 아웃, 교착 상태 등 시스템이 감지하는 문제로 인하여 DBMS가 철회하는 경우
DBMS는 이와 같은 상황에서 트랜잭션을 관리해야 한다.
트랜잭션 관리를 위한 DBMS의 전략
DBMS 구조
DMBS는 저장 시스템과 질의 처리기로 구분된다. 저장 시스템은 비휘발성 저장 장치이며 전체 DB의 일부분을 메인 메모리에 유지한다.
DBMS는 데이터를 고정 길이의 페이지로 저장한다. 페이지 단위로 입출력이 이루어지며 메인 메모리에 유지하는 페이지들을 관리하는 모듈을 페이지 버퍼 관리자라고 한다.
버퍼 관리 정책이 트랜잭션 관리에 중요한 결정을 가져온다.
UNDO의 필요성
DBMS에서는 여러 트랜잭션이 동시에 실행되며 데이터를 수정한다. 오퍼레이션 수행 중에 수정된 페이지들이 버퍼 관리자의 버퍼 교체 알고리즘에 따라서 디스크에 출력될 수 있다. 즉, 아직 완료되지 않은 트랜잭션이 수정한 페이지들도 디스크에 출력될 수 있다. 만약 해당 트랜잭션이 비정상적으로 종료되면 트랜잭션이 변경한 페이지들은 원상 복구되어야 한다. 이러한 복구를 UNDO라고 한다.
만약 버퍼 관리자가 트랜잭션 종료 전에는 수정된 페이지들을 디스크에 쓰지 않는다면, UNDO 오퍼레이션은 메모리 버퍼에 대해서만 이루어지면 되므로 매우 간단해질 수 있다. 이 부분은 매력적이지만 이 정책은 매우 큰 크기의 메모리 버퍼가 필요하다는 문제점을 가지고 있다.
수정된 페이지를 디스크에 쓰는 시점을 기준으로 다음과 같은 두 개의 정책으로 나누어 볼 수 있다.
STEAL: 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
¬STEAL: 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT)까지는 버퍼에 유지하는 정책
대부분의 DBMS는 STEAL 정책을 채택하고 있다. 이는 수정된 페이지가 어느 시점에도 디스크에 반영될 수 있기 때문에 필연적으로 UNDO 로깅과 복구를 수반한다.
REDO의 필요성
REDO 복구는 트랜잭션의 커밋 시점 이후에 변경된 데이터를 다시 적용하는 작업을 의미한다. 트랜잭션은 커밋 시점에서 영구적으로 저장되어야 하므로, 커밋한 트랜잭션의 변경 내용이 디스크에 반영되지 않은 경우에도 효과적으로 데이터를 복구하고 일관성을 유지하기 위해 사용된다.
트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 페이지들을 디스크에도 쓸 것인가 여부로 두 가지 정책이 구분된다.
💡 `¬FORCE` 정책은 수정된 페이지를 디스크에 반영하지 않으나 로그는 기록한다 💡 디스크 반영은 페이지 버퍼 관리자의 버퍼 관리 정책에 의해 수행된다!
FORCE: 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
¬FORCE: 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책
¬FORCE 정책을 따른다면 커밋한 트랜잭션의 내용이 디스크 상의 데이터베이스 상에 반영되어 있지 않을 수 있기 때문에 반드시 REDO 복구가 필요하다.
트랜잭션 관리
💡 DBMS는 STEAM과 ¬FORCE 정책을 채택하고 있고, UNDO와 REDO가 모두 필요하다!UNDO와 REDO를 위해 가장 널리 쓰이는 구조는 로그(Log)이다.
로그는 로그 레코드의 연속이며 DB의 모든 갱신 작업을 기록한다. 대부분 DBMS는 성능 상의 이유로 하나의 로그를 유지한다.
로그는 덧붙이는(append)방식으로 기록되며, 각 로그 레코드는 고유의 식별자를 가진다. 로그 레코드의 식별자를 LSN(Log Sequence Number) 혹은 LSA(Log Sequence Address)라고 부른다.
Log entry
각각의 로그에는 다음과 같은 내용들이 저장된다.
- Transaction ID
- Object ID
- 이전 값 (Undo에 사용된다)
- 바뀐 값 (Redo에 사용된다)
로그들은 메모리 영역에 저장되었다가 나중에 실제 로그 파일에 쓰여질 수 있다.
UNDO vs ROLLBACK
💡 `UNDO`는 DBMS 상에서 일관성 유지를 위해 자동으로 실행되는 것ROLLBACK은 사용자의 요청에 따라 특정 시점으로 되돌아가는 것
UNDO는 데이터베이스 관리 시스템(DBMS) 내부에서 자동으로 실행되는 작업으로, 트랜잭션의 일관성을 유지하기 위해 사용된다. 트랜잭션이 중단되거나 문제가 발생할 경우, DBMS는 UNDO 로그를 사용하여 해당 트랜잭션의 변경 내용을 원래 값으로 복구하여 데이터의 일관성을 보장한다.
ROLLBACK은 사용자가 명시적으로 요청하여 특정 트랜잭션을 취소하고 이전 상태로 되돌리는 작업을 말한다. 사용자가 원할 때 특정 트랜잭션을 중단하거나 취소하고자 할 때 ROLLBACK 명령을 사용하여 이전 상태로 데이터를 복원할 수 있다. 이는 사용자가 조작하는 명령어로, 특정 시점으로 되돌아가는 것을 가능하게 해준다.
