DBMS :: Transaction (트랜잭션)

1. 정의

sql 묶음

하나의 논리적 작업 단위로 수행되는 일련의 연산 집합. DB 작업의 단위

다양한 데이터 항목들을 액세스하고 갱신하는 프로그램 수행의 단위가 됨

 

단일 쿼리로는 해결할 수 없는 로직을 처리할 때 필요한 기술

2개 이상의 퀴리를 하나의 Connection으로 묶어 DB에 전송하고 에러가 발생할시 원상태로 복구함 (All or Nothing)

 

한 개 이상의 쿼리에서 동일한 Connection 객체를 공유하게 되는데, 자바에서는 DB 연결시 java.sql.Connection 객체를 이용했던 반면 트랜잭션에서는 Connection autoCommit() 이라는 메소드가 존재하여 개발자가 직접 커넥션에 대해 커밋을 수동으로 관리할 수 있음 (autoCommit default : true)

=> 개발자가 직접 commit과 rollback을 자유자재로 조절 가능

 

* commit() : 해당 커넥션 요청을 완료한 후 에러가 없으면 그 결과를 DB에 반영하는 것

  rollback() : 해당 커넥션을 수행 중 에러가 발생할 시 모든 과정을 취소하고 DB를 커넥션 수행 전 상태로 변경하는 것

 

* Spring framework는 다이나믹 프록시 + AOP 기술을 사용하기 때문에 크게는 인터페이스 단위까지 트랜잭션을 컨트롤할 수 있음. 거기에 애노테이션 기술로 @Transaction을 설정하는 것 만으로 트랜잭션 설정을 가능하게 함

 

트랜잭션은 ACID 성질이라고 하는 4가지 조건으로 설명됨

 

 

2. 트랜잭션의 필수 조건 4가지 (ACID)

명칭	설명
원자성(Atomic)	- 더이상 분류할 수 없는 작업 단위여야 함  - 모든 데이터 수정 작업이 수행되거나, 하나도 수행되지 말아야 함
일관성(Consistency)	- 완료된 트랜잭션의 모든 데이터는 일관적이어야 함  - 관계형 DB에서는 트랜잭션 수정에 모든 규칙을 적용하여 모든 데이터 무결성을 유지해야 함  - 트랜잭션 마지막에는 B-tree 인덱스 또는 이중 연결 목록 등 모든 내부적 데이터 구조를 반드시 수정해야 함
독립성(Isolation)	- 동시 트랜잭션에 의한 수정은 다른 동시 트랜잭션에 의한 수정과 격리되어야 함  - 트랜잭션에서 다른 동시 트랜잭션이 수정하기 전 상태의 데이터를 보거나, 두번쨰 트랜잭션이 완료된 후의 데이터를 볼 수는 있으나 중간 상태는 볼 수 없음  => 결과적으로 시작 데이터를 다시 로드하고 일련의 트랜잭션을 재생하여 원래 트랜잭션이 수행된 후의 상태로 데이터를 되돌릴 수 있는데, 이를 순차성이라고 함
지속성(Durabillity)	- 트랜잭션 완료 후 그 영향이 영구적으로 시스템에 적용되어야 함  - 수정은 시스템에 오류가 발생한 경우에도 지속됨

 

 

3. DBMS 구성

ㄱ. 질의 처리기 (Query Processor) : 상부 구성.

ㄴ. 저장 시스템 (Storage System) : 하부 구성. MySQL의 경우 InnoDB/MyISM 등과 같이 여러 하부 저장 시스템

선택 가능

 

* MySQL : 상부의 질의 처리기와 하부의 저장 시스템이 명확하게 구분되는 계증 구조에 해당됨

 

 

4. 트랜잭션이 종료되는 경우

ㄱ. 쿼리가 정상으로 수행되어 commit을 통해 종료되는 경우

ㄴ. 잘못된 입력 or 일관성 제약 조건 위배 등 사용자 요청에 의해 철회되는 경우

ㄷ. time out or 교착 상태 등 시스템이 감지하는 문제로 DBMS가 철회되는 경우

 

DB 시스템은 비휘발성 저장 장치인 디스크에 데이터를 저장하며, 전체 DB의 일부분을 메인 메모리에 유치시킴

DBMS는 데이터를 고정 길이의 페이지로 저장하며 디스크에서 읽거나 쓸 때 페이지 단위로 입출력이 이루어짐

 

메인 메모리에 유치되는 페이지들을 관리하는 모듈을 페이지 버퍼(Page buffer) 또는 관리자 버퍼라 부르는데, DBMS의 주요 모듈 중 하나임

 

 

5. 트랜잭션 복구시 버퍼 관리 정책

종류	설명
UNDO 복구	- 해당 트랜잭션이 어떤 이유든 정상적으로 종료할 수 없게 되면 트랜잭션이 변경했던 페이지들이 그 이전 상태로 원상 복구되는 것  - STEAL / -STEAL 2가지가 존재함
REDO 복구	- UNDO 복구의 반대  - 커밋한 트랜잭션 수정은 어떤 경우에도 유지되어야 함  - 이미 commit한 트랜잭션의 수정을 재반영하는 복구 작업  - FORCE / -FORCE 2가지가 존재함

DBMS는 버퍼 관리 정책으로

UNDO 복구의 STEAL : 수정된 페이지를 언제든지 디스크에 쓸 수 있음

REDO 복구의 -FORCE : 수정했던 페이지를 트랜잭션 commit 시점에서 디스크에 반영하지 않음

두 개를 채택하고 있어 UNDO + REDO 복구 두 가지가 모두 다 필요함

 

 

6. 로그 (Log)

UNDO 복구와 REDO 복구를 사용하기 위해 가장 널리 쓰이는 구조

로그는 로그 레코드의 모음으로 이루어짐. DB의 모든 갱신 작업을 기록함. 이론적으로는 가장 안정적인 저장 매체에 기록됨

 

로그는 덧붙이는(append) 방식으로 기록되며, 각 로그 레코드는 고유 식별자를 가짐

항상 뒤에 덧붙이는 방식으로 쓰이기 때문에 로그 식별자는 단조 증가함

 

* 레코드 고유 식별자 : LSN (Log Sequence Number) or LSA (Log Sequence Address)로 불림

 

기록할 Object 타입에 따라 물리적 / 논리적 로깅으로 분류됨

 

* 물리적 상태 로깅 (Physical State Logging) : DBMS에서 가장 널리 쓰이는 기본적인 로깅 방법

* 로그 버퍼 : DBMS가 로그 레코드 관리를 위해 유지하는 별도의 버퍼

성능을 위해 로그 버퍼에 로그 레코드를 모았다가, block 단위로 로그 파일에 출력함

 

* 더티 페이지 (Dirty Page)

- 데이터 캐시에서는 변경되었지만 데이터 파일 (*.mdf)에서는 아직 변경되지 않은 데이터(페이지)

- 더티 페이지가 데이터 파일에 성공적으로 적용된 후 체크포인트가 설정됨