[데이터베이스] 트랜잭션, 동시성 제어

트랜잭션

DBMS가 데이터베이스를 다룰 때 사용하는 작업(프로그램)의 단위

• 트랜잭션은 일반 프로그램과 달리 데이터베이스의 데이터를 다루기 때문에 데이터베이스의 무결성을 유지해야한다.
• 트랜잭션은 ACID 성질을 갖는다.
  • DBMS는 트랜잭션이 이러한 성질을 유지할 수 있도록 지원한다.

 

트랜잭션의 개념

트랜잭션 : DBMS에서 데이터를 다루는 논리적인 작업의 단위
보통 단일 sql문을 사용하여 데이터를 다루기도 하지만, 여러 개의 sql문을 순차적으로 수행하여 데이터를 다루기도 한다.

 

트랜잭션 정의하는 이유

• 데이터베이스에서 데이터를 다룰 때 장애가 발생할 경우, 트랜잭션은 장애 시 데이터를 복구하는 작업의 단위
• 데이터베이스에서 여러 작업이 동시에 데이터를 다룰 때, 트랜잭션은 이 작업을 서로 분리하는 단위

 

트랜잭션은 전체가 수행되거나 전혀 수행되지 않아야한다.(all or nothing)

예시 : A 계좌에서 B계좌로 10000원 이체

1번 sql문과 2번 sql문은 모두 수행되거나 아예 수행되지 않아야한다.

만약 1번 문이 실행되고 2번 문을 실행하지 못할 경우 1번 문을 취소해야한다.

 

DBMS에게 1번과 2번문이 하나의 실행 단위라는 것을 알리기 위해 트랜잭션 시작과 끝을 명시한다.

 

수행 과정

데이터베이스 데이터는 하드디스크에 저장되어있고, 데이터 처리를 위해서 주기억장치의 버퍼로 사본을 읽어와야한다.

• 트랜잭션은 데이터베이스에 저장된 테이블을 읽어와 주기억장치인 버퍼에 저장하고, 버퍼에 저장된 데이터를 수정한 후 최종적으로 데이터베이스에 다시 저장한다.

 

부분완료

• 트랜잭션의 종료를 사용자나 다른 트랜잭션에게 알리는 단계
• 트랜잭션 수행은 완료되었지만 변경 내용이 데이터베이스에 기록되었는지 확실하지 않은 상태

  DBMS가 최종적으로 변경 내용을 데이터베이스에 기록해야 완료 상태가 된다.
  만약 시스템 내부 문제 혹은 시스템 다운 등으로 DBMS가 변경 내용을 데이터베이스에 기록하지 못하면 실패 상태가 된다.

부분 완료된 트랜잭션은 다른 트랜잭션의 작업 상황을 봐 가면서 변경 내용을 하드디스크에 기록한다.
기록이 끝나면 완료(commit)한다.

완료 후에는 다른 트랜잭션이 데이터를 자유롭게 사용할 수 있다.

• 트랜잭션은 사실적으로 1~6번이 완전 끝난 후지만, DBMS는 1~4까지 수행하고 사용자에게 완료 사실을 알린다(부분완료). 그리고 5,6은 DBMS가 책임지고 수행한다.
• 즉 트랜잭션은 임시로 종료를 선언하고 실제 데이터베이스에 기록하는 것은 dbms가 수행한다.

이유1 : DBMS가 동시에 많은 사용자의 트랜잭션을 수행할 때 각각의 트랜잭션이 하드디스크에 개별 접근하는 것을 피하고 DBMS에 일관적으로 접근하기 위해

이유2 : 수행 결과를 데이터베이스에 저장하는 5,6 과정이 시간이 많이 소요되고 다른 트랜잭션이 동일한 테이블을 또 필요로 할 수 있기 때문

 

트랜잭션의 성질

트랜잭션은 데이터베이스에 저장된 데이터를 다루며 DBMS에 의해 처리된다.

일반 프로그램은 파일에 저장된 데이터를 다루며 컴파일러에 의해 처리된다.

