[DB] 트랜잭션(개념/특성/연산/상태)

트랜잭션이란?

데이터베이스의 상태를 변화시키기 위해서 수행하는 작업의 최소 단위를 뜻한다. 여기서 작업의 단위는 질의어 한 문장을 뜻하는 것이 아니며, 이 작업 단위는 쪼개질 수 없다. 간단히 말해 여러 개의 질의어들이 묶인 작업의 한 단위를 의미하는데, 이 단위만큼 DB에 명령을 한 번에 반영한다.

예를 들어 A가 B에게 송금하는 경우를 생각해보자. A가 B에게 일정 금액을 송금했을 때, 정상적으로 송금이 완료되면 A의 계좌에서 해당 금액이 차감되고, B에 계좌에는 같은 금액이 추가되어야 한다. 이를 질의어로 표현해보면 아래와 같다.

-- A 계좌에서 금액 차감
UPDATE 계좌
SET 잔액 = 잔액 - 10000
WHERE 이름 = 'A';

-- B 계좌에 금액 추가
UPDATE 계좌
SET 잔액 = 잔액 + 10000
WHERE 이름 = 'B';

위와 같이 두 가지의 질의어를 ‘송금’이라는 하나의 작업단위로 정하게 되면 이 작업 단위가 하나의 트랜잭션이 된다. A 계좌에서 금액이 차감되고 B 계좌에 금액이 추가되지 않으면 안되기 때문에 이 트랜잭션은 더 이상 쪼갤 수 없다.
*트랜잭션은 논리적 작업 단위(LUW, Logical Units of Work)라고 불리기도 함

 

트랜잭션의 특성(ACID)

이론적으로 데이터베이스 시스템은 각 트랜잭션의 안정성을 위해  원자성, 일관성, 독립성, 영구성을 보장한다. (그러나, 실제로는 성능향상을 위해 이런 특성들이 종종 완화되기도 한다.)

 

원자성(Atomicity)

"트랜잭션의 연산은 데이터베이스에 모두 반영되든지 아니면 전혀 반영되지 않아야 한다."
위에서 든 트랜잭션의 예시처럼 트랜잭션은 쪼갤 수 없는 성질을 가져야 한다는 것이 원자성을 보장하는 것이다. (송금 트랜잭션 수행 시 한쪽 계좌 금액을 차감했으면, 다른 한쪽 계좌 금액 반드시 추가) 트랜잭션 내의 모든 쿼리는 완벽히 수행되어야 하며, 만약 하나의 쿼리라도 정상적으로 종료되지 않았다면, 트랜잭션 내의 모든 쿼리가 취소되어 트랜잭션을 수행하지 않았던 시점으로 돌아가야 한다.

 

일관성(Consistency)

"트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다."
여기서 말하는 일관성이란 데이터베이스의 제약이나 규칙을 뜻한다. 트랜잭션의 수행을 통해 DB가 변한 후에도 트랜잭션 실행 이전의 제약이나 규칙을 그대로 따라야 한다. 예를 들어 위의 송금 트랜잭션에서 접근한 ‘계좌’ 테이블은 ‘잔액은 항상 양의 정수이어야 한다.’라는 제약 조건이 있다고 가정하자. 그렇다면 송금 트랜잭션이 수행된 후의 잔액도 양의 정수이어야 한다. 따라서 송금하는 계좌에 잔액이 송금하려는 금액보다 작다면 트랜잭션을 수행하지 못하게 하는 등의 조건을 통해 일관성을 보장한다.

 

독립성(Isolation)

"모든 트랜잭션은 다른 트랜잭션으로부터 독립되어야 한다."
동시에 여러 트랜잭션이 수행될 때, 모든 트랜잭션들은 다른 트랜잭션에 끼어들 수 없고 트랜잭션 중간 단계의 데이터를 참조할 수 없다. 이 성질로 인해 동시에 여러 트랜잭션을 수행될 때, 각 트랜잭션들이 순차적으로 하나씩 실행된 것과 같은 결과를 나타낸다. 즉, 동시에 같은 데이터에 접근했을 때 하나의 트랜잭션이 완료될 때까지 다른 트랜잭션의 요청을 막아 데이터 무결성을 보장한다. 만약 잔액이 10000원인 A의 계좌에 대해 8000원 5000원 송금을 요청하는 두 가지 트랜잭션이 동시에 수행되어야 한다면, 두 트랜잭션이 하나씩 수행되는 결과와 같게 된다. 즉, 8000원이 먼저 송금되고 잔액이 2000원이 된 계좌에 5000원 송금을 요청한 결과와 같게 된다. (두 번째 트랜잭션은 일관성 문제 때문에 수행되지 못할 것이다.)
  독립성은 나머지 성질들과 비교했을 때 가장 유연성이 있는 제약조건이다. 왜냐하면 독립성을 완전히 보장하려면 각 트랜잭션을 하나씩 순서대로 처리해야 하기 때문에 동시성 성능을 떨어뜨리기 때문이다. 따라서 정도에 따라 여러 단계로 나누어져 있는 독립성을 이해하고 상황에 맞게 적용한다.

