[DB] 트랜잭션(Transaction)

개념

트랜잭션(Transaction)은 데이터베이스의 상태를 변화시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 하는 일련의 연산을 의미한다.

1. 트랜잭션은 데이터베이스 시스템에서 병행 제어 및 회복 작업 시 처리되는 작업의 논리적 단위이다.
2. 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업단위이다.
   • 상태변화 : SQL질의어(SELECT | INSERT | UPDATE | DELETE)를 통해 DB에 접근하여 데이터베이스 상태가 변화하는 것
   • 작업 단위 : 일련의 연산(SQL 명령문 집합). 사람이 정하는 기준(하나의 논리적 기능을 수행하기 위한)에 따라 정의함

하나의 트랜잭션 설계를 잘 만드는 것이 데이터를 다룰 때 많은 이점을 가져다준다.

Lock 과 트랜잭션

Lock
- 여러 Connection에서 동시에 동일한 자원을 요청할 경우, 한 시점에 하나의 Connection만 변경할 수 있도록 해주는 역할
- 동시성 제어
트랜잭션
- 하나의 논리적인 작업 셋 자체가 100% 적용되거나 아무것도 적용되지 않아야함을 보장
- 데이터의 정합성을 보장

 

트랜잭션 특징(ACID)

• 원자성(Atomicity)
  • 트랜잭션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 된다. (= 하나의 트랜잭션은 Commit되거나 Rollback된다.)
  • Commit : 하나의 트랜잭션에 속하는 쿼리문 모두 성공적으로 완료되어야만 하나의 작업(트랜잭션)이 완료되는 것이다.
  • Rollback : 작업 단위에 속하는 쿼리 중 하나라도 실패하면 모든 쿼리문을 취소하고 이전 상태로 돌려놓아야 한다.
  • 회복
• 일관성(Consistency)
  • 트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다.
  • 동시성 제어
• 독립성(Isolation)
  • 둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다.
  • 동시성 제어
• 지속성(Durability)
  • 트랜잭션이 성공적으로 완료되었으면, 결과는 영구적으로 반영되어야 한다.
  • 회복

 

연산

하나의 트랜잭션은 Commit 되거나 Rollback 되어야 한다.

Commit

하나의 트랜잭션이 성공적으로 끝났고, DB가 일관성있는 상태일 때 트랜잭션이 행한 연산이 완료된 것을 트랜잭션 관리자에게 알려주기 위해 사용하는 연산

Rollback

하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 트랜잭션의 일부가 정상적으로 처리되었더라도, 원자성을 구현하기 위해 이 트랜잭션이 행한 모든 연산을 취소(Undo)하는 연산이다.

transaction이 정상적으로 종료되지 않았을 때, last consistent state(ex. 트랜잭션의 시작 상태)로 Rollback 할 수 있음.

트랜잭션 내에서 에러가 발생했을 경우 rollback,
시스템 오류와 같은 트랜잭션 외부 요인으로 인해 에러가 발생했을 경우 회복을 한다.

 

트랜잭션의 상태

