[Database] 트랜잭션 정리

뚱이·2023년 7월 11일

CS Database

트랜잭션

1) 정의

트랜잭션 = DB의 상태를 변경시키는 작업의 단위

트랜잭션은 쉽게 말해, 한꺼번에 수행되어야 할 연산을 모아놓은 것이다.

연산들을 모두 처리하지 못 한 경우에는 원 상태로 복구한다. 즉, 작업의 일부만 적용되는 현상이 발생하지 않는다.

이를 통해 트랜잭션은 작업의 완전성을 보장해준다.

사용자의 입장에서는 작업의 논리적 단위 이고,

시스템의 입장에서는 데이터들을 접근 또는 변경하는 프로그램의 단위 가 된다.

2) 트랜잭션의 4가지 특징: ACID

Atomicity (원자성)

트랜잭션이 DB에 모두 반영되거나, 혹은 전혀 반영되지 않아야 된다 (All or Nothing).

Consistenty (일관성)

트랜잭션의 작업 처리 결과는 항상 일관성 있어야 한다.

시스템이 가지고 있는 고정 요소는 트랜잭션 수행 전과 수행 후의 상태가 같아야 한다는 말로,

DB의 제약조건을 위배하는 작업을 트랜잭션 과정에서 수행할 수 없음을 나타낸다.

ex) 송금 시 금액의 데이터 타입을 정수형(integer)에서 문자열(string)로 변경할 수 없음.

Isolation (독립성)

둘 이상의 트랜잭션이 동시에 병행 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다.

Durability (지속성)

트랜잭션이 성공적으로 완료되었으면, 결과는 영구적으로 반영되어야 한다.

3) 트랜잭션의 연산

(1) COMMIT 연산

트랜잭션이 성공적으로 수행되었음을 선언하는 연산으로,

COMMIT ****연산의 실행을 통해 트랜잭션의 수행이 성공적으로 완료되었음을 선언하고, 그 결과를 최종 DB에 반영한다.

(2) ROLLBACK 연산

트랜잭션 수행이 실패했음을 선언하고 작업을 취소하는 연산으로,

트랜잭션이 수행되는 도중 일부 연산이 처리되지 못한 상황이라면 ROLLBACK 연산을 실행하여 트랜잭션 수행이 실패했음을 선언하고, DB를 트랜잭션 수행 전과 일관된 상태로 되돌려야 한다.

4) 트랜잭션의 상태

Active

트랜잭션 활동 상태

트랜잭션이 실행 중이며 동작 중인 상태를 말한다.

Partially Committed

트랜잭션의 COMMIT 명령이 도착한 상태

트랜잭션의 COMMIT 이전 SQL문이 수행되고, COMMIT 만 남은 상태를 말한다.

(트랜잭션의 마지막 연산까지 실행하고 COMMIT 연산을 실행하기 직전의 상태)

Failed

트랜잭션 실패 상태

더이상 트랜잭션이 정상적으로 진행될 수 없는 상태를 말한다.

Committed

트랜잭션 완료 상태

트랜잭션이 정상적으로 완료된 상태를 말한다.

Aborted

트랜잭션 취소 상태

트랜잭션이 취소되고, 트랜잭션 실행 이전 데이터로 돌아간 상태를 말한다.
(트랜잭션 수행을 실패하고 ROLLBACK 연산을 실행한 상태)

❓ Partially Committed vs Committed
—
COMMIT 요청이 들어오면, Partially Committed 상태가 된다.
이후 COMMIT 을 문제 없이 수행할 수 있으면 Committed 상태로 전이되고, 오류가 발생한다면 Failed 상태가 된다.

즉, Partially Committed 는 COMMIT 요청이 들어왔을 때를 말하며,
Committed 는 COMMIT 을 정상적으로 완료한 상태를 말한다.

5) 트랜잭션 사용 시 주의할 점

트랜잭션은 꼭 필요한 최소한의 코드에만 적용하는 것이 좋다. 즉, 트랜잭션의 범위를 최소화하라는 말이다.