*트랜잭션의 독립성 레벨 보기

 

영구성(Durability)

"트랜잭션이 성공적으로 완료되었을 경우 그 결과는 영구적으로 반영되어야 한다."
만약 시스템 문제 등으로 인해 오류가 발생하더라도 이전에 완료된 트랜잭션의 결과는 영원히 반영되어야 한다. 이를 구현하기 위해 로그를 남기는 방식을 사용한다. 트랜잭션이 성공적으로 수행되었다면 그에 대한 로그를 남겨야 하며, 만약 로그를 남기기 전에 오류로 인해 시스템이 종료된다면 해당 트랜잭션은 실패로 돌아가고 수행하기 이전으로 돌아가야 한다.

 

 

https://mangkyu.tistory.com/30

                 DBMS는 원자성을 유지하기 위해 회복 관리자 프로그램 작동시킴
                 DBMS는 일관성을 유지하기 위해 동시성 제어 알고리즘과 무결성 제약조건을 활용함
                 DBMS는 독립성을 유지하기 위해 동시성 제어 알고리즘을 작동시킴
                 DBMS는 지속성을 유지하기 위해 회복 관리자 프로그램을 이용함

 

 

트랜잭션 연산

commit
하나의 트랜잭션이 성공적으로 실행되어 정상적으로 종료되었을 때, 데이터베이스의 일관된 상태를 확인하고 DB 갱신 연산이 완료되었음을 명시하는 연산이다. commit 연산을 통해 결과를 최종적으로 DB에 반영한다.

rollback
하나의 트랜잭션이 비정상적으로 종료되어 데이터베이스의 일관성이 깨진 상태일 때, 트랜잭션의 원자성을 보장하기 위해 해당 트랜잭션의 모든 연산을 취소하고 실행하기 이전의 상태로 돌리는 연산을 말한다.

 

트랜잭션의 상태

• 활성화(Active)
    : 트랜잭션이 작업을 시작하여 실행 중인 상태
• 실패(Failed)
    : 트랜잭션에 오류가 발생하여 실행이 중단된 상태
• 철회(Aborted)
    : 트랜잭션이 비정상적으로 종료되어 Rollback연산을 수행한 상태
• 부분 완료(Parially committed)
    : 트랜잭션이 마지막 연산까지 실행하고 commit 요청이 들어온 직후의 상태(DB에 최종 결과 미반영)
• 완료(committed)
    : 트랜잭션이 성공적으로 종료되어 commit연산을 한 후의 상태(DB에 최종 결과 반영)

 

트랜잭션 복구(recovery)

DBMS는 트랜잭션 수행 도중 오류가 발생하거나 사용자의 요청으로 인해 트랜잭션이 철회된 경우, 복구 작업을 수행한다. 여기서 복구란 데이터베이스를 장애 발생 이전의 일관된 상태로 복원하는 것을 말한다. DBMS에서는 회복 관리자(Recovery Management)가 장애 발생을 탐지하고 데이터베이스를 복구하는 기능을 제공한다. 

💡 DB 장애 3가지 유형
트랜잭션 장애: 트랜잭션 내의 논리적 오류나 시스템 내의 자원 부족 등으로 인해 트랜잭션이 중단된 경우
시스템 장애: 정전이나 하드웨어 결함으로 인해 정상적인 수행을 계속할 수 없는 경우
미디어 장애: 디스크와 같은 저장 장치의 결함으로 인해 디스크에 저장된 데이터베이스의 내용이 손상된 경우

💡 복구 연산
UNDO (취소)
로그를 이용해 지금까지 실행된 모든 연산을 취소하여 데이터베이스를 원래의 상태로 복구하는 연산
REDO (재실행)
가장 최근에 저장한 데이터베이스 복사본을 가져와 로그를 이용해 복사본이 만들어진 이후에 실행된 모든 연산을 재실행

 

