Transaction

---

Transaction Processing

데이터의 공유와 다수 사용자를 관리하기 위한 기능을 트랜잭션 처리라고 한다. 여러 사용자가 동시에 동일한 데이터베이스 공유 가능하도록 지원하는 것이다. 동시에 사용하더라도 일관성(consistency)을 보장하기 위한 동시성 제어 (concurrency control) 기능을 제공한다.
이때 트랜잭션 자체는 DB 작업을 수행하는 단위 프로세스를 의미한다.

 

트랜잭션의 주요 성질은 Jim Gray가 정의한 ACID로 정리된다.
• 원자성(Atomicity) : 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력이다.
• 일관성(Consistency) : 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터 베이스 상태로 유지하는 것을 의미한다.
• 격리성(Isolation) : 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보 장하는 것을 의미한다.
• 영속성(Durability) : 성공적으로 수행된 트랜잭션은 영원히 반영되어야 한다.

---

Commit

Autocommit이 켜져있으면 자동으로 commit이 진행되는 반면 autocommit이 꺼져있으면 아래와 같이 commit을 진행해야 어디서 보던 변화가 똑같이 적용이 되는 것이다. 이때 commit전에 rollback을 이용하면 DB를 수정하기 전으로 돌아간다.

---

원자성 예시

계좌A에서 100원을 계좌B에 이체하려한다. 이때 원래 잔고는 다음과 같다. (A=1000, B=2000)

Output 연산이 진행되기전 DB는 아래와 같다.

이때 Output(Ba)를 수행하고 Output(Bb)를 실행하려는 순간에 장애가 발생했다.

100을 잃어서 모순상태가 된 것이다. 이럴때 rollback을 하면 더 큰 혼란을 막고 다시 연산을 수행할 수 있다. 원자성을 보장하여 다른 사용자에게 까지 혼란이 생기지 않은 모습이다.

이를 트랜잭션 회복(Transaction Recovery)라고 한다. 아래와 같은 과정을 거친다.

BEGIN_TRANS;
    UPDATE ACCOUNT
    SET Balance = Balance - 100 
    WHERE Accnt = 'A';
    IF ERROR GO TO UNDO;
    
    UPDATE ACCOUNT
    SET Balance = Balance + 100 
    WHERE Accnt = 'B';
    IF ERROR GO TO UNDO;
    
    COMMIT TRANS;
    GO TO FINISH; 
   UNDO:
        ROLLBACK TRANS;
   FINISH:
	RETURN; 
END_TRANS

위와 같은 명령문을 이용하는데 실패 상태에 있는 트랜잭션은 데이터베이스 상태를 트랜잭션 실행이 시작되기 직전의 상태로 환원 시키기 위해 Rollback 연산이 실행되고 그 뒤에서 철회 상태의 트랜잭션으로 되어 종료된다.

 

이때 취할 수 있는 조치는 두가지 정도가 있다.

트랜잭션의 재시작 : 하드웨어나 시스템 소프트웨어 오류로 인해 철회된 트랜잭션은 다시 새로운 트랜잭션으로 취급되어 재시작

트랜잭션의 폐기 : 트랜잭션의 내부적 오류로 재작성을 해야 하든지 원하는 데이타가 데이터베이스에 없는경우에 취하는 조치

 

회복관리자(Recovery manager) : DBMS의 서브시스템

- DBMS 코드의 10% 이상을 차지

- 신뢰성 있는 회복을 책임

 

회복의 기본원리 : 중복(redundancy)

- 덤프(dump) : 다른 저장장치로 복제(archive)

- 로그(log, journal) : 데이타 아이템의 옛 값과 새 값(old/new value)을 별도의 파일에 기록

 

회복을 위한 조치

- REDO : 가장 최근 복제본과 로그를 이용하는데 데이터베이스 내용 자체가 손상이 된 경우에 가장 최근의 복제본을 적재시킨 뒤 이 복제본 이후에 일어난 변경만을 로그를 이용하여 재실행함으로써 데이터베이스를 복원하는것이다.