일반적으로 DB 커넥션은 개수가 제한적이다. 그런데 각 단위 프로그램이 커넥션을 소유하는 시간이 길어지면, 사용 가능한 여유 커넥션의 개수는 줄어들게 된다. 그러다 어느 순간에는 각 단위 프로그램에서 커넥션을 가져가기 위해 기다려야 하는 상황이 발생할 수 있기 때문이다.

6) 병행제어 - 지엽적, 참고만

병행제어란, 여러 개의 트랜잭션이 실행될 때, 트랜잭션들이 DB의 일관성을 파괴하지 않고 다른 트랜잭션에 영향을 주지 않으면서 트랜잭션을 제어하는 것을 의미한다.

병행 실행 시 발생 가능한 문제들

(1) 분실된 갱신

두 개의 트랜잭션이 같은 데이터에 대해서 동시에 갱신 작업을 하면, 하나의 갱신 작업이 분실 되는 경우

(2) 모순성

한 개의 트랜잭션 작업이 갱신 작업을 하고 있는 상태에서 또 하나의 트랜잭션이 같은 작업 구역에 침범하여 작업하게 되어, DB의 일관성을 해치는 경우

(3) 연쇄복귀

같은 자원을 사용하는 두 개의 트랜잭션 중 한 개의 트랜잭션이 성공적으로 일을 수행하였다 하더라도 다른 트랜잭션이 처리하는 과정에서 실패하게 되면, 두 개의 트랜잭션 모두가 복귀되는 현상

(4) 비완료 의존성

한 개의 트랜잭션이 수행 과정에서 실패하였을 때, 이 트랜잭션이 회복되기 전에 다른 트랜잭션이 수행 결과를 참조하는 현상

병행제어 기법

(1) 로킹(Locking)

트랜잭션이 어떤 데이터에 접근하고자 할 때 로킹을 수행하며, 한 트랜잭션만이 로킹 해제 가능.

트랜잭션은 로킹이 된 데이터에 대해서만 연산을 수행할 수 있으며, 필드/레코드/파일/DB 모두 로킹의 단위 및 대상이 될 수 있음.

로킹 단위가 크면: 관리 용이(로킹 오버헤드 감소) but 동시성 수준 감소
로킹 단위가 작으면: 동시성 수준 증가 but 관리 어려움(로킹 오버헤드 증가)

2단계 로킹 규약(Two-Phase Locking Protocol)

Lock과 Unlock이 동시에 이루어지면 일관성이 보장되지 않으므로, Lock만 가능한 단계와 Unlock만 가능한 단계를 구분하여 직렬가능성을 보장한다.

교착상태가 발생할 수도 있다.

확장단계: 트랜잭션이 Lock 가능, Unlock 불가능
축소단계: 트랜잭션이 Unlock 가능, Lock 불가능
ex) T1: write(A) read(B), T2: read(B) write(A) ⇒ dead lock 발생

로킹의 종류

S-lock (공유잠금)
- 공유잠금을 설정한 트랜잭션은 데이터 항목에 대해 읽기 연산(read)만 가능
- 하나의 데이터 항목에 대해 여러 개의 공유잠금(S-lock) 가능
- 다른 트랜잭션도 읽기 연산(read)만을 실행
X-lock (배타잠금)
- 배타잠금을 설정한 트랜잭션은 데이터 항목에 대해 읽기 연산(read)과 쓰기 연산(write) 모두 가능
- 하나의 데이터 항목에 대해서는 하나의 배타잠금(X-lock)만 가능
- 다른 트랜잭션은 읽기 연산(read)과 쓰기 연산(write) 모두 불가능

(2) 타임 스탬프(Time Stamp)

데이터에 접근하는 시간을 미리 정하여 정해진 시간의 순서대로 데이터에 접근하며 수행.

직렬가능성을 보장하며, 시간을 나눠 사용하기 때문에 교착 상태가 발생하지 않음.

But, 연쇄 복귀를 초래할 수 있음.