트랜잭션 상태 다이어그램(출처 : https://d2.naver.com/helloworld/407507)

• 활동(Active) : 트랜잭션이 실행중인 상태
• 실패(Failed) : 트랜잭션 실행에 오류가 발생하여 중단된 상태
• 철회(Aborted) : 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태
• 부분 완료(Partially Committed) : 트랜잭션의 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태
• 완료(Committed) : 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태

 

트랜잭션 시 주의할 점

• 데이터베이스 Connection 개수가 제한적이기 때문에 트랜잭션의 범위를 최소화해야 한다.
• Conntection을 소유하는 시간이 길어질수록 사용 가능한 Connection 수는 줄어든다.

교착상태

두 개 이상의 트랜잭션이 특정 자원의 잠금을 획득한 채 다른 트랜잭션이 소유하고 있는 잠금을 요구하여 아무리 기다려도 상황이 바뀌지 않는 상태

교착상태의 빈도를 낮추는 방법

• 트랜잭션을 자주 Commit
• 정해진 순서대로 테이블에 접근
  • 트랜잭션 1 이 테이블 B -> A 의 순으로 접근했고, 트랜잭션 2 는 테이블 A -> B의 순으로 접근했다. 트랜잭션들이 동일한 테이블 순으로 접근하게 한다.
• 읽기 잠금 획득(SELECT ~ FOR UPDATE) 사용을 피함
• 테이블 단위의 잠금을 획득해 갱신을 직렬화
  
  • 한 테이블의 복수 행을 복수의 연결에서 순서 없이 갱신하면 교착상태가 발생하기 쉽다, 이 경우에는 테이블 단위의 잠금을 획득해 갱신을 직렬화 하면 동시성을 떨어지지만 교착상태를 회피할 수 있다.

[DB] 트랜잭션 격리 수준(Transaction Isolation Level)

 

DBMS의 구조

DBMS 구조(출처 : https://mangkyu.tistory.com/19, https://gyoogle.dev/blog/computer-science/data-base/Transaction.html)

크게 질의 처리기(Query Processor)와 저장 시스템(Storage System) 두 가지로 나뉜다.

• 입출력 단위는 고정 길이의 페이지(Page)단위로 디스크를 읽거나 쓴다.
• 저장 공간은 비휘발성 저장 장치인 디스크로 일부분은 Main Memory에 저장한다.

Buffer 관리 정책

DBMS의 저장 시스템(Storage System)에 속하는 모듈 중 하나로, Main Memory에 유지하는 페이지를 관리하는 모듈

• Page Buffer Manager
• Buffer Manager

Buffer 관리 정책에 따라 undo 복구와, redo 복구가 요구되거나 그렇지 않게 되므로 transaction 관리에 매우 중요한 결정을 가져온다.

 

회복(복구방법)

시스템 오류와 같은 트랜잭션 외부 요인으로 인해 에러가 발생했을 경우에 회복을 한다.
시스템 오류 또는 물리적인 문제를 실패(failure)라고 한다.

UNDO : 원상태로 되돌림

정상적으로 종료되지 않은 transaction이 변경한 page들은 원상 복구 되어야 하는데, 이 복구를 undo라고 한다.

Buffer 교체는 transaction과는 무관하게 Buffer의 상태에 따라 결정되기 때문에 수정된 Page가 Buffer 교체 알고리즘에 따라서 디스크에 출력될 수 있음.
∴ undo로 복구

수정된 페이지를 디스크에 쓰는 시점으로 분류

• STEAL : 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
  • UNDO 작업이 필요하지 않지만, 매우 큰 메모리 버퍼가 필요함.
• ¬STEAL : 수정된 페이지들을 EOT (End Of Transaction)까지는 버퍼에 유지하는 정책
  • 대부분의 DBMS가 채택하는 Buffer 관리 정책
  • UNDO logging과 복구를 필요로 함.

• 사용자가 했던 작업을 반대로 진행해 원상태로 되돌린다.

REDO : 재반영

이미 commit한 transaction의 수정을 재반영하는 복구 작업

Buffer 관리 정책에 영향을 받는다.

Transaction이 종료되는 시점에 해당 transaction이 수정한 page를 디스크에 쓸 것인가 아닌가로 분류

• FORCE : 수정했던 모든 페이지를 Transaction commit 시점에 disk에 반영
  • transaction이 commit 되었을 때 수정된 페이지들이 disk 상에 반영되므로 redo 필요 없음.
• ¬FORCE : commit 시점에 반영하지 않는 정책
  • transaction이 disk 상의 db에 반영되지 않을 수 있기에 redo 복구가 필요.
  • 대부분의 DBMS 정책

• 이전 상태로 되돌아간 후, 실패가 발생하기 전까지의 과정을 그대로 따라가는 것을 의미한다.
• redo를 하기 위해서는 정상적으로 실행 되기까지의 과정을 기록해야 하는데, 이를 log라고 한다.

Check Point

• check point로 설정한 지점 이전 까지는 트랜잭션이 성공적으로 수행이 돼서 disk에 확실히 저장된 상태를 의미한다.
• check point를 설정하는 이유는 시스템을 회복하기 위해 되돌아갈 때, 너무 많이 되돌아가지 않도록 하기 위함입니다.
• 만약 실패가 발생하여 회복을 할 때 check point가 설정되어 있다면, redo는 check point 시점부터 log를 따라가면서 트랜잭션을 수행하지만, undo는 log를 따라가지 않고 트랜잭션을 재수행 한다.

예시

• 시스템 장애가 발생하면, undo 데이터도 모두 날아간다.
• 결국 redo 데이터를 이용해서 마지막 Check Point부터 장애까지 DB Buffer Cache를 복구하게 된다.
• 복구가 완료되면 undo를 이용하여 Commit 되지 않은 데이터를 모두 Rollback함으로써 복구를 완료하게 된다.
• 결국 Redo가 Undo를 복구하고 최종적으로 Undo가 복구를 하게 된다.

• 트랜잭션 T1
  • check point 이전에 실행이 완료되었으므로 failure 되더라도 이미 disk에 저장이 된 상태이므로 회복을 하지 않습니다.
• 트랜잭션 T2
  • check point 이전에 실행된 내용은 disk에 반영이 되었으므로 check point 이후의 내용을 log를 따라가는 redo를 수행한다.
• 트랜잭션 T3
  • failure 시점에 실행중이였으므로 check point 시점으로 undo한 후, 트랜잭션을 재실행한다.
• 트랜잭션 T4
  • check point 이후에 실행됐고 failure 시점 전에 실행이 끝났으므로 redo를 수행한다.
• 트랜잭션 T5
  • check point 이후에 실행됐고 failure 시점에 실행중이였으므로 시작지점까지 undo한 후, 트랜잭션을 재실행

 

참고

• gyoogle.dev/blog/computer-science/data-base/Transaction.html
• coding-factory.tistory.com/226
• brownbears.tistory.com/181
• d2.naver.com/helloworld/407507
• https://dheldh77.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98Transaction
• https://victorydntmd.tistory.com/130