Transaction Management

트랜잭션

여러개의 오퍼레이션으로 이루어진 논리적 작업단위, 성공하거나 완전히 실패해야만 한다.

A의 50달러를 B로 옮기는 프로그램에서

1. 버퍼에서 A를 읽고
2. A에서 50달러를 감소시킨 후
3. A에 적용시키고,
4. B에서 버퍼를 읽어오고
5. B를 50달러 증가시키고
6. B에 적용시킨다.

만약 위의 과정이 트랜잭션이 안 일어났을 경우,

3번 이후 프로그램이 정지되었을 경우, A는 감소되기만 하고, B는 돈을 얻지 못한다. 즉, 50달러가 증발해버린다.

	A.balance	B.balance
1	1000	2000
2	1000	2000
3	950	2000
4	950	2000
5	950	2000
6	950	2000

• 차라리 실패한다면 3번에서 실행한 내용까지 다 실패하면 문제는 되지 않는다!
• 이 과정을 묶어서 하나로 만들자(실패할때 이전 상태로 롤백할 수 있어야한다.)

트랜잭션의 표현

• 위의 과정을 간단하게 표현하면 아래와 같이 표현된다.

ACID

Consistency

위에서 말한 문제는 inConsistency한 상황이다.

즉, A + B 전과 후 일정해야 했지만, A + B 는 50달러를 잃은 상황이다.

• 일관성을 잃어버림.

Atomicity

트랜잭션은 Atomicity(원자적)한 곳에 담아야한다.

• 더이상 쪼개질 수 없다.

Isolation

여러사람이 동시에 쓸 수 있어야한다.

• A트랜잭션과 B트랜잭션은 서로 모른다(알 필요가 없음)

Durability

변경사항은 데이터베이스에 영구적으로 유지되어야한다.

• 데이터베이스 시스템(Recovery Management Component)가 Durability를 유지해준다.

Transaction State

트랜잭션의 상태는 6가지로 나뉜다.

active: 트랜잭션이 시작됨(활성화)

partially committed: 메모리를 디스크에서 읽은 후의 상태

failed: 실패한 상태

committed: 메모리 내부에서 변경된 내용이 디스크로 저장되는 상태

aborted: 메모리에서 변경된 것이 이전 상태로 롤백되는 상태

terminated: 트랜잭션이 종료됨

트랜잭션 생애주기

active → partially committed → committed → terminated

• 잘 실행되서 커밋된 후 종료된 과정

active → partially committed → failed → aborted → terminated

• 메모리를 읽고 커밋하는 과정에서 실패하여 롤백되는 상태

active → failed → aborted → terminated

• 메모리 읽기를 실패하여 롤백되는 상태

특수한 상황

1. 커밋된 트랜잭션은 롤백될 수 없다.

2. aborted되거나terminated된 이후 로직 문제가 아니라면, 재시작한다.

3. 중단 될 수 없는 것, 프린트 등에서는 롤백 될 수 없다(이미 출력된 것은 뭘 할수 없으므로) 따라서 커밋된 후 실행하자.

Towards Atomicity and Durability

Shadow copy

1. 데이터베이스 복사본을 만들고,
2. 바뀐 내용을 복사본에 적용한다.
3. 그리고 포인터를 복사본에 바꿔주고
4. 이전 데이터베이스 파일은 삭제한다.

위 과정으로 Atomicity와 Durability를 만족한다.

• 1번이 끝난 상태에서 failure가 발생해도 아직 포인터는 원래 값을 가리키므로 괜찮음
• 2번이 끝난 상태에서 failure가 발생해도 위와 같으므로 괜찮음
• 3번이 끝난 상태에서 failure가 발생해도 변경내용이 잘 저장되었으므로 괜찮음

문제점

• concurrent특성을 포기했다.
• 데이터의 크기가 크면 효율이 매우 좋지 않다.

Concurrent?

1번은 concurrency하지 않다. 트랜잭션이 끝나고 다음 트랜잭션이 시작되므로