(3) 낙관적 병행제어(Optimistic Concurrency Control)

트랜잭션 수행동안은 어떠한 검사도 하지 않고 트랜잭션 종료 시에 일관적으로 검사.

트랜잭션 수행동안 그 트랜잭션을 위해 유지되는 데이터 항목의 지역사본에 대해서만 갱신하며, 트랜잭션 종료 시에 동시성을 위한 트랜잭션 직렬화가 검증되며 일시에 DB에 반영함.

(4) 다중 버전 병행제어(Multi-version Concurrency Control)

하나의 데이터 아이템에 대해 여러 버전의 값을 유지하며 조회 성능을 최대한 유지하기 위한 기법.

트랜잭션 간의 충돌 문제는 대기가 아니라 복귀 처리함으로써 연쇄복귀초래 발생 가능성 존재.

7) 교착상태 (Deadlock) - 정의만, 나머지는 참고

정의

교착상태란, 두 개 이상의 트랜잭션이 특정 자원(테이블 or 행)의 잠금(Lock)을 획득한 채 다른 트랜잭션이 소유하고 있는 잠금을 요구해 아무리 기다려도 상황이 바뀌지 않는 상태를 의미한다.

교착상태의 예시(MySQL)

MySQL MVCC에 따른 특성으로, 트랜잭션에서 갱신 연산(Insert, Update, Delete) 을 실행하면 잠금을 획득한다. (디폴트는 행에 대한 잠금)

T1이 테이블B의 첫 번째 행의 잠금을 얻고, T2도 테이블A의 첫 번째 행의 잠금을 얻었다고 하자.

Transaction 1> create table B (i1 int not null primary key) engine = innodb;
Transaction 2> create table A (i1 int not null primary key) engine = innodb;

Transaction 1> start transaction; insert into B values(1);
Transaction 2> start transaction; insert into A values(1);

트랜잭션을 COMMIT 하지 않을 채 서로의 첫 번째 행에 대한 잠금을 요청하면

Transaction 1> insert into A values(1);
Transaction 2> insert into B values(1);
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

Deadlock이 발생한다. 일반적으로 DBMS는 교착상태를 독자적으로 검출해 보고한다.

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

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

8) 트랜잭션 격리수준(Isolation Level)

정의

ACID 중 Isolation(독립성, 고립성)을 구현하는 개념으로,

동시에 여러 트랜잭션이 처리될 때 트랜잭션끼리 얼마나 서로 고립되어 있는지를 나타내는 것이다.

즉, 특정 트랜잭션이 다른 트랜잭션에 변경한 데이터를 볼 수 있도록 허용할지 말지를 결정하는 것이다.

격리수준은 크게 아래의 4가지로 구분된다.

READ UNCOMMITTED
READ COMMITED
REPEATABLE READ
SERIALIZABLE

아래로 내려갈수록 트랜잭션 간 고립 정도가 높아지며 성능이 떨어지는 것이 일반적이다.

일반적인 온라인 서비스에서는 READ COMMITED 나 REPEATABLE READ 중 하나를 사용한다.

(oracle의 디폴트 = READ COMMITED, MySQL의 디폴트 = REPEATABLE READ)

트랜잭션 격리수준의 필요성

DB는 ACID 특징과 같이 트랜잭션이 독립적인 수행을 하도록 한다.

따라서 Locking을 통해 트랜잭션이 DB를 다루는 동안 다른 트랜잭션이 관여하지 못하도록 막는 것이 필요하다.

하지만 무조건 Locking으로 동시에 수행되는 수많은 트랜잭션들을 순서대로 처리하는 방식으로 구현하게 되면, DB의 성능은 떨어지게 된다.

그렇다고 성능을 높이기 위해 Locking의 범위를 줄인다면 잘못된 값이 처리될 문제가 발생하게 되므로, 최대한 효율적인 Locking 방법이 필요하다.

트랜잭션 격리수준의 종류

READ UNCOMMITTED (레벨 0) - 커밋되지 않는 읽기

