Computer-Science

Transaction Processing

데이터의 공유와 다수 사용자 트랜잭션 처리
- 여러 사용자가 (동시에) 동일한 데이터베이스 공유 가능하도록 지원
- 동시에 사용하더라도 일관성(consistency)을 보장하기 위한 동시성 제어 (concurrency control) 기능 제공

트랜잭션의 정의

데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 프로세스 (예: 계좌이체, 좌석예약)
- 장애가 일어날 때 데이터를 복구하는 작업의 단위가 됨
- 동시에 같은 데이터를 다룰 때가 이 작업을 서로 분리하는 단위가 됨
하나의 작업을 수행하는 데 필요한 데이터베이스의 연산들을 모아놓은 것 (한꺼번에 모두 수행되어야 할 일련의 연산들)

트랜잭션의 주요 성질: ACID

Atomicity (원자성)
- 트랜잭션과 관련된 작업들은 전부 정상적으로 실행되거나, 아예 하나도 실행되지 않아야 한다. (all or nothing)
Consistency (일관성)
- 트랜잭션이 성공적으로 수행된 후에도, 데이터베이스는 항상 일관된 상태를 유지해야 한다.
Isolation (격리성, 고립성)
- 현재 수행 중인 트랜잭션이 완료될 때까지 트랜잭션이 생성한 중간 연산 결과에, 다른 트랜잭션들이 접근할 수 없어야 한다.
Durability (지속성, 영속성)
- 성공적으로 수행된 트랜잭션은 손실되지 않고, 영구적으로 반영되어야 한다.

원자성을 위한 연산

Commit (완료)
- 트랜잭션의 성공적인 실행
  - 일관성 있는 데이터베이스 상태 (Consistency)
- 영구적인 갱신
- 갱신된 데이터의 영속성을 보장 (Durability)
Rollback (취소, 복귀)
- 트랜잭션 실행의 실패
  - 모순된 데이터베이스 상태
- 수행한 모든 연산 결과의 UNDO

MySQL의 autocommit, commit, rollback

mysql> SHOW VARIABLES LIKE "%commit%";
+-----------------------------------------+-------------------+
| Variable_name                           | Value             |
+-----------------------------------------+-------------------+
| autocommit                              | ON                |
| binlog_group_commit_sync_delay          | 0                 |
| binlog_group_commit_sync_no_delay_count | 0                 |
| binlog_order_commits                    | ON                |
| innodb_api_bk_commiTinterval           | 5                 |
| innodb_commit_concurrency               | 0                 |
| innodb_flush_log_at_trx_commit          | 1                 |
| original_commit_timestamp               | 36028797018963968 |
| replica_preserve_commit_order           | ON                |
| replication_sender_observe_commit_only  | OFF               |
| slave_preserve_commit_order             | ON                |
+-----------------------------------------+-------------------+
11 rows in set (0.06 sec)

mysql> SET autocommit = 0;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW VARIABLES LIKE "%commit%";
+-----------------------------------------+-------------------+
| Variable_name                           | Value             |
+-----------------------------------------+-------------------+
| autocommit                              | OFF               |
| binlog_group_commit_sync_delay          | 0                 |
| binlog_group_commit_sync_no_delay_count | 0                 |
| binlog_order_commits                    | ON                |
| innodb_api_bk_commiTinterval           | 5                 |
| innodb_commit_concurrency               | 0                 |
| innodb_flush_log_at_trx_commit          | 1                 |
| original_commit_timestamp               | 36028797018963968 |
| replica_preserve_commit_order           | ON                |
| replication_sender_observe_commit_only  | OFF               |
| slave_preserve_commit_order             | ON                |
+-----------------------------------------+-------------------+
11 rows in set (0.00 sec)

mysql> CREATE TABLE customer (a INT, b CHAR (20), INDEX (a));
Query OK, 0 rows affected (0.00 sec)

mysql> -- Do a transaction with autocommit turned on.
mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO customer VALUES (10, 'Heikki');
Query OK, 1 row affected (0.00 sec)

