트랜잭션

 트랜잭션?

DB의 수행 단위

 

데이터 무결성을 지킴으로써 데이터 베이스의 일관된 상태를 유지하기 위한 핵심 개념

 

DBMS에서 데이터베이스를 다루는 하나의 논리적이 작업. 

 

일련의 작업을 단일 실행 단위로 그룹화. 각 트랜잭션은 특정 작업을 시작하고 그 그룹의 모든 작업이 성공적으로 완료되면 면 종료한다. 성공 또는 실패의 결과만이 있다.

일련의 하나의 과정을 그룹화해 직관적으로 알 수 있게 하는 것. 이런 하나의 과정을 트랜잭션이라고 한다.

 

트랜잭션은 데이터 무결성을 지킴으로써 데이터 베이스의 일관된 상태를 유지하기 위한 핵심 개념이다.

 

DB 상태를 변경시키기 위해 논리적 기능을 수행하는 하나의 작업 단위. 수행되어야할 연산의 집합이다.

 

SQL 문은 트랜잭션을 사용해 그룹화 된다.

 

트랜잭션의 연산 :  읽기read , 쓰기write, 완료commit, 복귀rollback

 

TCL ( Transaction Control Statements ):

COMMIT: 완료

트랜잭션의 작업이 성공되었음을 알려주는 연산자. 현재까지 진행된 트랜잭션으로 인한 변화를 영구적으로 저장. 

모든 SAVEPOINT들을 삭제, 트랜잭션 락을 해지. 트랜잭션이 종료되었음을 표시한다. 

 

ROLLBACK : 복구.

트랜잭션 작업이 실패되었음을 알리고 결과를 원상복귀 하는 연산자

트랜잭션을 마지막 커밋이나 롤백 단계까지 되돌린다. 

롤백은 SQL에 수행되며 변경한 모든 데이터를 복원한다. 아무 일도 일어나지 않았던 것처럼 만든다.

트랜잭션에서 sql문들에 의해 수행된 모든 갱신을 취소한다. 

데이터 베이스는 트랜잭션의 첫 구문이 실행되기 전의 상태로 돌아가게 된다. 

 

트랜잭션은 커밋과 롤백 작업을 수행한다.

SAVEPOINT : 나중에 롤백 할 수 있는 지점을 저장한다. 사용자의 필요에 따라 사용자가 트랜잭션 중간에 지정하는 마커의 개념.

 

- 데이터 베이스에서 트랜잭션을 정의하는 이유

1. 데이터베이스에서 데이터를 다루는 작업이 일어날 때 장애가 일어나는 경우, 장애에서 올바르게 데이터를 복구하는 작업의 단위를 트랜잭션으로 삼는다

2. 데이터 베이스에서 프로그램이 동시에 실행될 때 프로그램들을 서로 분리하는 단위이다.

 

 

 

트랜잭션의 특징: ACID

Atomicity 원자성: all or nothing. 모든 게 실패 혹은 모든 게 성공

 -> 트랜잭션이 제대로 실행되지 않았다면 롤백한다. 

회복

 

Consistency 일관성 : 트랜잭션 실행이 성공적으로 완료되면 db는 일관성 있는 상태를 가진다. 모든 트랜잭션은 데이터베이스에서 무결성 조건을 만족해야 한다.

동시성제어, 무결성 제약 조건

 

Isolation 고립성

동시성 제어. 이를 위해 고립 수준 Isolation level 제공

 

Durability 영속성: 트랜잭션이 일단 실행 완료되면 결과는 영구적이다. 

회복

 

 

[ dbms는 여러 사용자의 요청을 동시에 수행한다. 이 경우 트랜잭션 간 간섭을 없애고, 데이터 정합성을 일관성 있게 제공해야 하는데 이를 Isolation을 보장한다고 표현한다. 이를 다른 말로 표현하면 serializability 가 보장된다고 표현 할 수 있다. ]

 

트랜잭션의 상태

활동active: 활동 상태. 트랜잭션이 실행중. 동작중

부분 완료 Partially committed : 트랜잭션의 커밋 명령이 도착한 상태. 커밋 이전 sql문이 실행되고 커밋만 남은 상태

