티스토리 뷰

트랜젝션 (Transaction)

데이터베이스에서 사용하는 용어로 분할될 수 없는 작업 단위를 나타낸다. 분할될 수 없다는 말은 물리적으로 분할될 수 없다는 것이 아니라 논리적으로 분할하면 안된다는 의미로, 분할되어 실행될 시 시스템에 큰 타격을 줄 수 있다.

 

ATM기기에서 돈을 송금하는 작업을 예로 들어보자. 돈을 송금하여 내 계좌 데이터에서는 금액이 감소되었는데, 상대방 계좌 데이터를 증가시키는 부분에서 간섭이 일어나 증가가 안된다면 문제가 된다. 위 예에서 돈을 인출하는 명령(내 계좌에서 돈을 인출)과 돈을 입금하는 명령(상대 계좌에 돈을 입금)은 하나의 트랜잭션으로 묶여서 실행되어야 한다.

 

트랜젝션의 특성

트랜잭션이 신뢰를 가지기 위해 다음과 같은 특성을 가진다.

 

  1. 원자성(Atomicity)
    트랜잭션에 포함된 명령들은 모두 수행되거나, 모두 수행 안되어야 한다. 즉 어느 명령은 실행되고 어느 명령은 실행되지 않으면 안된다.
  2. 일관성(Consistancy)
    트랜잭션이 완료된 뒤에는 일관적인 상태에 있어야 한다. 트랜잭션의 영향이 한 방향으로만 전달되어야 한다.
  3. 고립성(Isolation)
    트랜잭션은 다른 트랜잭션과 독립적으로 실행되는 것 처럼 보여야 한다. 트랜잭션의 부분상태를 다른 트랜잭션에 제공해서는 안된다.
  4. 지속성(Durability)
    트랜잭션의 결과는 반드시 데이터베이스에 반영되어야 한다.

 

트랜젝션 상태

  1. Active : 트랜젝션의 시작.
  2. Partially Commited : 마지막 작업이 끝난 상태
  3. Failed :트랜젝션 작업 도중 어느 명령을 수행할 수 없게된 상태
  4. Aborted : 트랜젝션이 실패하여 다시 롤백된 상태. 트랜젝션을 다시 수행하거나 아예 무시해버리는 분기로 나뉠 수 있다.
  5. Commited : 모든 작업이 끝난 상태

 

스케줄 (schedule)

한 데이터베이스에서는 여러개의 트랜젝션이 동시(concurrency)에 수행되는데 이렇게 동시에 수행되는 트랜젝션이 같은 데이터에 접근하는 경우 그 수행순서에 따라 결과가 달라질 수 있는데 이 때 동시에 처리하는 순서를 스케줄(schedule)이라고 한다.

 

직렬성 (serializability)
어떤 트랜젝션 T1, T2가 어떤 스케줄로 실행되어도 각각 독립적으로 실행했을 때와 결과가 같은 성질

 

뷰 직렬 (view serializable)

스케줄이 바뀌어도 각 쿼리의 직렬성. 즉, 같은 값에 접근할 때 다음 조건을 충족하기만 하면 된다.

 

  1. 스케줄A에서 T1이 초기값을 읽었다면 스케줄B 에서도 T1이 초기값을 읽는다.
  2. 스케줄A에서 T1의 쓰기 -> T2의 읽기를 했다면 스케줄B 에서도 같은 순서로 실행되어야한다.
  3. 스케줄 A에서 마지막 쓰기를 T1이 했다면 스케줄B에서도 T1이 마지막 쓰기를 한다.

 

충돌 직렬 (conflict serializable)

스케줄이 바껴도 전체 트랜젝션의 결과가 동일하게 유지되는 것을 말한다. 뷰 직렬성과 달리 전체 결과가 동일하게 유지되어야하기 때문에 더 엄격한 규칙이라고 볼 수 있다. 두 트랜젝션이 공유하는 자원에 둘 다 쓰기만 한다면 충돌이 발생하지 않지만 어느 한 트랜젝션이라도 쓰기작업을 한다면 충돌이 발생한다. 충돌이라함은 그림처럼 순서가 달라졌을 때 결과가 달라지는 것을 뜻한다.

DBMS는 장애에 대한 고려도 필요하다. 다수의 트랜젝션이 한 값에 접근하다가 어느 트랜젝션에서 문제가 생겨 abort해야하는 경우 원만하게 복구되도록 해야하는데 이를 위해 다양한 스케줄을 사용한다.

 

recoverable schedule

T1이 값 A에 쓰기작업을 하고 T2가 A를 읽었다면 T1이 T2보다 먼저 commit되어야 복구가 가능하다. 값을 읽은 T2가 먼저 종료하고 T1이 abort된다면 완료된 T2를 복구하는 것이 불가능하기 때문이다. 따라서 recoverable schedule을 유지하려면 쓰기작업을 한 트랜젝션이 읽기작업을 한 트랜젝션보다 먼저 종료되어야 한다.

 

avoid cascading schedule

cascading rollback이 발생하지 않도록 각 트랜젝션은 commit이 완료된 값만 읽도록 한다. 따라서 어떤 값을 사용하고 있는 트랜젝션이 있다면 해당 트랜젝션이 종료(commit)될 때 까지 기다린다.

 

Cascading Rollback
어떤 트랜젝션이 abort될 때 연쇄된 다른 트랜젝션도 같이 rollback해야하는 경우를 말한다.

 

DBMS는 conflict serializabilityrecoverable schedule, avoid cascading schedule을 만족할 수 있도록 만들어져야한다.

'Non-Programming > Database' 카테고리의 다른 글

데이터베이스 - 오류 복구  (0) 2019.06.12
데이터베이스 - 동시성 제어 (Concurrency Control)  (0) 2019.05.28
SQL - subquery  (0) 2019.05.20
데이터베이스 정규화  (0) 2019.05.20
SQL - Sequence  (0) 2019.05.07
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함