1. 원자성(Atomicity) : 트랜잭션에 포함된 작업은 전부 수행되거나 전부 수행되지 않아야 한다.
2. 일관성(Consistency) : 트랜잭션을 수행하기 전이나 수행한 후나 데이터베이스는 항상 일관된 상태를 유지해야 한다.
3. 고립성(Isolation) : 수행 중인 트랜잭션에 다른 트랜잭션이 끼어 들어 변경 중인 데이터 값을 훼손하는 일이 없어야 한다.
4. 지속성(Durability) : 수행을 성공적으로 완료한 트랜잭션은 변경한 데이터를 영구히 저장해야한다. 저장한 데이터베이스는 저장 직후 혹은 어느 때나 발생할 수 있는 정전,장애,오류에 영향을 받지 않도록 해야 한다.

 

원자성

트랜잭션이 원자처럼 더이상 쪼개지지 않는 하나의 프로그램 단위로 동작해야한다.

all or nothing

• DBMS는 원자성을 유지하기 위해 회복 관리자 프로그램을 작동시킨다.

회복 관리자 프로그램은 데이터베이스가 변경한 내용을 로그로 기록하고 있다가 트랜잭션에 문제가 생겼을 때 원래 상태로 되돌린다.

 

TCL

• 트랜잭션 시작과 끝을 표기하기 위해 BEGIN TRANSACTION, COMMIT TRANSACTION 명령어를 사용한다.
• 트랜잭션 중간에 작업을 멈추면 회복 알고리즘을 이용하여 변경 내용을 취소한다. 또는 자의적으로 트랜잭션을 취소하는 명령어 ROLLBACK을 사용한다.
  • savepoint(저장점) : 트랜잭션 길이가 긴 경우 트랜잭션의 중간 지점에 수정내용을 반영하는 point를 만든다. 이 경우 rollback을 하면 savepoint까지만 진행하도록 하여 트랜잭션 전체가 롤백하는 것을 막는다.

savepoint 시점으로 이동

 

일관성

트랜잭션을 수행하기 전이나 수행한 후나 데이터베이스는 항상 일관된 상태를 유지해야 한다.

• 일관성은 테이블이 생성될 때 CREATE 문과 ALTER 문의 무결성 제약조건을 통해 명시된다.

PK, unique, not null..

• DBMS는 일관성을 유지하기 위해 무결성 제약조건을 활용한다. 트랜잭션 수행시 데이터가 변경되면 DBMS는 미리 정의해둔 무결성 제약조건을 검사하여 일관성이 깨지는 것을 막는다.
• 만약 두 개의 트랜잭션이 동시에 수행될 때 트랜잭션 간에 간섭으로 일관성이 깨질 경우 동시성 제어 알고리즘을 작동시켜 트랜잭션들이 질서 있게 접근하도록 해야한다.

 

고립성

• 데이터베이스는 공유가 목적이므로 여러 트랜잭션이 동시에 수행된다.
  동시에 수행되는 트랜잭션은 상호 존재를 모르고 독립적으로 수행되는데, 이를 고립성이라고 한다.
• DBMS는 고립성을 유지하기 위해 동시성 제어 알고리즘을 작동시킨다
  동시성 제어 알고리즘을 작동시켜 여러 트랜잭션이 동시에 같은 데이터를 접근할 때 마치 한 트랜잭션씩 순서대로 접근하는 것처럼 제어한다.
  • 고립성을 유지하기 위해서는 트랜잭션이 변경 중인 임시 데이터를 다른 트랜잭션이 읽고 쓸 때 제어가 필요하다.
  • 동시성 제어 : 같은 데이터를 동시에 읽고 쓸 경우 충돌하지 않도록 제어하는 작업
• 트랜잭션 고립 수준에 따라 트랜잭션의 상호 간섭을 배제시키는 방법도 있다.

 

지속성

트랜잭션이 성공적으로 완료 혹은 부분 완료한 데이터는 DBMS가 책임지고 데이터베이스에 기록한다.