mysql> COMMIT;
Query OK, 0 rows affected (0.00 sec)

mysql> -- Do another transaction with autocommit turned off.
mysql> SET autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysq1> INSERT INTO customer VALUES (15, 'John');
Query OK, 1 row affected (0.00 sec)

mysq1> INSERT INTO customer VALUES (20, 'Paul');
Query OK, 1 row affected (0.00 sec)

mysql> DELETE FROM customer WHERE b = 'Heikki';
Query OK, 1 row affected (0.00 sec)

mysql> -- Now we undo those last 2 inserts and the delete.
mysql> ROLLBACK;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM customer;
+------+---------+
| a    | b       |
+------+---------+
|   10 | Heikki  |
+------+---------+
1 row in set (0.00 sec)

트랜잭션 상태

트랜잭션의 상태는 다섯가지 상태 중 하나에 속하게 된다.
- 활동 상태
  - 트랜잭션이 수행되기 시작하여 현재 수행 중인 상태
- 부분 완료 상태
  - 트랜잭션의 마지막 연산이 실행된 직후의 상태.
  - 모든 연산의 처리가 끝났지만 트랜잭션이 수행된 최종 결과를 데이터베이스에 아직 반영하지 않은 상태
- 완료 상태
  - 성공적으로 완료되어 커밋 연산을 실행한 상태
- 실패 상태
  - 장애가 발생하여 트랜잭션의 수행이 중단된 상태
- 철회 상태
  - 트랜잭션을 수행하는데 실패하여 롤백연산을 실행한 상태

Transaction_status

프로그램 : 하나 이상의 트랜잭션을 포함
- 프로그램의 성공적인 수행 = 모든 트랜잭션의 성공적인 완료

트랜잭션의 예

계좌 A에서 계좌 B로 100원을 이체

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)

데이터베이스를 장애 발생 이전의 일관된 상태 (consistent state)로 복원시키는 것
- 일관된 상태 : 데이터베이스에 오류가 없는 상태, 데이터베이스의 내용에 모순이 없는 상태
기본원리 : 중복(redundancy)

회복을 위한 연산

덤프 (dump)
- full backup, 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법 (archive)
로그 (log, journal)
- 데이터베이스에서 변경 연산이 실행될 때마다, 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록하는 방법
REDO (재실행) : 가장 최근 복제본 + 로그
- 가장 최근에 저장한 데이터베이스 복사본을 가져온 후 로그를 이용해 복사본이 만들어진 이후에 실행된 모든 변경 연산을 재실행하여 장애가 발생하기 직전의 데이터베이스 상태로 복구
- 전반적으로 손상된 경우에 주로 사용
UNDO (취소) : 로그 + 모든 변경들을 취소
- 로그를 이용해 지금까지 실행된 모든 변경 연산을 취소하여 했던 것을 없던 것처럼 원래의 데이터베이스를 복원하는 것
- 변경 중이었거나 이미 변경된 내용만 신뢰성을 잃은 경우에 주로 사용

데이터베이스 로그 : 로그 압축

목적 : 저장장치의 효율성, 신속한 회복
이유
- 1. 실패한 트랜잭션은 로그 불필요
    - 트랜잭션이 이미 rollback 되었음
- 1. 성공한 트랜잭션의 갱신 전 데이터는 불필요
    - REDO를 위해 새로운 값만 필요
- 1. 하나의 데이터 아이템이 여러 트랜잭션에 의해 여러 번 갱신되었다면 가장 마지막 데이터 값만 필요
    - REDO 시 중간 과정의 데이터 값은 불필요

다양한 회복 기법

(1) 로그 기반 회복 기법
- (1-1) 즉시 갱신 회복 기법
- (1-2) 지연 갱신 회복 기법
(2) 검사 시점 회복 기법
(3) 미디어 회복 기법

(1-1) 즉시 갱신 회복 기법