완료 Committed :  트랜잭션 이 정상적으로 완료된 상태. 

실패 Failed: 트랜잭션이 더 이상 정상적으로 진행할 수 없는 실패 상태

취소 Aborted: 트랜잭션이 취소되고 트랜잭션 이전 데이터로 돌아간 상태. roll back된 상태.

트랜잭션에서 변경하려는 내용이 데이터베이스에 일부만 반영된 경우, 원자성 보장을 위해 트랜잭션이 갱신한 사항을 트랜잭션이 수행되기 전의 상태로 되돌림.

두가지 옵션이 있다. 트랜잭션을 재시작하는 것과 트랜잭션을 킬 하는 것.

 

부분완료와 완료? 커밋 요청이 들어왔을 때 - 부분완료

커밋을 정상적으로 완료한 상태 - 완료

 

트랜잭션 스케줄

DB의 일관적인 상태를 유지하기 위해 동시에 실행되는 트랜잭션들의 연산 순서를 정하는 것이다.

여러 트랜잭션을 동시에 처리하기 위한 시간적 작업 순서이다.

연산 순서에 따라 결과가 달라지기 때문에 스케줄이 중요하다.

 

트랜잭션 스케줄을 사용하는 이유?

여러 트랜잭션이 실행되기 때문에 각 트랜잭션 안의 작업이 수행되는 순서에 따라 예상하지 못하는 결과가 나올 수 있다.

이를 방지하기 위해 DBMS는 각 트랜잭션의 독립성과 정확성을 보장하기 위해 동시성을 제어하는 방법을 사용해야 하는데, 대표적인 방법이 트랜잭션 스케줄링이다. 

 

트랜잭션 스케줄은 다음과 같은 조건을 만족해야 한다.

- 스케줄은 트랜잭션의 모든 연산을 포함하고 있어야 한다.

- 스케줄의 연산 순서는 트랜잭션 내에서의 연산 순서와 동일해야 한다.

- 스케줄 내 트랜잭션이 성공적으로 마무리 되면 마지막에 commit, 실패했다면 abort를 수행한다.

 

 

 

 

동시성 제어 concurrency control

동시에 수행되는 트랜잭션들이 데이터베이스에 미치는 영향은 이들을 순차적으로 수행했을 때 데이터에 베이스에 미치는 영향과 같도록 보장.

다중 사용자 환경을 지원하는 데이터베이스 시스템서 여러 트랜잭션이 성공적으로 실행될 수 있게 지원하는 기능

다수의 사용자가 데이터베이스를 동시에 접근하도록 허용하면서 데이터베이스의 일관성을 유지한다. 

트랜잭션의 직렬화 수행을 보장.

병행제어 라고도 한다.

 

트랜잭션의 목적: 

트랜잭션의 직렬성 보장

공유도 최대화, 응답 시간 최소, 시스템 활동의 최대 보장.

 

동시성 제어를 하지 않는다면 :

갱신손실 Lost update:  둘 이상의 트랜잭션이 동일 데이터를 수정할 때 발생한다. 하나의 트랜잭션이 데이터를 읽고 수정하기 전에 다른 트랜잭션이 동일 데이터를 수정해 이전에 수행한 변경 사항이 사라지는 현상

현행파악 오류 dirty read: 커밋되지 않은 다른 트랜잭션에 의해 수정된 데이터를 읽는 현상. 

하나의 트랜잭션이 아직 반영되지 않은 변경 사항을 읽어 오류 발생

모순성 Inconsistency : 데이터베이스 내의 데이터가 일관성을 유지하지 못하는 상태. 두 트랜잭션이 동시에 실행할 때 데이터베이스가 일관성이 없는 상태로 남는 오류

연쇄 복귀 Cascasing Rollback: 하나의 트랜잭션이 롤백될 때 그와 관련된 다른 트랜잭션도 함께 롤백되는 현상. 주로 트랜잭션간 종속성이 있는 경우 발생

 

동시성 제어 기법 : lock기반, MVCC, TimeStamp기반, 격리수준

 

스케줄 Schedule:

다수의 트랜잭션이 동시에 실행될 때 그 트랜잭션들에 속한 연산들의 실행 순서를 의미한다

 

DBMS는  serial schedule 직렬 스케줄, non serial schedule 비직렬 스케줄 두가지로 구분한다.

 

 

 직렬 스케줄 Serial Schedule

 격리성이 가장 높은 스케줄. 정확한 결과, 일관성 있는 결과를 만드는 스케줄.

모든 트랜잭션이 완료될 때 까지 다른 트랜잭션의 영향을 받지 않고 독립적으로 수행한다. 항상 일관된 결과를 생성하지만 순차적으로 수행하기 때문에 처리량 관점에선 효율적이지 않다. 순서를 완벽하게 보장한다는 말. 

한 트랜잭션의 모든 연산을 끝낸 후 다른 트랜잭션의 연산을 실행한다. 트랜잭션 별로 연산들을 순차적으로 실행

단점 느리다. 

 

 비직렬 스케줄 non serial schedule

여러 트랜잭션들을 동시에 실행

인터리빙(여러 트랜잭션들이 겹쳐 실행되는 경우) 방식 이용. 트랜잭션들을 병행 수행.

내부 연산이 번갈아 가며 병렬로 실행되는 스케줄 기법.

동시성이 높아지는 장점.

하지만 serializability 를 보장하지 않아 순서가 바뀜으로서 의도지 않은 결과값이 나올 수 있음. 

병행 수행 시 갱신 분실, 모순성, 연쇄복귀 등의 문제를 야기할 수 있음. 

최종 수행 결과의 정확성을 보장할 수 없다

 

 직렬 가능 스케줄 serializable schedules 

비직렬 스케줄의 결과가 어떤 직렬 스케줄의 수행 결과와 동등함. 

직렬 스케줄과 같이 정확한 결과를 생성하는 비직렬 스케줄.

모든 트랜잭션을 순차적으로 인터리빙 없이 실행한 결과를 내는 비직렬 스케줄링.

한 트랜잭션의 모든 연산이 끝난 후 다음 트랜잭션이 시작된다.  

제일 성능이 좋고, 일관성 유지가 가능하다.

이 serializable 을 계산하기 위해선 conflict serializable, view serializable 개념이 필요하다

 

 

 

 

충돌 직렬화 가능성 Conflict serializability  : 

데이터 베이스서 트랜잭션의 일관성과 격리 수준을 보장하기 위한 개념.

충돌 직렬화 가능성은 직렬 가능성(Serializability), 충돌(Conflict) 개념에 기반을 둔다.

 

[  conflict: 서로 다른 두 트랜잭션에서 작업의 순서가 전체 스케줄링의 결과에 영향을 미칠 때 발생.

서로 다른 트랜잭션에서 동시에 같은 데이터에 접근 할 때 발생한다.  ]

 

[ Serializablility  : 여러 트랜잭션을 병렬로 동시에 처리하면서도 순차적으로 수행한 것과 같은 결과를 도출.

동시에 온 트랜잭션 요청을 순차적으로 직렬화 시켜 트랜잭션 간의 간섭을 없애고 데이터 간 정합성을 맞추는 것을 의]

 

충돌 직렬 가능 conflict serializable 한 스케줄링 :

동일한 데이터 내 두 트랜잭션이 있을 때, 하나 이상의 연산이 write 인 경우 충돌conflict 가 발생할 수 있다. 즉 하나라도 write가 있으면 충돌이라고 부른다.

 

read, write 순서에 따라 결과 값이 달라진다 =  conflict operation 

read, read 뿐이라 뭘 먼저해도 결과값이 달라지지 않는다. 뭘 먼저해도 상관 없다 = non confict opetaion

 

 

 

View serializability 뷰 직렬화 가능성

트랜잭션 간의 데이터베이스 상태 전이를 비교해 트랜잭션들을 순차적으로 실행했을 때와 동일한 결과를 보장하는 것을 의미한다.

트랜잭션들이 동일한 데이터베이스 상태를 가지고 있는지 확인해 일관성을 보장한다.

 

 

모든 conflict serializability 는 view serializability 하다

 

Precedence Graph:

충돌 그래프 라고 한다.

데이터베이스에서 동시성을 제어하는 맥락에서 사용된다. 

 

복구 가능한 스케줄 Recoverable Schedule 

스케줄은 serializable 해야한다. = 직렬화 가능해야 한다. 데이터베이스서 다중 트랜잭션을 동시에 실행해도 동일 결과를 얻어야 한다. 

스케줄 s안에 있는 어떤 트랜잭션 t가 읽은 값에 쓰기 연산을 수행한 또 다른 트랜잭션이 완료되기 전까지 트랜잭션 t가 완료되지 않는 스케줄

 

Unrecoveralbe schedule이 발생하는 이유는, 커밋이 되기 전 데이터를 읽어서이다.

항상 커밋을 먼저 해줘야 한다. 커밋 미실행시 연쇄적인 스케줄 cascading schedule이 만들어진다.

 

연쇄적인 스케줄이란, 하나의 트랜잭션 취소로 인해 다른 트랜잭션들이 롤백되는 현상이다. (하나의 트랜잭션 실패 시 여기에 의존했던 것들이 다 실패되고 로그가 꼬인다. )

 

 

 

회복 시스템 recovery

장애 이후 회복. 장애 발생 시 장애 이전의 상태로 복구 시키는 것이다.

장애 후 회복이 됐을 때 상태가 일관되게 만드는 것을 리커버리 라고 한다. 

데이터베이스를 갱신하는 도중 시스템이 고장나도 데이터베이스의 일관성을 유지한다.

 

고장이 발생하기 전 트랜잭션이 완료 명령을 수행했다면, 회목 모듈은 이 트랜잭션의 갱신 사항을 재수행 redo하여 트랜잭션의 갱신이 지속성을 갖도록 해야 한다.

고장이 발생하기 전에 트랜잭션이 완료 명령을 수행하지 못했다면, 원자성을 보장하기 위해 이 트랜잭션이 데이터베이스에 반영했을 가능성있는 갱신 사항을 취소 undo해야 한다 .

회복은 원자성, 영속성과 관련이 있다

 

log: db 변경 내용을 저장하는 파일이다. 변경하기 이전의 값, 변경하기 이후의 값 등을 기록한 파일.

레코드 단위, 트랜잭션 수행과 동시에 기록된다.

 

시스템 오류 발생 시 데이터 베이스를 일관된 상태로 되돌리려면 해당 로그가 필요하다

 

 

 

검사 시점,

회복연 연산, 검사시점 UNDO, REDO

undo : 실행 취소. 원상태로 돌리다. 예전 상태로 연산을  취소해 복구. 되돌리기 위한 변화. 롤백될 때 사용. 무언가를 되돌리는 것. 

사용자가 수행한 작업을 이전 상태로 되돌리는 기능

최신 데이터를 오래된 것으로 만들기 위해 존재.

해당 트랜잭션이 수행한 변경 사항을 취소하고 이전 상태로 되돌린다.

롤백에 대비, 중단된 트랜잭션 복구, read consistency 보장.

작업 롤백과 읽기 일관성 복구를 함. 

 

redo : 재실행. 다시 하다. 최근 저장한 db 복사본을 가져온 후 로그를 이용해 모든 연산을 재실행하여 복구하는 것. 재생하기 위한 변화, 무언가를 다시 하는 것. 오래된 데이터를 최신 데이터로 만들기 위해 존재. 커밋 될 때 사용.

트랜잭션이 커밋되면 redo 기술은 해당 트랜잭션이 수행한 변경 사항을 다시 적용해 데이터베이스의 현재 상태로 업데이트 한다. 

복구한다. 데이터의 손실을 방지한다.

사용자가 undo로 취소한 작업을 다시 실행하는 기능. 사용자가 이전에 실행한 작업을 되돌리 후 다시 실행. 

 

 

트랜잭션 수행 중 변경된 데이터를 로그 파일에 기록. 일정 기간 단위로 로그와 버퍼를 디스크에 반영. 로그파일에 검사시점 (check point) 표시

 

Undo log:

롤백을 하기 위한 로그. 충돌이 일어나면 undo를 원복할 때 사용한다.