• DBMS는 지속성을 유지하기 위해 회복 관리자 프로그램을 이용한다.
  • DBMS 복구 시스템은 트랜잭션이 작업한 내용을 수시로 로그 데이터베이스에 기록해두었다가 문제가 발생하면 로그 파일을 이용하여 복구 작업을 수행한다.

트랜잭션 작업으로 변경된 내용은 시스템이 고장나더라도 유지된다.

•  

트랜잭션은 수행을 완료하면 부분 완료 혹은 실패 상태 중 하나가 된다.

• 부분완료에서는 작업한 내용을 데이터베이스에 저장한다.
• 실패에서는 작업한 내용을 취소한다. (트랜잭션이 수행한 작업을 원상복구한다.)
  • 실패 : 트랜잭션을 중간에 중단하였거나 부분완료 상태에서 변경 내용을 데이터베이스에 저장하지 못한상태.

 

ACID를 지원하는 DBMS

 

동시성 제어

데이터베이스는 공유를 목적으로 하기 때문에 가능한 많은 트랜잭션을 동시에 실행시켜야한다.
동시에 수행되는 트랜잭션은 다른 트랜잭션이 같은 데이터를 공유하고 있다는 사실을 모를 수 있기 때문에 일관성이 훼손될 수 있다.
=> 동시성 제어는 트랜잭션이 동시에 수행될 때, 일관성을 해치지 않도록 트랜잭션의 데이터 접근을 제어하는 기능이다.

 

트랜잭션 읽기/쓰기 시나리오

• 상황 1 : 두 트랜잭션이 모두 읽기만 하는 경우, 동시 실행시에도 아무 문제가 없다.
• 상황 2 : 한 트랜잭션만 쓰고 다른 트랜잭션은 읽을 경우 문제가 발생한다. => 트랜잭션 고립 수준
• 상황 3: 두 트랜잭션이 모두 쓰기 작업을 수행할 경우 갱신 손실 문제가 발생한다.

먼저 두 트랜잭션이 모두 쓰기 작업을 수행할 경우 발생하는 문제를 살펴보자

 

갱신손실(lost update) 문제

두 개의 트랜잭션이 한 개의 데이터를 동시에 갱신할 때 발생

 

예시

x계좌에 1000원이 있다.
T1 : X계좌의 예금을 100원 인출한다. (UPDATE)
T2 :X계좌의 예금을 100원 입금한다. (UPDATE)
=> 결과 : X계좌의 총합은 1000원이다.

 

갱신 손실 문제 발생 케이스

T1과 T2의 작업을 동시에 수행할 때, T2는 T1이 갱신중인 데이터를 읽어와 작업을 진행하며 T1의 결과(900)에 덮어쓰기를 수행한다.
=> 결과 : 갱신손실 문제 발생, X계좌의 총합은 1100원이다.

갱신손실 문제를 해결하기 위해 T1이 종료한뒤에 T2를 실행하거나 T2 실행 후 T1을 실행해도 되지만, 데이터베이스의 공유와 빠른 처리를 위해 그럴 수 없다.
갱신 손실 문제를 해결하고 트랜잭션을 동시에 실행시킬 수 있는 방법을 알아보자.

 

락(Lock)

트랜잭션이 데이터를 읽거나 수정할 때 데이터에 표시하는 잠금 장치

자신이 사용할 데이터를 잠금(lock)하면 다른 트랜잭션은 잠금이 풀릴때까지 기다린다.

• (쓰기, 쓰기) 문제를 해결한다.

 

락을 이용한 갱신 손실 문제 해결

T1이 X에 락을 설정하였기 때문에 T2는 T1이 사용중인 데이터 X에 대해 락을 얻을 수 없어(읽어올 수 없어) 대기한다.
T2는 T1이 X의 락을 해지(unlock)하면 X에 대한 작업을 진행할 수 있다.
=> 락을 사용하면 데이터 X에 대한 갱신을 순차적으로 진행할 수 있으므로 갱신손실 문제를 해결할 수 있다.

 