각 트랜잭션에서의 변경 내용을 COMMIT 이나 ROLLBACK 여부에 상관없이 다른 트랜잭션에서 값을 읽을 수 있다.
정합성에 문제가 많은 격리 수준이기 때문에 사용하지 않는 것을 권장.
DIRTY READ 현상 발생
- DIRTY READ: 트랜잭션 작업이 완료되지 않았음에도 다른 트랜잭션에서 볼 수 있게 됨
ex) 아래 그림과 같이 COMMIT 되지 않은 상태지만 Update 된 값을 다른 트랜잭션에서 읽기 가능

READ COMMITED (레벨 1) - 커밋된 읽기

RDB에서 대부분 기본적으로 사용되고 있는 격리 수준
실제 테이블 값을 각져오는 것이 아니라, Undo 영역에 백업된 레코드에서 값을 가져옴

DIRTY READ와 같은 현상 발생 X
Non-repeatable Read 현상 발생
- Non-repeatable Read: 한 트랜잭션에서 같은 쿼리를 두 번 수행할 때, 그 사이에 다른 트랜잭션 값을 수정 or 삭제하면서 두 쿼리의 결과가 상이하게 나타나는 일관성이 깨진 현상

REPEATABLE READ (레벨 2) - 반복가능한 읽기

Undo 공간에 백업해두고 실제 레코드 값을 변경

MySQL에서는 트랜잭션마다 트랜잭션 ID를 부여해 트랜잭션 ID보다 작은 번호에서 변경한 것만 읽음
백업된 데이터는 불필요하다고 판단하는 시점에 주기적으로 삭제
Undo에 백업된 레코드가 많아지면 MySQL 서버의 처리 성능이 떨어질 수 있음
이러한 변경방식을 MVCC(Multi Version Concurrency Control) 라고 부름
PHANTOM READ 현상 발생
- PHANTOM READ: 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보였다가 하는 현상
- REPEATABLE READ 에 의하면 원래 출력되지 않아야 하는데 Update 영향을 받은 후부터 출력
- 방지 방법: 쓰기(write) 잠금을 걸어야 함

SERIALIZABLE (레벨 3) - 직렬화 가능

가장 단순한 격리 수준이면서 가장 엄격한 격리 수준
완벽한 읽기 일관성 모드 제공
다른 사용자는 트랜잭션 영역에 해당되는 데이터에 대한 수정 및 입력 불가능
성능 측면에서는, 동시 처리 성능 가장 낮음
PHANTOM READ 발생 X
DB에서 거의 사용 X

[정리] 낮은 격리수준을 활용했을 때 발생하는 현상들

이 현상들은 트랜잭션의 Isolation(고립성)과 데이터 무결성의 지표로 사용된다.

Dirty Read

생성, 갱신 또는 삭제 중에 커밋되지 않은 데이터 조회를 허용함으로써,

트랜잭션이 종료되면 더이상 존재하지 않거나, 롤백되었거나, 저장 위치가 바뀌었을 수도 있는 데이터를 읽어들이는 현상
Non-repeatable Read

한 트랜잭션 내에서 같은 행이 두 번 이상 조회됐는데 그 값이 다른 경우

ex) A와 B가 마지막 남은 영화표를 예매하는데, A가 고민하는 중에 B가 표를 구매하여 A는 상반된 정보를 받게 되는 경우
Phantom Read

한 트랜잭션 안에서 일정 범위의 레코드를 두 번 이상 읽었을 때,

첫 번째 쿼리에서 없던 레코드가 두 번째 쿼리에서 나타나는 현상

참고

뚱이

이전 포스트

[헤드퍼스트 디자인패턴] Chapter 08. 템플릿 메소드 패턴

다음 포스트

[C++] max(), min()의 인자 3개 이상일 때

1개의 댓글

mysem900

2024년 12월 1일

https://boersen.oeh-salzburg.at/author/viwadoll/
https://www.ilcirotano.it/annunci/author/viwadoll/

답글 달기