Transaction Processing System
- 여러 유저가 동시에 처리하는 커다란 데이터베이스 시스템
- 트랜잭션은 데이터 베이스 프로세싱의 논리적 단위가 정확성과 일관성을 위해 전부 실행되어야 한다.
- 일부만 실행되어선 안 된다, Atomic 하다.
Terminology
종류
- 읽기전용 / Read - Only
- 읽기-쓰기 / Read - Write
단어
- Data Item : 필드 값, 데이터베이스 튜플, 디스크 블록, 파일 전체, 데이터베이스 전체
- 각각의 Data Item들은 이름을 가져 특이하게 구분될수 있어야 한다.
- Granuarity : Data Item 의 크기
- Database : 이름 붙은 Data Item 들의 Collection
접근 연산자
- read_item(X) : Data Item X 를 읽어 변수에 저장
- write_item(X) : 변수의 값을 X Data Item 에 저장
- 트랜잭션의 시작, 끝, 읽기, 쓰기, 적용, 롤백
작동
Partially Commited - 메인메모리에 저장되어 빠르게 유저에게 응답한다.
- 마지막 연산까지 실행 완료 후 커밋 직전의 상황
- 동시성 제어에 의해 커밋이 가능한지 확인될수 있다.
- 복구 프로토콜에 의해 Failure과 이것이 데이터베이스에 끼치는 영향이 확인될수 있다.
- 이중 하나라도 실패하면 트랜잭션이 Abort된다, 즉 실패한다.
- 실패되거나 Abort된 트랜잭션은 다시 시작될수 있다.
- Terminated : 트랜잭션이 시스템에서 종료된다.
Recovery
- 트랜잭션이 어느정도 연산이 진행된 뒤에 실패할 경우 이전에 진행된 연산들은 모두 취소해야만 한다.
- 데이터베이스에 영향을 끼치지 못한다.
- 트랜잭션의 모든 연산이 완벽하게 완료될시 Committed 되어 데이터베이스에 영구히 남게 된다.
Failure 원인
- 컴퓨터 에러 : 하드웨어/소프트웨어/네트워크 에러
- 트랜잭션 / 시스템 에러 : 정수 오버플로우, 0으로 나누기, 유저 인터럽트
- 로컬 에러, 트랜잭션에서 발견된 예외 : 예외 조건에 의해 발견된것 ( 예시. 잔고 부족 )
- 동시성 제어 : 데드락
- 디스크 실패 : 디스크 블럭 작동 문제
- 물리적 문제 혹은 재난 : 불, 도둑, 정전
System Log
- DBMS가 Failure로부터 복구하기 위해 유지하는것
- 데이터 베이스 아이템의 값에 영향을 주는 트랜잭션 연산자를 계속 추적한다.
- 순차적이고 추가되기만 한다.
- 반드시 주기적으로 기록 스토리지에 백업되어야 한다.
Log Buffer
- 로그의 버퍼를 위해 하나 혹은 그 이상의 메인 메모리를 사용한다.
- 시작, 읽기, 쓰기, 적용, 롤백
- T는 트랜잭션
Commit Point
- 데이터베이스에 접근하는 모든 연산이 성공적으로 완료 및 로그에 작성시 Committed 했다고 한다.
- Failure 발생시, 커밋 기록이 있으면 로그로 부터 다시 작업을 진행한다.
- 커밋 로그가 없으면 starttransaction 부터 처음부터 시작한다 ( rollback )
Force writing
- 트랜잭션 commit 전에 로그 버퍼를 비운다.
- 디스크에 아직 쓰여지지 않은 로그 버퍼를 디스크에 작성한다.
- 로그가 제대로 남아있을수 있게 한다.
UNDO 연산자
- X 값을 이전값으로 복구한다.
- WRITE 연산자를 취소한다.
REDO 연산자
- X 값을 새로운 값으로 업데이터한다.
- ARIES 를 사용한다.
- 로그에서는 새로운 값으로 업데이트 하는데 성공했으나 데이터베이스에 작성하는데 실패했을때 작동한다.
ACID
A - Atomicity - 전부 실행되거나 실행되지 않거나 둘중 하나여야 한다.
C - Consistency - 트랜잭션 처리 전과 후에 테이블 내 데이터는 제약조건에 일치해야 한다.
I - Isolation - 트랜잭션을 수행시 다른 트랜잭션의 연산이 끼어들지 못하도록 보장한다.
D - Durability - 성공적으로 수행된 트랜잭션은 영원히 반영되어야 한다.
트랜잭션 스케쥴 S
- 트랜잭션의 연산 순서를 정하는것
- 하나하나씩 전부 완료 하는것 : Serial
- 여러 트랜잭션을 조금씩 실행해 나가는것 : Interleaved
Serial Schedule
- 트랜잭션이 완료 되어야 다음 트랜잭션이 실행된다.
- 트랜잭션이 순차적으로 진행된다.
- 항상 옳은 결과가 나온다.
- 동시성을 갖출수 없다.
- 다른 트랜잭션이 끝날때까지 기다릴수 없다, 현실적으로 사용 불가능하다.
- Serial 스케쥴과 동일하게 데이터가 무결하면서 빠른것이 필요하다.
NonSerial Schedule - Conflict
- 두 다른 트랜잭션에서 같은 Data Item 에 대해 한번 이상의 쓰기를 할 경우 발생한다.
- 읽기만 해선 발생 안함!
Concurrency Control
없으면 발생할수 있는 문제
- Lost update - 값이 쓰여지기 전에 읽혀져 변경이 제대로 적용되지 않는다.
- dirty read - 값을 읽어온 뒤에 갑자기 읽어온 값이 바뀔경우
- 왼쪽 트랜잭션이 값을 바꾸고 나서 오른쪽이 읽어왔는데 왼쪽 트랜잭션이 취소되는 경우이다.
- incorrect sum - 트랜잭션 하나가 전체의 합을 구하는 경우, 합이 전부 구해지기 전에 다른 트랜잭션에 의해 값이 변경될수 있다.
- 내가 값을 읽어올때는 직접 값을 바꾸지 않는 이상 값이 바뀌지 않아야 한다
- unrepeatable read - 한 트랜잭션이 같은 값을 두번 읽을때 그 사이에 다른 트랜잭션이 값을 바꾼 경우
- 트랜잭션은 같은 값을 읽어오지만, 읽어온 값은 다르게 된다.
해결
- 이들 문제를 해결하기 위해 Nonserial이나, Serializable한 스케쥴이 필요하다.
Serializable Schedule
- n개의 트랜잭션에 대해 Serial Schedule과 결과는 동일하나 반드시 다른 트랜잭션이 완료되어야 또 다른 트랜잭션이 실행되지 않아도 된다.
- 동시 트랜잭션이 실행되어도 언제나 옳다고 처리된다.
- 동시 실행의 이점을 얻을수 있다.
Concurrency Control Protocol
Two Phase Locking
- 가장 흔한 방식
- Data Item 에 락을 걸어 동시에 실행되는 트랜잭션이 서로를 방해하지 않도록 한다.
- 락을 거는 Growing Phase, 락을 해제하는 Shrinking Phase로 구성된다.
- 즉, 락을 해제 ( Shrink ) 한 이후에 락을 걸수 ( Growing ) 없다!
- Serializablity를 보증하기 위해 추가적인 조건을 넣는것
- 데드락이 발생할수 있다.
- 각각의 트랜잭션이 상대방이 서로 Lock한 Data Item을 기다리고 있을 경우
- 락의 상태가 테이블에 저장되기에, 락이 많으면 디스크를 너무 많이 쓸수 있다. ( High Overhead )
- 이전에 너무 많은 락이 걸려 있으면 연산을 실행할수 없는 Starvation에 빠질수 있다.
Serializable Methods
Snapshot isolation
- 트랜잭션이 시작할때의 데이터베이스 스냅샷을 기준으로 트랜잭션이 데이터를 사용 한다.
- 똑같은 테이블을 쿼리했는데 다른 값이 나오는 문제 ( Phantom ) 를 해결할수 있다.
Timestamp ordering
- 각각의 트랜잭션이 고유한 타임스탬프를 할당받는다.
- 충돌되는 연산은 이 타임스탬프 순서대로 동작한다.
Multiversion concurrent control protocol / MVCC
- Data item 의 여러 버전을 관리한다.
Optimistic protocol
- 트랜잭션 종료 및 커밋 이전에, 가능한 위반사항을 검사한다.
SQL TRANSACTION
-
모든 트랜잭션은 COMMIT, ROLLBACK 으로 끝난다.
-
모든 트랜잭션은 Isolation level을 가진다.
- READ UNCOMMITTED - 커밋 되지 않은 값 읽기
- READ COMMITTED - 커밋된 값만 읽기
- REPEATABLE READ - 팬텀값 허용
- SERIALIZABLE - 팬텀값 비허용
만능 컴덕후 겸 번지 팬