sql 문으로 보는 갱신 손실 예시

• T1 : 1번 도서의 가격을 조회한 후 가격을 7100원으로 업데이트한다.
• T2 : 1번 도서의 가격을 조회한 후 가격을 100원 올린다.

트랜잭션 동시실행 과정!

• T1에서 가격을 7100원으로 업데이트한 후(UPDATE 실행 후) T2를 실행하면 X에 락이 걸려있어서 조회 및 UPDATE를 실행할 수 없다.
• T1이 COMMIT되어 종료되면 X에 대한 락이 해제되며 T2는 조회 및 UPDATE문을 진행하고 종료한다.

 

락 최소화

• 락은 트랜잭션이 다루는 데이터를 다른 트랜잭션이 중간에 접근하지 못하도록 막아, 다른 트랜잭션을 대기 상태로 만든다.
• 다른 트랜잭션을 대기 상태로 만드는 것은 사용자의 응답 시간에 영향을 주기 때문에 가능한 최소화해야한다.

수강신청시 동시접속하는 사용자가 많으면 느려질 수 있다.

 

락의 유형

• 공유락(LS, shared lock) : 트랜잭션이 읽기를 할 때 사용하는 락
• 배타락(LX, exclusive lock) : 트랜잭션이 읽고 쓰기를 할 때 사용하는 락

읽기만 하는 데이터는 허용해도 문제가 없으므로 읽기 표시 락과 쓰기 표시 락으로 나눈다.

 

락 사용 규칙

• 데이터에 락이 걸려있으면 트랜잭션은 데이터에 락을 걸 수 있다.
• 트랜잭션이 데이터 X를 읽기만 할 경우 LS(X)를 요청하고, 읽거나 쓰기를 할 경우 LX(X)를 요청한다.
• 다른 트랜잭션이 데이터에 LS(X)를 걸어둔 경우, LS(X)의 요청은 허용하고 LX(X)는 허용하지 않는다.
• 다른 트랜잭션이 데이터에 LX(X)를 걸어둔 경우, LS(X), LX(X) 모두 허용하지 않는다.
• 트랜잭션이 락을 허용받지 못하면 대기 상태가 된다.

 

락 호환행렬

트랜잭션의 공유락은 상호 호환이 되지만, 배타락은 허용되지 않는다.

 

2단계 락킹

트랜잭션이 락을 걸고 해제하는 시점에 제한을 두지 않으면 두 개의 트랜잭션이 동시에 실행될 때 데이터의 일관성이 깨질 수 있다.

T1 트랜잭션이 데이터에 락을 걸고 푸는 과정에서 T2 트랜잭션이 T1 트랜잭션 커밋 전에 락을 얻어 A의 중간 결과가 노출될 수 있다. 즉, 데이터 일관성이 깨질 수 있다.

 

=> 트랜잭션이 락을 걸고 해제하는 시점을 정한다.

• 확장단계 : 트랜잭션이 필요한 락을 획득하는 단계, 이미 획득한 락은 해제하지 않는다.
• 수축단계: 트랜잭션이 락을 해제하는 단계로, 이 단계에서는 새로운 락을 획득하지 않는다.

 

작업 설명

A 계좌 : 1000, B 계좌 : 1000원
T1 : A계좌에서 100원을 인출하여 B 계좌에 입금한다.
T2 : A와 B 계좌 모두 10%씩 잔고를 증가시킨다.

결과

• T1 -> T2: A:900, B:1100 -> A: 990, B:1210
• T2 -> T1: A:1100, B:1100 -> A: 1000, B:1200
  일관성 규칙 : A+B = 2200

 

데이터 일관성이 깨지는 예시

• T1은 실행중에 데이터 A에 대한 락을 해제하였고, 트랜잭션 B는 트랜잭션 A가 커밋 전에 데이터 A에 락을 걸어 중간 결과를 읽어와 데이터를 변경했다.
• 트랜잭션 종료 후 A=990, B:1200으로 A+B=2190, 일관성 규칙이 깨진다.