실행 취소 로크 레코드의 집합. 트랜잭션 실행 후 롤백이나 undo log를 참조해 이전 데이터로 복구할 수 있도록 로깅해놓은 영역

check point 시 디스크에 기록

변경 전의 값을 기록, backing

 

Redo log: DB 장애발생시 복구에 사용되는 log.

DML, DDL, TCL 작업 등 데이터 변경이 있을 때 기록한다. 

Redo 의 의미 : 변경되는 작업 내용이 있을 경우 기록해 장애를 대비하는 기능. 

목적 : db recovery. db 복구를 위해 사용,

instance recovery. instace가 비정상적으로 종료됐을 때 트랜잭션 데이터의 유실에 대비하기 위해 사용

fast commit : 트랜잭션 발생 시 하나씩 데이터 파일에 기록하기 보다 우선 변경 사항을 redo log에 기록하고 메모리 데이터 블록과 데이터 파일 간 동기화는 나중에 일괄적으로 수행하는 기능. 

변경 후의 값을 기록, forwarding 

 

 

회복 기법

Checkpoint :

검사점을 이용한 데이터 복구 기법.

로그 파일에 체크포인트를 기록라고 장애 발생 시 체크포인트 이전에 처리된 트랜잭션은 회복 작업에서 제외하고

이후에 처리된 내용에서만 회복 작업을 수행하는 회복 기법.

DBMS는 회복 시 재수행 할 트랜잭션의 수를 줄이기 위해 체크포인트를 수행한다.

 

트랜잭션에 로그를 남겨 backward 방식으로 리커버리(undo) 하는 것은 좋으나, 그 범위가 너무 클 때, 이 문제를 해결하기 위해 체크포인트 개념 도입.

체크포인트 이후의 상태만 redo 한다. 

 

평소 동작: 트랜잭션 수행 중, 체크포인트 기반으로 로그 기록을 수행한다. 

 

회복 동작 : 트랜잭션 수행 중에 장애 발생 시, 로그 정보를 모두 검사 redo, undo 연산을 실행할 트랜잭션과 체크 포인트 선정, 검사점의 로그 기록을 기반으로 redo/ undo 수행.

검사점 이전 시작된 트랜잭션은 redo, 검사점 이후 새로 시작한 트랜잭션은 undo 

 

 

- 체크 포인트 이전에 시작해 체크 포인트 이전에 완료된 트랜잭션은 회복 대상이 아니다.

- 체크 포인트 이전, 이후와 관계 없이 시작해 장애 발생 시간에 진행 중인 트랜잭션은 undo대상이다.

- 체크포인트 이전, 이후와 관계 없이 시작해 장애 발생 시간 이전에 완료된 트랜잭션은 redo 대상이다. 

 

 

병행제어 concurrency control:

트랜잭션이 병행 수행될 때 트랜잭션이 데이터베이스의 일관성을 파괴하지 않고, 다른 트랜잭션에 영향을 주지 않도록 트랜잭션간의 상호작용을 제어하는 것이다. 

 

병행제어의 목적:

데이터 베이스의 일관성 유지

데이터 베이스 공유 최대화

시스템 활용도 최대화

사용자 응답 시간 최소화

단위 시간당 트랜잭션 처리 건수 최대

 

병행제어를 하지 않을 때 문제점: 갱신 분실,모순성, 연쇄복귀, 비완료 의존성

 

Locking 로킹 : 

동시성 제어 기법

언제 발생하나? 트랜잭션 2개,테이블 1개 같이 트랜잭션이 같은 테이블을 다룰 때 발생.

이때 lock 을 사용해 해결한다

트랜잭션이 접근하려는 데이터를 다른 트랜잭션이 접근하지 못하도록 잠그는 병행제어 기법 

이를 통해 상호배제 기능 제공, 잠금이 설정된 트랜잭션이 해제 (unlock) 될 때 까지 데이터를 독점적으로 사용할 수 있다.

 

한 번에 로킹 할 수 있는 데이터의 크기를 로킹 단위 라고 한다.

 

이를 통해 동시성 문제를 해결한다

 