2번은 concurrency하다. 중간에 다른 트랜잭션이 개입가능하므로.

• cpu가 multi-core일 때 병렬작업 가능
• 그리고 몇몇 T는 cpu작업이고, 몇몇개는 I/O작업일때 동시에 적용 가능하다.

Concurrent = inconsistence?

트랜잭션 2개가 진행될 경우,

Sequencial한 상황(T1 → T2)

A = 1000, B = 2000

After T1: A = 950, B = 2050, Whole = 3000

After T2: A = 855, B = 2145 , Whole = 3000

The requirement holds: Yes

1. Sequencial한 상황(T2→T1)

After T1: A = 900, B = 2100, Whole = 3000

After T2: A = 850, B = 2150 , Whole = 3000

The requirement holds: Yes

1. Concurrency한 상황 1

a. A : 950
b. A: 855
c. B : 2050
d. B : 2145

After T1, T2: A = 855, B = 2145, Whole = 3000

The requirement holds: Yes

2. Concurrency한 상황 2

a. A = 950 (T1 에서 50 감소 = 업데이트 되지 않음)
b. A = 900 (T2 에서 100 감소 = 업데이트 됨)
c. A = 950 (T1 의 값이 업데이트 됨)
d. B = 2050(T1에서 50증가 = 업데이트 됨)
e. B = 2150(T2에서 100증가 = 업데이트 됨)

After T1, T2: A = 950, B = 2150, Whole = 3100

The requirement holds: No!

변경후 메모리 버퍼에 업데이트 되지 않은채 다시 읽는 과정에서 오류가 발생함.

Equivalent

3번 상황과 sequencial한 상황과 결과가 동일하다.

• 추구해야할 목표

Conflict Serializability

confilct serializability: 순서를 바꾸었을때 문제가 되지 않는 것들

1. 같은 데이터 아이템에 대해서 read끼리 순서가 바뀌어도 동일한 결과이다.

2. read와 write는 순서가 바뀌면 Confilct생길 수 있다.

3. write끼리 순서가 바뀌면 Confilct생길 수 있다.

즉, 읽기 연산만 있는게 아닌 쓰기 연산을 포함하는 경우, conflict serializability가 생길 수 있다.

확인

S’: B와 A가 얽힌채 바뀐 것이 아니다.

S’’: 이것도 마찬가지로 B와 A가 얽힌것이 아니다.

위의 두 상황은 conflict equivalent한 상황이다.

위와 같이 conflict equivalent한 상황이 존재하는 schedule은

Conflict Serializability한 스케쥴이라고 부른다.

위 상황은 반대로 S’을 만드려면 write를 하나라도 건드려야 하는데, 건드린다면 non-conflict하게 바뀌게 된다.

위 그림에서 A := A + 50 은 오타 B := B + 50으로 수정

A: 1000 , B : 2000일때

S

1. A: 950 (write)
2. B: 1990 (write)
3. B: 2040(write)
4. A: 960(write)

• 결과 : 3000 으로 결과 동일

S’

1. A:950 (write)
2. B: 2050 (write)
3. B: 2040 (write)
4. A: 960 (write)

• 결과 3000으로 동일

그러나 위 상황을 보면 같은 데이터베이스 (B)의 read와 write를 서로 바꾸어주어, conflict equivalent한 상황이 아닌데 결과는 같다.

• 즉, conflict serializability는 안지켜지더라도 유지될 수는 있지만, 확실히 consistancy를 지켜주는 보수적인 방법

View Equivalent

각 트랜잭션이 읽고 쓰는 값의 출처가 동일하게 보장

Inicial Read

S에서 Ti가 최초로 Q값을 읽었을 때 S’에서 Ti가 처음 값을 읽으면 만족 (읽은 후 또 읽으면 안된다.)

• 즉, 초기값을 읽는 트랜잭션은 두 트랜잭션모두 같은 값을 읽어야한다.