- UNDO : 데이터베이스 내용 자체는 손상되지 않았지만, 변경중이거나 변경된 내용에 대한 신뢰성을 잃어버린 경우에 로그를 이용하여 모든 변경들을 취소시킴으로써 원래 데이터베이스를 복원하는 것이다.

---

DB 저장

1) 소멸 저장장치(volatile storage)

- 메인 메모리

- 시스템의 붕괴와 함께 저장된 데이타 상실

 

2) 비소멸성 저장장치(nonvolatile storage)

- 디스크나 테이프

- 시스템 붕괴 시에도 보통 저장된 데이타 손실되지 않음

- 저장장치 자체의 고장으로 손실 가능

 

3) 안정 저장장치(stable storage)

- 데이타의 손실이 발생하지 않게 여러 개의 비소멸 저장장치로 구성된 저장장치

 

DBMS 코드의 내용을 먼저 로그 버퍼에 보내주고 DB 버퍼에 보내주면 각각 온라인 로그와 온라인 데이터베이스에 disc write을 수행한다.

---

검사시점

시스템에 장애가 일어났을 때 로그를 이용하는 기법은 기본적으로 생각하면 Redo와 Undo를 해야 될 트랜잭션을 결정하기 위해서 로그 전체를 조사해야한다. 그러나 이러한 방법은 너무 많은 시간이 걸리고 불필요한 Redo를 진행해야한다.

따라서 게임에서도 자주 나오는 checkpoint 설정 방법이 있다. 로그를 기록 유지하고 일정 시간 간격으로 검사시점 설정하는 것이다. 메인 메모리(로그 버퍼)에 있는 모든 로그 레코드를 안정 저장소로 출력하고 변경된 데이타 버퍼 블록을 전부 디스크로 출력하여 검사 시점 표시로써 로그 레코드를 안정 저장소에 출력하도록한다. 여기서 L은 현재 실행 중에 있는 트랜잭션들의 리스트이다.

위와 같은 상황에서 T1은 회복작업이 필요없다. T2와 T4는 failure 시점 전에 commit이 되었으므로 REDO 요청을 하면되는 것이고 T3와 T5와 같은 경우에는 commit을 하기 전에 장애가 발생했으므로 UNDO를 진행해야한다.

 

트랜잭션 목록 결정 방법은 아래와 같다.

- 두 개의 빈 Undo-list와 Redo-list 생성

- 검사시점 설정 당시 활동 중인 트랜잭션은 Undo-list에 삽입

- 로그를 차례로 검색하면서 로그 레코드를 만나면 트랜잭션 Ti를 Undo-list에 첨가

- 로그를 차례로 검색하면서 < Ti, Commit> 로그 레코드를 만나면 트랜잭션 Ti를 Undo-list에서 삭제하고 Redo-list에 첨가

---

회복 기법의 구현

첫번째 방안으로는 메인 메모리 일부를 운영체제가 아니라 DBMS가 관리하는 버퍼로 예약하는 것이다. 그리고 DB블록 이동을 DBMS가 관리하는 것이다. 그러나 데이터베이스 버퍼로 사용할 수 있는 메인 메모리 크기가 제한되어 있고 DBMS가 운영될 때는 다른 목적으로 예약된 부분의 메인 메모리가 낭비되는 문제가 있고 데이터베이스 버퍼로 예약된 부분에 대해서는 데이터베이스를 이용하지 않는 app들은 사용할 수 없다는 단점이 있다.

두번째 방안은 DBMS는 운영체제의 가상 기억장치 속에 데이터베이스 버퍼를 구현하는 것이다. 데이터베이스 자체는 운영체제의 파일 시스템 속에 저장하 데이터베이스 파일과 이 가상 기억장치의 버퍼 사이의 이동은 DBMS가 관리하여 변경된 블록보다 로그 레코드가 먼저 출력되도록 한다. 그러나 디스크에 추가적인 출력을 필요로 하는 단점이 있고 블록 B를 출력하기 위해서 두 번의 출력(운영 체제와 DBMS가 각각 한 번씩)과 또 한 번의 입력이 수행되어야 하는 단점도 있다.

 

위는 MySQL의 WAL(Write-Ahead Log)로 InnoDB에서 Redo의 log 역할이다.

MySQL에서 로그가 저장되는 모습이다.

---