멀티 트랜잭션 환경에서 데이터베이스의 일관성과 무결성을 유지하기 위해 트랜잭션의 순차적 진행을 보장할 수 있는 잠금 장치이다. 

 

하지만 교착상태 deadlock가 발생할 수 있다. 

 

락의 유형 

Shared Lock 공유락: read only. 다른 트랜잭션이 잠긴 객체를 읽고 다른 공유 락을 생성하는 것은 허용. 하지만 write나 xlock을 생성하는 것은 불허.

여러 트랜잭션이 동일 행에 공유 락을 생성할 수 있다. 즉, 다른 트랜잭션이 읽고 있는 행을 읽을 수 있음. 

 

 

Exclusive lock 베타락 : read write. 수정할 때 사용. 동일 행에 다른 트랜잭션을 생성하는 것을 허용하지 않음.

베타락이 걸리면 공유락을 걸 수 없다. 

어떤 트랜잭션에 데이터를 변경하자고 할 때 해당 트랜잭션이 완료될 때 까지 해당 테이블 혹은 row를 다른 트랜잭션이 읽거나 쓰지 못함.

해당 데이터에 대한 동시 읽기 및 쓰기를 막는다. 

 

 lock 사용 규칙:

트랜잭션 데이터를 읽을 때 공유락 요청 / 쓰거나 읽을 때 베타락 신청 - 데이터에 아무런 락이 걸려있지 않다면, 트랜잭션이 락을 걸려고 할 때 허용 - 데이터에 락이 걸려 있다? -트랜잭션이 lock share 를 요청할 경우, lock share 가 걸려 있는 경우 허용, 나머지는 락 허용 하지 않음 - 트랜잭션이 락을 허용바지 못하면 그 트랜잭션은 대기 상태가 된다.

 

베타락이 걸려 있는 데이터에는 다른 트랜잭션의 공유락, 베타락 요청을 수락 할 수 없다.

 

= LOCK  사용시 두 트랜잭션이 동시에 쓰기는 금지.

Deadlock: 서로가 잡은 락을 기다려 더 이상 진행하지 못하는 상태

여러 트랜잭션이 특정 데이터에 lock한 채, 다른 트랜잭션이 lock 을 수행한 데이터에 접근하려고 할 때 실행하지 못하고 무한정 기다리는 상태. 

해결 방법 : 교착 상태에 빠진 트랜잭션 중 하나를 철회하고 로크를 해제한다.

교착 상태 예방 프로토콜을 사용한다.

락 매니저로 관리한다. dbms서 롤백을 해결해준다. 

 

Two phase locking protocal , 2PL ,2단계 로킹 규약

동시성 제어 기법이다. 

모든 트랜잭션들이 lock 과 unlock연산을 확장 단계와 수축 단계로 구분하여 수행한다.

각 트랜잭션의 락과 언락 요청을 2단계로 실시하는 방식이다.

이를 통해 직렬성을 보장하는 대표적인 로킹 규약. 하지만 여전히 lock연산으로 인한 교착상태를 예방할 수는 없다.

확장 단계 Growing phase 와 축소 단계 shriking phase 단계로 나뉜다. 

확장 단계 : 새로운 락 연산만 수행 가능. 언락 연산은 수행할 수 없는 단계

트랜잭션이 락을 획득하는 단계. 트랜잭션이 데이터를 읽거나 쓸 때 해당 데이터에 락을 획득한다.

트랜잭션은 lock 연산만 실행 할 수 있고 unlock 연산은 실행할 수 없다.

축소 단계 : unlock 연산 수행 가능, 락lock연산은 수행 불가.

트랜잭션은 필요한 작업을 수행하고 데이터베이스를 수정 후 락을 해제한다.

 

락은 어떤 연산을 수행하기 전, 필요한 락들을 다 잡아놔야 한다. -?

연산이 끝난 후 락은 release되어야 한다. 

중간에 락이 풀리게 되면 serializable한 스케줄이 안될 수 있다.

트랜잭션 내 모든 lock 연산이 첫 번째 unlock 연산 이전에 위치해야 한다. 따라서 하나의 트랜잭션에서 데이터에 대한 연산을 완전히 끝낸 후 unlock 하므로 직렬성이 보장된다. 

 

 