트랜잭션이 쓰기 작업 중인 중간 데이터를 다른 트랜잭션이 가져올 수 없도록 막기

 

2단계 락킹 기법을 사용해 데이터 일관성 유지

트랜잭션이 작업을 완수하기 전까지 락을 해제하지 않도록 한다.
확장 단계와 수축 단계를 지켜 진행한다.

 

확장 단계에서는 락을 걸기만 하고, 수축 단계에서는 락을 해지하기만 한다.

LX(A)
LX(B)
..
..
UN(A)
UN(B)

 

데드락(deadlock)

두 개 이상의 트랜잭션이 각각 자신의 데이터에 대해 락을 획득하고 상대방 데이터에 대해 락을 요청하면 무한 대기 상태에 빠질 수 있다.

이러한 현상을 데드락 혹은 교착상태라고 한다.

 

작업 설명

T1 : 1번 도서와 2번 도서의 가격을 100원씩 올린다.
T2 : 2번 도서와 1번 도서의 가격을 10%씩 인상한다.

 

데드락 발생

• T1은 1번 도서에 락을 건다.
• T2는 2번 도서에 락을 건다.
• T1이 2번 도서의 락을 얻기 위해 대기한다.
• T2는 1번 도서의 락을 얻기 위해 대기한다.
  => T1, T2는 상대방이 락을 해제하기를 기다리는 상태가 된다.

실습시에는 T2의 실행이 자동으로 중지된다.
sql server에서 데드락이 발생하면 마지막에 실행된 트랜잭션을 강제로 중지시키기 때문이다.

 

데드락 해결

일반적으로 데드락이 발생하면 DBMS는 T1 혹은 T2의 작업 중 하나를 강제로 중지시킨다. 그 결과 나머지 트랜잭션은 정상적으로 실행된다.

이때 중지시키는 트랜잭션에서 변경한 데이터는 원래 데이터로 되돌려 놓는다.

 

트랜잭션 고립 수준

• (쓰기, 읽기) 문제를 해결한다.

(쓰기, 읽기)시 락을 이용하면 문제를 해결할 수 있지만 락을 얻기까지 대기해야하므로
해당 상황에 대해 너무 과도한 해결책이다.

 

트랜잭션 동시 실행시 발생하는 문제

(쓰기, 읽기)시 갱신 손실같은 심각한 문제는 발생하지 않지만, dirty read 문제, non-repeatable 문제, phantom read 문제가 발생할 수 있다.

읽기만 하는 트랜잭션이 쓰기 트랜잭션에서 작업한 중간 데이터를 읽기 때문에 발생한다.

 

dirty read(오손 읽기) 문제

읽기 작업을 하는 트랜잭션A이 쓰기 작업을 하는 트랜잭션B가 작업 중인 중간 데이터를 읽기 때문에 생기는 문제이다.
작업 중인 트랜잭션B가 작업을 rollback할 경우 트랜잭션 A는 무효가 된 데이터를 읽게 되고 잘못된 결과를 도출한다.

 

dirty read 예시

T1 : 읽기 트랜잭션
T2 : 쓰기 트랜잭션
T2가 변경한 데이터를 가지고 T1은 읽기 작업을 수행한다.

dirty read : T2가 변경한 데이터를 T1이 가져와 읽었는데, T2가 작업 중 rollback을 하게 되어 T1은 올바르지 않은 데이터를 읽어오게 된다.

• 쓰기 작업한 중간 데이터를 읽었는데 쓰기가 rollback된 경우

쓰기 작업이 rollback될 경우 읽기 작업에서 읽어온 중간 데이터가 오류를 발생시킨다.

 

non-repeatable read (반복 불가능 읽기)

• 트랜잭션 1이 데이터를 읽고 트랜잭션 2가 데이터를 쓰고(update) 트랜잭션 1이 다시 한번 데이터를 읽을 때 생기는 문제
• 트랜잭션 1이 읽기 작업을 다시 한번 반복할 경우 이전의 결과와 다른 결과가 나오는 현상