지연 갱신 기법(deferred updates)
로그 파일을 이용한 복구 방법이다. 여기서 로그파일이란 데이터의 변경이 발생할 때마다 생성되는 파일인데, 데이터의 변경 기록들을 저장해둔다. 트랜잭션이 부분 완료 상태에 이르기까지 발생한 모든 변경 내용을 로그 파일에만 저장하고 데이터베이스에는 커밋이 발생할 때까지 갱신을 지연하는 기법이다. 커밋이 이뤄지기 전에는 데이터베이스에 데이터가 갱신되지 않기 때문에 트랜잭션이 실패할 경우 UNDO 없이 로그를 폐기하면 된다.  

[연산 →  데이터 변경 → 로깅] → commit → DB갱신

*[ ] 안에 있는 것들은 트랜잭션 끝날 때까지 반복

즉시 갱신 기법(immediate updates)
지연 갱신 기법과 마찬가지로 로그 파일을 이용한 복구 방법이다. 하지만 지연 갱신 기법과 다르게 트랜잭션 연산 중 데이터가 변경되면 해당 내용을 로그파일과 DB에 즉시 갱신하는 방법이다. 오류 발생 시, 커밋이 발생하기 전에 갱신(미완료 갱신)된 DB는 원자성이 보장되지 않기 때문에 이 미완료 갱신을 UNDO 할 필요가 있다. 오류가 발생하면 로그 파일을 참조해 미완료된 변경에 대해 UNDO를 실행하고 REDO를 통해 해당 트랜잭션을 재수행한다. 

[연산 → 데이터 변경 → 로깅 → DB 갱신(미완료 갱신)] → commit

*[ ] 안에 있는 것들은 트랜잭션 끝날 때까지 반복

체크 포인트 복구 기법(checkpoint recovery)
오류가 발생하여 트랜잭션 복구에 로그 이용 시,  로그 처음부터 마지막까지 모두 처리하기 때문에 오래 걸린다는 단점이 있다. 체크 포인트를 사용하여 복구 시작 시점을 조절하여 효율적으로 진행할 수 있다. 장애 발생 시 체크포인트 이전에 처리된 트랜잭션은 복구에서 제외하고 체크포인트 이후에 처리된 트랜잭션만 복구 작업을 진행한다. 체크포인트는 회복 관리자가 정한 일정 시간 간격으로 생성된다. 

---

 

+트랜잭션의 독립성 레벨

READ UNCOMMITTED
commit 되지 않은 단계의 데이터를 읽는 것을 허용하는 단계이다. 이 단계는 데이터베이스의 정합성을 침해할 수 있으며 거의 독립성이 보장되지 않는 수준으로 본다.
*데이터 정합성: 데이터가 서로 모순 없이 일관되게 일치하는 성질

 

READ COMMITTED
commit 되어야만 데이터를 읽을 수 있는 단계로 가장 보편적인 독립성 단계이다. 이 단계에서는 NON-REPEATABLE READ문제가 발생할 수 있다. 이 문제는 A 트랜잭션에서 commit 한 데이터를 B트랜잭션에서 읽는 도중 A 트랜잭션에서 수정 후 또 다른 commit이 발생한 경우에 일어나는 문제이다. B 트랜잭션에서는 동일한 트랜잭션 내에서 다른 데이터를 조회하게 된다.

 

REPEATABLE READ
위에서 설명한 NON-REPEATABLE READ 문제가 해결된 상태이다. 자신의 트랜잭션 번호보다 낮은 트랜잭션 번호에서 commit 된 내용만 읽게 하는 단계이다. 결과적으로 한번 조회한 데이터는 트랜젝션 내에서 다시 조회해도 같은 데이터가 나오는 것이 보장된다. 이 단계에서는 PHANTOM READ 문제가 발생할 수 있다. 이 문제는 트랜잭션 중간에 INSERT로 인해 새로운 데이터가 추가되었을 때 처음에 읽지 못한 데이터가 갑자기 생기는 문제를 말한다. 즉, 트랜잭션 과정에서 기존에 없던 자료가 새로 얽히는 문제가 발생한다.

 

SERIALABLE
가장 엄격한 수준의 독립성 단계로 해당 트랜잭션의 읽기를 차단한 상태이다. 정합성 측면에서는 완벽하지만, 동시성 측면에서는 최악의 성능을 보여 실제로 적용하기 힘든 단계이다.

*Dirty Read: commit 되지 않은 데이터를 조회하는 것