MVCC 다중 버전 병행 제어

동시성 제어 기법이다.

동시 접근을 하용하는 데이터베이스에서 동시성을 제어하기 위해 사용한다. 

트랜잭션의 타임 스탬프와 접근 데이터의 여러 버전 타임 스탬프를 비교해 직렬 가능성이 보장되는 버전을 택한다. 

한 데이터에 대해 여러 버전의 값을 유지하며 관리하는 방식. 타임 스탬프의 개념을 이용한다. 

여러 버전의 타임 스탬프를 비교해 스케줄상 직렬 가능성이 보장되는 타임 스탬프를 선택한다.

충돌이 발생할 경우 연쇄 복귀가 발생 할 수 있는 단점이 있다. 

 

mvcc는 업데이트 될 때마다 새로운 버전을 만든다.

 

사용자가 업데이트를 하면 이전 버전에 덮어 씌우는 것이 아니라 새로운 버전의 데이터를 undo영역에 생성한다. 이전 버전의 데이터와 비교해여 변경된 내용을 기록한다. 

이렇게 해 하나의 데이터에 대한 여러 버전의 데이터가 존재하게 되고, 사용자는 마지막 버전의 데이터를 읽게 된다.

 

shared lock이 없는 상태. 잠금을 필요로 하지 않는다. 리드는 어떠한 락도 잡지 않고 리드를 한다.

write에 대해서만 동시에 실행되지 않게 xlock 을 지원한다.

read에 대한 lock이 없다 -> write도 더 빠르다. -> 일반적인 RDBMS보다 빠르다.

사용하지 않는 버전의 데이터가 계속 쌓인다 -> 어느 순간에 버전 클린업을 해야한다 -> gc가 필요하다. 

 

낙관적 검증 Validation :

트랜잭션 수행 동안 어떠한 검사도 하지 않고 트랜잭션 종료 시 일괄적 검사

특징 : 트랜잭션 수행 동안 그 트랜잭션을 위해 유지되는 데이터 항목들의 지역 사본에 대해서만 갱신이 이뤄진다.

트랜잭션 종료 시에 동시성을 위한 트랜잭션 직렬화가 검증되면 일시에 db 반영.

 

TimeStamp Ordering :

데이터베이스 시스템이 들어오는 트랜잭션 순서대로 system clock 시스템 클럭/ logical counter 논리적 계수기를 할당하고 순서를 부여해 동시성 제어의 기준으로 사용한다. 

 

[논리적 계수기 : 트랜잭션이 발생할 때마다 카운터를 하나씩 증가

시스템 클럭: 트랜잭션이 시스템에 들어올 때마다 시스템 시각을 부여한다.]

 

Timestamp : 트랜잭션을 식별하기 위해 dbms가 부여하는 유일한 식별자를 지정해 트랜잭션간의 순서를 미리 선택하는 동시성 제어 기법

특징 : 시스템에 들어오는 트랜잭션의 순서대로 시간 스탬프를 지정해 동시성 제어의 기준으로 사용.

교착 상태를 방지할 수 있으나 롤백 발생률이 높고 연쇄 복귀를 초래 할 수 있음

 

 트랜잭션 분리 수준

 

 트랜잭션 동시 실행 문제

트랜잭션 모두가 쓰기를 하는 경우 -> lock으로 해결

한 트랜잭션은 읽고, 한 트랜잭션은 쓴다면?

 

Dirty Read

트랜잭션이 다른 트랜잭션이 수정중인 데이터를 읽는 것. 수정 중인 데이터가 커밋되지 않았기 때문에 발생하는 문제.

데이터가 롤백, 수정 될 수 있기 때문에 일관성을 해친다.

 

Non-Repeatible Read 반복 불가능한 

트랜잭션이 동일 쿼리를 두 번 실행했을 때 결과값이 다른 것.

데이터가 변경될 때 발생하는 문제

 

Phantom Read

트랜잭션이 동일 쿼리 두 번 실행시, 첫번째와 두번째 결과 사이에 새로운 행이 삽입된 경우.