• 다른 트랜잭션에 의해 해당 레코드가 갱신되거나 삭제되어 발생한다.

작업 상황

트랜잭션 T1과 T2가 동시에 실행된다.
T1은 읽기 작업, T2는 쓰기 작업을 한다.
T1은 데이터를 읽고 작업한 후, T2가 변경된 데이터를 다시 한번 읽어와 작업을 한다.

 

반복 불가능 읽기 예시

T1이 데이터를 읽고 작업하던 중 T2가 데이터를 변경하였다.
T1이 다시한번 데이터를 읽으니 이전 sql결과와 다른 결과가 도출된다.

홍길동의 나이가 30살이었는데 21살이 되었다. 혼란 유발..

 

T2가 commit하였으므로 틀린 데이터는 아니지만 T1 입장에서는 같은 sql문이 다른 결과를 도출하는 문제가 있다.

 

phantom-read(유령데이터 읽기)

• 동일한 트랜잭션에서 특정 범위의 레코드를 두 번 이상 읽었을 때, 이전에는 없던 새로운 레코드가 나타나는 현상
• 트랜잭션 1이 데이터를 읽고 트랜잭션2가 데이터를 쓰고, 트랜잭션 1이 다시 한번 데이터를 읽을 때 생기는 문제이다.
• 트랜잭션 1이 읽기 작업을 다시 한번 반복할 경우 이전에 없던 데이터(유령 데이터)가 나타나는 현상이다.
• non-repeatable read와 다르게 다른 트랜잭션에 의해 새 레코드가 삽입되어 발생한다.

 

작업 상황

트랜잭션 T1과 T2가 동시에 실행된다.
T1은 읽기 작업, T2는 쓰기 작업을 한다.
T1은 데이터를 읽고 작업한 후, T2가 변경된 데이터를 다시 한번 읽어와 작업을 한다.

 

phantom-read 예시

T1이 데이터를 읽고 작업하던 중 T2가 데이터를 삽입하였다.
T1이 다시한번 데이터를 읽으니 이전 sql결과와 다른 결과가 도출된다.

T2가 commit하였으므로 틀린 데이터는 아니지만 T1 입장에서는 같은 sql문이 다른 결과를 도출하는 문제가 있다.

 

non-repeatable read vs phantom read

공통점 : 같은 sql문이 다른 결과를 도출한다.
차이점

• non-repeatable read는 다른 트랜잭션에 의해 데이터가 수정되거나 삭제되어 발생한다.
• phantom read는 다른 트랜잭션에 의해 데이터가 삽입되어 발생한다.

dirty read, non-repeatable read, phantom read 문제를 해결하기 위해 락을 도입할 수 있지만,
dbms는 락보다 좀 더 완화된 방법인 트랜잭션 고립 수준 명령어를 사용하여 동시성을 높이고 문제를 해결한다.

 

트랜잭션 고립 수준 명령어

• 사용자가 어느 정도 선택하여 트랜잭션을 제어할 수 있다.
• 읽기/쓰기에 대한 트랜잭션 간의 고립 수준을 결정한다.

참고 : 공유락과 배타락

• 공유락은 특정 데이터에 대해 읽기 전용 권한을 부여하며, 어떤 트랜잭션에서 공유락을 건 경우 다른 트랜잭션에서도 공유락은 가능하지만 배타적 잠금은 불가능하다.
• 배타락은 특정 데이터에 대해 읽기와 쓰기 권한을 부여하며, 어떤 트랜잭션에서 배타락을 건 경우 다른 트랜잭션에서는 그 데이터에 접근할 수 없다.

 

READ UNCOMMITED (레벨 0) : 커밋되지 않아도 읽기

• 고립 수준이 가장 낮은 명령어
• 자신의 데이터에 아무런 공유락을 걸지 않는다.

배타락은 갱신 손실 문제로 인해 걸어야한다.