트랜잭션 수행 도중 데이터를 변경하면 변경 정보를 로그 파일에 저장하고, 트랜잭션이 부분 완료되기 전이라도 모든 변경 내용을 즉시 데이터베이스에 반영하는 기법

특징
- 회복 시 로그 파일을 참조하여 Redo와 Undo 연산을 모두 실행해야 한다.
- 트랜잭션이 완료되기 전 장애가 발생한 경우 : Undo
  - 만일 로그에 <Ti, Start> 레코드만 있고 <Ti, Commit> 레코드가 없으면 Undo(Ti)를 수행
- 트랜잭션이 완료된 후 장애가 발생한 경우: Redo
  - 만일 로그에 <Ti, Start> 레코드와 <Ti, Commit> 레코드가 모두 다 있으면 Redo(Ti)를 수행
구현
- 트랜잭션 활성 상태에서 데이터 변경 결과를 로그와 데이터베이스에 반영
- 회복 시 트랜잭션 실행 이전의 상태로 복구
- 로그 파일을 참조하여 미완료된 변경에 대해 Undo를 우선 실행한 후, 완료된 변경에 대해 Redo 실행
적용의 예 (<T1, T2> 순으로 실행)
- T1이 Commit하기 직전에 시스템 붕괴
  - Undo(T1)실행
- T2가 Commit하기 직전에 시스템 붕괴
  - Undo(T2)를 먼저 실행, 다음 Redo(T1) 실행
    - 일반적으로 모든 Undo 후에 Redo를 해야 함
- T2가 <T2, Commit>로그 레코드 출력 직후 시스템 붕괴
  - Redo(T1), Redo(T2) 실행
    - Undo는 역순, Redo는 기록된 순서대로 실행

(1-2) 지연 갱신 회복 기법

트랜잭션이 수행되는 동안에는 데이터 변경 연산의 결과를 데이터베이스에 즉시반영하지 않고 로그 파일에만 기록해두었다가, 트랜잭션이 완료된 후에 로그에 기록된 내용을 이용해 데이터베이스에 한 번에 반영

특징
- 트랜잭션이 수행되는 동안 장애가 발생할 경우 로그에 기록된 내용을 버리기만 하면 데이터베이스가 원래 상태를 그대로 유지하게 된다.
  - 지연 갱신 회복 기법에서는 REDI 연산만 이용함
    - 데이터베이스 회복 과정에서 UNDO는 필요 없음. 트랜잭션 복구 시 로그 파일 내용만 폐기
- 트랜잭션이 완료되기 전 장애가 발생한 경우: 로그 내용을 무시하고 버림
- 트랜잭션이 완료된 후 장애가 발생한 경우: Redo
- 부분 완료될 때까지 모든 Output 연산을 지연
  - 모든 데이터베이스의 변경을 로그에 먼저 기록
  - 안전한 저장소에 <Ti, Commit>를 포함하는 로그 레코드를 기록한 후에 데이터베이스 갱신
    - 완료 상태로 감
    - <Ti, Commit>는 부분적으로 기록
  - 로그 레코드 : REDO 연산에 대비. 예전값도 필요없음
    - <트랜잭션 id, 데이터 아이템, 변경된 값>
- Redo 연산은 idempotent 성질을 가지고 있어야 함
  - 같은 Redo를 여러번 실행한 것이나 한 번 실행한 것이나 그 결과는 동등
  - Redo 작업 중 다시 장애가 일어나 Redo 연산을 또 다시 실행하더라도 처음 한 번 시행한 결과와 동일
  - Redo(Redo(Redo...(x))) = Redo(x)
구현
- 트랜잭션 단위가 종료될 때까지 디스크에 기록하는 출력 연산을 지연시키고, 데이터베이스 변경 내역을 로그에 보관
- 트랜잭션 완료(Commit) 시 로그를 이용해 지연된 출력 연산(Redo) 수행
- 트랜잭션이 실패할 경우 Undo 없이 로그 단순 폐기