데이터가 추가될 때 발생되는 경우 발생

 

 

트랜잭션 분리 수준 명령어, 고립화

 

READ UNCOMMITTED ( LEVEL = 0):

미완료된 트랜잭션 읽기

가장 저수준의 고립화. 수정 중인 데이터를 읽을 수 있다. 이 때문에 더티 페이지의 데이터를 읽게 되고, 일관성이 보장되지 않는다. 

즉, 아무런 공유 잠금이나 독점 잠금이 걸리지 않게 되고, COMMIT 되지 않은 불완전한 상태, 트랜잭션이 끝나지 않은 데이터를 참조하게 된다. 이 옵션은 SELECT 질의의 대상이 되는 테이블에 대해 NOLOCK을 설정하는 것과 같다. 

더티 리드, 반복불가능읽기, 팬텀 문제 발생

 

READ COMMITTED ( LEVEL = 1):

완료된 트랜잭션 읽기. 한 트랜잭션이 다른 트랜잭션이 커밋된 데이터만 읽을 수 있다. 

더이 페이지 참조하는 것을 피하기 위해 데이터를 읽는 동안 공유 잠금이 걸리지만, 트랜잭션이 끝나기 전에 데이터는 변경되고, 결과적으로 데이터는 연속적이지 않거나, 유령 데이터 (Phantom Data) 가 된다. 

이 옵션은 sql서버의 기본 설정.

팬텀 문제 발생

 

REPEATIBLE READ (LEVEL = 2) :

한 트랜잭션이 읽은 데이터는 다른 트랜잭션이 수정해도 변경되지 않음

질의에 이용되는 모든 데이터에 잠금이 적용되어 다른 사용자가 UPDATE를 할 수 없다.

다른 사용자의 의한 유령 데이터가 INSERT될 가능성이 있다. 이유는 다른 고립화 수준에 비해 데이터의 현재성 (Concurrency) 가 부족하기 때문이다. 

팬텀 문제 발생

 

SERIALIZABLE ( LEVEL = 3 ):

직렬 가능

가장 고수준의 고립화 수준. 모든 트랜잭션은 다른 트랜잭션에 대해 완벽하게 분리 된다. 순차적으로 실행되는 것처럼 처리된다. 

즉, 데이터 집합에 대한 범위적인 잠금을 설정 할 수 있기 때문에 다른 사용자의 데이터 변경을 위한 트랜잭션이 완벽하게 분리된다. 이 옵션은 네가지 고립화 수준 중 가장 제한이 심하고, 데이터의 현재성도 가장 낮다. 

이 옵션은 SELECT 질의의 대상이 되는 테이블의 질의에 HOLDLOCK을 설정하는 것과 같은 효과를 얻을 수 있다.

오손 판독, 반복 불가능 읽기, 팬텀 문제 모두 에방

 

격리 수준이 높아질수록 데이터 일관성은 보장되지만 동시성은 감소한다

 

[ 데이터의 현재성 : 동시에 여러 사용자나 프로세스가 데이터를 액세스 하고 수정 할 수 있는 능력 ]

 

[HOLDLOCK : 특정 테이블이나 데이터에 대한 락을 유지하는 데 사용. 데이터의 일관성과 무결성을 보장하기 위해 사용.

다른 트랜잭션에 의해 데이터가 변경되는 것을 방지. 하지만 데드락과 성능저하를 초래 할 수 있다. ]

 

 

 

정리

- 트랜잭션의 동시 실행 - LOST UPDATE 발생, 잘못된 데이터 값이 저장됨 -> LOCK을 사용해 해결.

 

- LOCK을 사용하고, 한 트랜잭션은 읽기, 한 트랜잭션은 쓰기

READ UNCOMMITTED 이면 DIRTY READ 발생.

READ COMMITTED 이면 Non Repeatible read 발생. 

REAPETIBLE READ 이면 Phantom Read 발생.

 

- LOCK 사용, SERIALIZABLE 이면 문제 없다.

그러나 한 트랜잭션은 읽기, 한 트랜잭션은 쓰기 동시에 실행 불가.

둘 다 읽기만 할 때 가능하다.