• 다른 트랜잭션에 공유락과 배타락이 걸린 데이터를 대기하지 않고 읽는다.
• commit되지 않은 데이터도 읽을 수 있어 dirty page의 데이터를 읽을 수 있다.
• select 질의의 대상이 되는 테이블에 대해 락을 설정하지 않은 것과 같다.

 

READ COMMITED (레벨 1) : 커밋된 것만 읽기

• dirty page 참조를 피하기 위해 자신의 데이터를 읽는 동안 공유락을 걸지만 트랜잭션이 끝나기 전이라도 해지가능하다.
  (읽기 연산 후 바로 공유락을 해제한다)
• 데이터를 읽은 후 공유락을 즉시 해제하여 다른 트랜잭션이 해당 데이터에 접근할 수 있다.

공유락을 걸면 업데이트를 수행하려는 트랜잭션이 배타락을 걸지 못해 dirty page 참조를 피할 수 있다.
다른 트랜잭션이 업데이트를 수행하는 트랜잭션의 중간 데이터를 읽으려면 공유락을 걸기 위해 배타락이 끝날때까지 기다려야 하므로 dirty page 참조를 피할 수 있다.

• 다른 트랜잭션의 데이터는 락 호환성 규칙에 따라 진행한다.
• SQL 서버의 기본 설정이다.

한 트랜잭션 내에서 데이터가 변경될 수 있다.
읽기 트랜잭션 중간에 쓰기 트랜잭션이 데이터를 변경하여 커밋한다면 같은 쿼리에 대해 다른 결과를 얻는 문제가 발생한다.

 

REPEATABLE READ (레벨 2) : 같은 데이터를 두 번 조회해도 동일한 데이터 보장

• 자신의 데이터에 설정된 공유락과 배타락을 트랜잭션이 종료할 때까지 유지하여 다른 트랜잭션이 자신의 데이터를 갱신할 수 없도록 한다.

한 트랜잭션에서 같은 데이터를 두 번 읽을 때 첫번째 조회 결과와 두번째 조회 결과가 동일하다.

• 다른 트랜잭션의 데이터는 락 호환성 규칙에 따라 진행한다.
• 다른 고립화 수준에 비해 데이터의 동시성이 낮아 특별 상황이 아니라면 사용하지 않는 것이 좋다.

repeatable read는 특정 레코드에 대한 조회의 반복성은 유지하지만, 조회 결과 범위 자체의 변화까지는 제어하지 못한다.
(범위 자체의 락을 설정할 수 없다.)
phantom read는 새로운 데이터가 삽입되어 발생하므로 쿼리 결과 범위 내에 새로운 레코드가 삽입되는 것을 repeatable read는 방지하지 못한다.

 

SERIALIZABLE (레벨 3) : 트랜잭션이 순차적으로 실행되는 것처럼 보장

• 고립 수준이 가장 높은 명령어
• 실행 중인 트랜잭션은 다른 트랜잭션으로부터 완벽히 분리된다.

하나의 트랜잭션만이 전체 데이터베이스 또는 특정 범위의 데이터에 접근할 수 있는 것처럼 만들어, 어떠한 동시성 문제도 발생하지 않도록 한다.

• 데이터 집합에 범위를 지어 잠금을 설정할 수 있으므로(범위락) 다른 사용자가 데이터를 변경하려고 할 때 트랜잭션을 완전히 분리할 수 있다.

범위 락을 사용하여 쿼리 범위 내의 모든 데이터 변경(삽입, 수정, 삭제)를 방지한다.
즉, phantom read를 방지할 수 있다.

• 4가지 고립화 수준 중 제한이 가장 심하고 데이터의 동시성도 낮다.
• SELECT 질의의 대상이 되는 테이블에 미리 배타락을 설정한 것과 같은 효과를 낸다.

 

Reference

책 : SQL Server로 배우는 데이터베이스 개론과 실습

https://m.yes24.com/Goods/Detail/97538787

SQL Server로 배우는 데이터베이스 개론과 실습 - 예스24

오개념이 있다면 댓글 남겨주세요 ~~