어떤 트랜잭션이 Redo 되어야 하는가?

로그에 <Ti, Start> 레코드와 <Ti, Commit> 레코드가 모두 있는 트랜잭션 Ti에 대해서만 재실행
회복절차 : 세 개의 상이한 시점의 로그
- 로그에 Commit 레코드가 있는 트랜잭션에 대해서 Redo 다시 실행

(2) 검사시점 회복

데이터베이스 트랜잭션 동작 과정에 주기적으로 검사점을 기록하여 데이터베이스 장애시 로그를 기반으로 회복하는 기법

특징
- 검사시점을 도입하면서, Undo를 다시 도입함
- 회복작업이 완료될 때까지 시스템은 새로운 트랜잭션을 받아들일 수 없음
동작
- 장애 발생 시 검사점 이전에 처리된 트랜잭션은 회복에서 제외하고
- 검사점 이후에 처리된 트랜잭션은 회복 작업 수행
  - 검사점 이후, 장애 발생 이전에 commit이 완료된 경우 Redo 수행
  - 장애 발생 시점까지 commit되지 못한 경우 Undo 수행
  - Undo/Redo의 수행
    - Step 1. Undo-list에 있는 모든 트랜잭션들에 대해 로그에 기록된 역순으로 Undo 연산 수행
    - Step 2. 그런 다음 Redo-list에 있는 트랜잭션에 대해 로그에 기록된 순서로 Redo를 수행
검사시점 (Checkpoint) 방법
- 로그 기록 유지, 일정시간 간격으로 검사시점 (Checkpoint) 설정
  - 메인 메모리(로그 버퍼)에 있는 모든 로그 레코드를 안정 저장소로 출력
  - 변경된 데이터 버퍼 블록을 전부 디스크로 출력
  - 검사 시점 표시로써 로그 레코드를 안정 저장소에 출력
    - 이 때, L은 현재 실행 중에 있는 트랜잭션들의 리스트

검사시점(checkpoint) 회복이 필요한 이유

일정한 간격으로 생성된 검사시점은 장애가 발생했을 때, 불필요한 부하를 줄이게 됨으로써 회복 처리 절차의 시간을 절약해 준다.
시스템 에러가 났을 때 회복관리자가 이를 해결하기 위해 로그 전체를 분석해야 되는데 시간이 많이 소요되고 불필요한 REDO 연산을 반복하는 문제가 발생하므로 검사시점 회복이 필요하다.

(3) 미디어 회복 기법

구현
- 로그 우선 기록 규약 (write-ahead log protocol)
  - 로그를 디스크에 써야지만 커밋할 수 있다.

References

Fundamentals of Database Systems 7th Edition by Ramez Elmasri, Shamkant B. Navathe.
https://overcome-the-limits.tistory.com/528
https://itwiki.kr/w/%EB%A1%9C%EA%B7%B8%EA%B8%B0%EB%B0%98%ED%9A%8C%EB%B3%B5_%EA%B8%B0%EB%B2%95
https://m.blog.naver.com/wook2124/222108776229
https://itwiki.kr/w/%EA%B2%80%EC%82%AC%EC%A0%90%ED%9A%8C%EB%B3%B5%EA%B8%B0%EB%B2%95
https://www.studocu.com/ko/document/dankook-university/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EA%B4%80%EB%A6%AC/%EA%B2%BD%EC%98%81%ED%95%99%EA%B3%BC-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EA%B0%9C%EB%A1%A0-%EA%B8%B0%EB%A7%90%EA%B3%A0%EC%82%AC-%EB%8C%80%EB%B9%84-%EC%9E%90%EB%A3%8C-%EA%B5%90%EC%9E%AC-%EB%B0%8F-%EC%88%98%EC%97%85-%EB%82%B4%EC%9A%A9-%ED%95%84%EA%B8%B0-%EB%85%B8%ED%8A%B8/17316211
https://m.blog.naver.com/paradice29/50184565199

This site is open source. Improve this page.