• 왼쪽 T1의 경우 갱신되기 전 A를 읽었고,
• 오른쪽 T1의 경우 갱신된 후의 A를 읽었으므로 Inicial Read를 만족하지 않는다.

Update Read

한 트랜잭션의 읽는 값이 다른 트랜잭션에 의해 갱신되었을 때, 두 스케쥴에서 모두 동일한 트랜잭션의 갱신된 값을 읽어야한다.

위에선 T2에 의해 갱신된 값을 읽는다는 것은 같다. 그러므로 UpdateRead자체는 만족한다.

• 그러나 아래 설명할 fianl write조건은 만족하지 않는다.

Final Write

데이터 항목에 대해 마지막으로 쓰기를 수행한 트랜잭션은 두 스케쥴에서 모두 동일해야한다.

위에선 T3가 마지막 쓰기를 했기 때문에Final Write조건은 만족한다.

• 그러나 read(A)를 하는 과정에서 왼쪽은 갱신된 값을 읽었고, 오른쪽은 갱신되지 않은 값을 읽었으므로 UpdateRead조건을 만족하지 않는다.

위의 세 조건이 모두 만족한다면 View Equivalent한 것이다.

두 스케쥴은 ViewEquivalent를 만족한다

• T1이 최초로 읽어 Initial Read만족
• Read는 두 스케쥴 모두 write되지 않은 값을 읽었으므로 Update Read만족
• T3가 마지막에 작성되었으므로 Final write만족

따라서 View Equivalent를 만족하는 스케쥴이 하나라도 존재하므로 S는 View Serializable한 스케쥴이다.

View Serializable

View Serializable해도 Conflict serializable하지 않을 수 있다.

그러나 Conflict serializable 한 스케쥴은 ViewSerializable하다.

Recoverability

동시적인 상황에서 실패가 발생했을 때 어떻게 롤백할것인가?

T2에서 오류가 발생하면 T2는 aborted되야한다.

이때, T1또한 연관되어 있으므로 연쇄적으로 T1도 롤백되어야 한다.

이걸 Cascading rollback이라한다.

위와 같은 상황에서 이미 commit되어 버렸으므로 rollback이 불가하다.

• T2는 T1에서 write한 값을 읽었기 때문에 T1에 의존하는 트랜잭션이다.
• 그러나 T1은 commit되지 못했기 때문에 consistency를 보장할 수 없을 뿐 아니라, 복구조차 불가능하다.
• 이를 recoverable 하지 못한 상황이라한다.

Cascadeless schedule

그러면 Cascading rollback하지 않도록 자주 commit해주어 주면 이건 recoverable하다.

• 위를 보면 T1과 T2, T3등 어느곳에서도 연쇄적인 트랜잭션이 없다. commit되어있기 때문이다.

중요한 것은 write이후 커밋이 아니라, 의존적인 T2가 커밋하기 전, T1이 먼저 커밋해주는 것이다. 즉, 의존관계가 있으면 의존 받는 트랜잭션이 먼저 커밋되어야한다.

Concurrent Transaction

Towards Isolation

한 트랜잭션을 사용중일때 db를 Lock해주는 것.

• 그러나 concurrent하지 않다.

Serializability test

Procedence graph를 그린다.

G = (V,E)

V = transactions

Ti → Tj 로의 edge를 그릴때

• Ti write(Q) → Tj read(Q)
• Ti read(Q) → Tj write(Q)
• Ti write(Q)→Tj write(Q)

위와 같이 그려진다.(write이후 read가 있으면 화살표 라는 의미)

• 위같은 상황에선 T2 → T1으로의 화살표만 계속 그려지므로,
• cycle이 나오지 않는다.
• conflict serializable 하다

• 위에선 T1 read(A) → t2 write(A) 와 T2 read(A)와 T1 write(A)등이 있으므로
• T1 <->T2
• cycle이 나왔다.
• 따라서 conflict serializable하지 않는다.