[Database] 10. 트랜잭션, 장애와 회복, 병행 제어

CS(Computer Science)/Database

[Database] 10. 트랜잭션, 장애와 회복, 병행 제어

seunghwaan 2024. 12. 9. 17:30

이번 포스트에서는 데이터베이스의 트랜잭션, 장애와 회복, 병행 제어에 대해 알아보겠습니다.

트랜잭션(Transaction)

[ 트랜잭션의 개념 ]

트랜잭션(Transaction)은 하나의 작업을 수행하기 위해 필요한 데이터베이스 연산들을 모아놓은 것으로, 논리적인 작업의 단위.
트랜잭션은 데이터베이스에 장애가 발생했을 때 데이터를 복구하는 작업의 단위도 된다.
데이터베이스의 연산은 SQL 문으로 표현되므로 트랜잭션을 작업 수행에 필요한 SQL 문들의 모임으로 이해해도 좋다.
트랜잭션을 통해 데이터베이스가 항상 정확하고 일관된 상태를 유지할 수 있도록 다양한 기능을 제공할 수 있다.

[ 트랜잭션의 특성 ]

트랜잭션이 성공적으로 처리되어 데이터베이스의 무결성과 일관성이 보장되려면 트랜잭션의 네 가지 특성인 원자성, 일관성, 격리성, 지속성을 꼭 만족해야 한다.
네 가지 특성을 각 특성에 해당하는 영어 단어의 첫 자를 따서 ACID 특성이라고 한다.

원자성

원자성(atomicity)은 트랜잭션을 구성하는 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 한다는 all-or-nothing 방식을 의미한다.
만약, 트랜잭션을 수행하다가 장애가 발생하여 작업을 완료하지 못했다면 지금까지 실행한 연산 처리를 모두 취소하고 데이터베이스를 트랜잭션 작업 전의 상태로 되돌려 트랜잭션의 원자성을 보장해야 한다.
트랜잭션의 원자성을 보장하면 트랜잭션을 구성하는 연산 중 일부만 처리한 결과를 데이터베이스에 반영하는 일이 없게 된다.
트랜잭션의 원자성을 보장하려면 장애가 발생했을 때 데이터베이스의 원래 상태로 복구하는 회복 가능이 필요하다.

일관성

일관성(consistency)은 트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관된 상태를 유지해야 함을 의미한다.
즉, 트랜잭션이 수행되기 전에 데이터베이스가 일관된 상태였다면 트랜잭션의 수행이 완료된 후 결과를 반영한 데이터베이스도 또 다른 일관된 상태가 되어야 한다는 의미다.
트랜잭션이 수행되는 과정에서는 데이터베이스가 일시적으로 일관된 상태가 아닐 수 있지만, 트랜잭션의 수행이 성공적으로 완료된 후에는 데이터베이스가 일관된 상태를 유지해야 한다.

격리성

격리성(isolation)은 현재 수행 중인 트랜잭션이 완료될 때까지 트랜잭션이 생성한 중간 연산 결과에 다른 트랜잭션들이 접근할 수 없음을 의미한다.
일반적으로 데이터베이스 시스템에서는 여러 트랜잭션이 동시에 수행되지만 각 트랜잭션이 독립적으로 수행될 수 있도록 다른 트랜잭션의 중간 연산 결과에 서로 접근하지 못하게 된다.

지속성

지속성(durability)은 영속성이라고도 하는데 트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 어떠한 경우에도 손실되지 않고 영구적이어야 함을 의미한다.
즉, 시스템에 장애가 발생하더라도 트랜잭션 작업 결과는 없어지지 않고 데이터베이스에 그대로 남아 있어야 한다는 의미다.
트랜잭션의 지속성을 보장하려면 시스템에 장애가 발생했을 때 데이터베이스를 원래 상태로 복구하는 회복 기능이 필요하다.

[ 트랜잭션의 특성을 지원하는 DBMS의 기능 ]

데이터베이스 관리 시스템(DBMS)은 트랜잭션의 네 가지 특성을 보장하기 위한 지원 기능을 제공한다. (회복 기능, 병행 제어 기능)

[ 트랜잭션의 연산 ]

트랜잭션의 수행과 관련하여 주로 사용되는 연산에는 작업 완료를 의미하는 commit 연산과 작업 취소를 의미하는 rollback 연산이 있다.

[ commit 연산 ]

commit 연산은 트랜잭션의 수행이 성공적으로 완료되었음을 선언하는 연산이다. (작업 완료)
-> commit 연산이 실행된 후에야 트랜잭션의 수행 결과가 데이터베이스에 반영되어 데이터베이스가 일관된 상태를 지속적으로 유지하게 된다.
아래 그림과 같이 트랜잭션을 구성하는 모든 연산이 정상적으로 처리되면 commit 연산의 실행을 통해 트랜잭션의 수행이 성공적으로 완료되었음을 선언하고 트랜잭션이 수행한 최종 결과를 데이터베이스에 반영한다.

[ rollback 연산 ]

rollback 연산은 트랜잭션의 수행이 실패했음을 선언하는 연산이다.
-> rollback 연산이 실행되면 트랜잭션이 지금까지 실행한 연산의 결과가 취소되고 트랜잭션이 수행되기 전의 상태로 돌아간다.
아래 그림과 같이 트랜잭션이 수행되는 도중에 장애가 발생하여 일부 연산이 처리되지 못한 상황에서는 rollback 연산을 실행하여 트랜잭션의 수행이 실패했음을 선언하고, 데이터베이스를 트랜잭션 수행 전의 일관된 상태로 되돌려 모순이 발생하지 않게 한다.

[ 트랜잭션의 상태 ]

트랜잭션은 다섯 가지 상태 중 하나에 속하게 된다.
활동 상태, 부분 완료 상태, 완료 상태, 실패 상태, 철회 상태가 있다.
완료 상태는 트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태다.
실패 상태는 장애가 발생하여 트랜잭션의 수행이 중단된 상태다.
철회 상태는 트랜잭션의 수행 실패로 rollback 연산을 실행한 상태다.

활동 상태

활동 상태는 트랜잭션이 수행을 시작하여 현재 수행 중인 상태다.
활동 상태인 트랜잭션은 상황에 따라 부분 완료 상태나 실패 상태가 된다.

부분 완료(partially committed) 상태

부분 완료 상태는 트랜잭션의 마지막 연산이 실행을 끝낸 직후의 상태다. (트랜잭션의 모든 연산을 처리한 상태)
부분 완료 상태인 트랜잭션은 모든 연산의 처리가 끝났지만 트랜잭션이 수행된 최종 결과를 데이터베이스에 아직 반영하지 않은 상태다.
-> 따라서 아직은 트랜잭션의 수행이 성공적으로 완료됐다고 볼 수 없다.
부분 완료 상태의 트랜잭션은 상황에 따라 완료 상태나 실패 상태가 될 수 있다.

완료(committed) 상태

완료 상태는 트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 상태다.
트랜잭션이 완료 상태가 되면 트랜잭션이 수행한 최종 결과를 데이터베이스에 반영하고, 데이터베이스가 새로운 일관된 상태가 되면서 트랜잭션이 종료된다.

실패 상태

실패 상태는 하드웨어나 소프트웨어의 문제, 트랜잭션 내부의 오류 등 여러 이유로 장애가 발생하여 트랜잭션의 수행이 중단된 상태다.
트랜잭션을 더는 정상적으로 수행할 수 없을 때 실패 상태가 된다.

철회 상태

철회 상태는 트랜잭션의 수행 실패로 rollback 연산을 실행한 상태다.
트랜잭션이 철회 상태가 되면 지금까지 실행한 트랜잭션의 연산을 모두 취소하고 트랜잭션이 수행되기 전의 데이터베이스 상태로 되돌리면서 트랜잭션이 종료된다.
-> 트랜잭션의 내부 문제가 아닌, 하드웨어의 이상이나 소프트웨어의 오류로 트랜잭션의 수행이 중단되고 철회 상태가 된 경우에는 철회된 트랜잭션을 다시 시작한다.
-> 트랜잭션이 처리하려는 데이터가 데이터베이스에 존재하지 않거나 트랜잭션의 논리적인 오류가 원인인 경우에는 철회된 트랜잭션을 폐기한다.

장애

장애(failure)는 시스템이 제대로 동작하지 않는 상태를 말한다.
장애가 발생하는 원인은 사용자의 실수, 정전 등으로 인한 하드웨어 고장, 소프트웨어의 논리적인 오류 등 매우 다양한다.

[ 데이터베이스의 저장 연산 ]

데이터베이스는 기본적으로 저장 장치에 저장된다.
저장 장치는 장애가 발생했을 때 대응하는 방법에 따라 아래의 세 종류로 분류할 수 있다.
휘발성(volatility) 저장 장치(소멸성) -> 장애가 발생하면 저장된 데이터가 손실됨. ex) 메인 메모리 등
비휘발성(nonvolatility) 저장 장치(비소멸성) -> 장애가 발생해도 저장된 데이터가 손실되지 않음. 단, 디스크 헤더 손상ㄱ앝은 저앚 장치 자체에 이상이 발생하면 데이터가 손실될 수 있음. ex) 디스크, 자기 테이프, CD/DVD 등
안정(stable) 저장 장치 -> 비휘발성 저장 장치를 이용해 데이터 복사본 여러 개를 만드는 방법으로, 어떤 장애가 발생해도 데이터가 손실되지 않고 데이터를 영구적으로 저장할 수 있음.

일반적으로 데이터베이스는 비휘발성 저장 장치인 디스크에 상주한다.
하지만 트랜잭션이 데이터베이스의 데이터를 처리하려면, 위 그림과 같이 데이터를 디스크에서 메인 메모리로 가져와 이를 처리한 후 그 결과를 다시 디스크로 보내는 작업이 필요하다.

디스크와 메인 메모리 간의 데이터 이동은 대게 블록(block) 단위로 수행된다. 디스크에 있는 블록을 디스크 블록이라 하고 메인 메모리에 있는 블록은 버퍼 블록이라 한다.

디스크와 메인 메모리 간의 데이터 이동은 아래의 두 연산으로 수행된다.

input(X) -> 디스크 블록에 저장되어 있는 데이터 X를 메인 메모리 버퍼 블록으로 이동시키는 연산
output(X) -> 메인 메모리 버퍼 블록에 있는 데이터 X를 디스크 블록으로 이동시키는 연산

사용자의 요구에 따라 응용 프로그램에서 트랜잭션의 수행을 지시하면 메인 메모리 버퍼 블록에 있는 데이터를 프로그램의 변수로 가져오고, 데이터 처리 결과를 저장한 변수 값을 메인 메모리 버퍼 블록으로 옮기는 작업이 추가로 필요하다.

메인 메모리의 버퍼 블록과 프로그램 변수 간의 데이터 이동은 아래의 두 연산으로 수행된다.

read(X) -> 메인 메모리 버퍼 블록에 저장되어 있는 데이터 X를 프로그램의 변수로 읽어오는 연산
write(X) -> 프로그램의 변수 값을 메인 메모리 버퍼 블록에 있는 데이터 X에 기록하는 연산

응용 프로그램이 실행한 트랜잭션을 수행하는 데 필요한 데이터 이동 연산들의 관계는 아래 그림과 같다.

응용 프로그램에 의해 수행된 트랜잭션이 데이터베이스에 접근하여 처리할 데이터를 가져올때 read(X) 연산이 실행된다.
그런데 read(X) 연산이 정상적으로 실행되려면 먼저 데이터베이스가 상주하고 있는 디스크에서 메인 메모리 버퍼 블록으로 데이터를 가져와야 한다.
-> 그래서 내부적으로 input(X) 연산의 실행이 요구된다.
read(X) 연산이 실행되어 디스크에 존재하는 데이터베이스의 데이터가 프로그램 변수에 저장되면 해당 데이터에 대한 모든 연산은 프로그램 변수를 대상으로 처리된다.
트랜잭션이 성공적으로 완료되려면 트랜잭션의 모든 연산을 처리한 후 결과 값을 디스크의 데이터에비스에 반영해야 하는데, 이를 위해 write(X) 연산이 실행된 후 output(X) 연산이 실행된다.

트랜잭션을 데이터 이동 연산을 포함한 프로그램으로 표현할 수 있다.
위 그림은 성호가 은경에게 5,000원을 계좌 이체하는 트랜잭션을 데이터 이동 연산과 함께 프로그램으로 표현한 예시다. 성호 계좌의 잔액을 X로, 은경 계좌의 잔액을 Y로 지정하였다.

회복

회복(recovery)은 장애가 발생했을 때 데이터베이스를 장애가 발생하기 전의 일관된 상태로 복구시키는 것이다.
데이터베이스 관리 시스템(DBMS)에 있는 회복 관리자(recovery manager)가 담당한다.
회복 관리자는 장애 발생을 탐지하고, 장애가 탐지되면 데이터베이스 복구 기능을 제공한다.
대개 장애가 일어난 데이터베이스를 복구하는 동안에는 데이터베이스에 접근하여 업무를 처리할 수 없으므로, 데이터베이스를 회복시키는 작업은 빠른 시간 내에 이루어져야 한다.

[ 회복을 위한 연산 ]

데이터베이스 회복의 핵심 원리는 데이터 중복이다.
-> 데이터를 별도의 장소에 미리 복사해두고, 장애로 문제가 발생했을 때 복사본을 이용해 원래의 상태로 복원한다.
덤프 또는 로그 방법을 사용해 데이터를 복사해두었다가 회복시킬 때 복사본을 사용한다.

데이터베이스 회복을 위해 복사본을 만드는 방법

덤프(dump) -> 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법.
로그(log) -> 데이터베이스에서 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경한 이후의 값을 별도의 파일에 기록하는 방법

덤프와 로그(회복 연산)

데이터베이스 전체를 복사하는 덤프 방법은 하루에 한 번 또는 한 달에 한 번과 같이 미리 정해진 주기에 따라 수행한다. 그리고 디스크와 같은 비휘발성 저장 장치에 데이터베이스 복사본을 저장한다.
장애가 발생했을 때, 덤프나 로그 방법으로 중복 저장한 데이터를 이용해 데이터베이스를 복구하는 가장 기본적인 방법은 redo나 undo 연산을 실행하는 것이다.
redo 연산(재실행) -> 가장 최근에 저장한 데이터베이스 복사본을 가져온 후, 로그에 기록된 변경 연산 후의 값을 이용하여 변경 연산을 재실행하는 방법으로 데이터베이스를 복구. (전반적으로 손상된 경우에 주로 사용)
undo 연산(취소) -> 로그에 기록된 변경 연산 이전의 값을 이용하여 변경 연산(지금까지 실행된 모든 변경 연산)을 취소하는 방법으로 데이터베이스를 복구. (변경 중이었거나 이미 변경된 내용만 신뢰성을 잃은 경우에 주로 사용)

[ 로그 ]

로그는 데이터베이스에 대한 변경 연산과 관련하여, 데이터를 변경하기 이전의 값과 변경한 이후의 값을 기록한 것이다.
로그를 저장한 파일을 로그 파일이라고 하는데, 로그 파일은 레코드 단위로 기록된다.
데이터베이스에 대한 변경 연산은 트랜잭션 단위로 실행되므로 로그 레코드도 트랜잭션의 수행과 함께 기록된다.
로그는 데이터베이스 회복 작업을 수행하기 위해 필요한 중요한 정보를 가지고 있으므로 데이터 손실이 발생하지 않는 저장 장치에 저장해둔다.
일반적으로 로그 파일을 구성하는 레코드는 아래와 같이 네 종류로 분류한다.

아래 그림은 계좌 잔액이 10,000원인 성호가 계좌 잔액이 0원인 은경에게 5,000원을 이체할 때, 계좌이체 트랜잭션의 수행 시작부터 완료까지를 기록한 로그의 예시다.

데이터베이스 회복의 기본 연산으로 소개한 redo와 undo는 데이터베이스 관리 시스템이 실제로 적용하는 위의 회복 기법들에서 주요 연산으로 사용된다.

[ 로그 회복 기법 ]

로그를 이용한 회복 기법은 데이터를 변경한 연산 결과를 데이터베이스에 반영하는 시점에 따라 즉시 갱신 회복 기법과 지연 갱신 회복 기법으로 나뉜다.

즉시 갱신 회복 기법

즉시 갱신(immediate update) 회복 기법은 트랜잭션 수행 중에 데이터를 변경한 연산의 결과를 데이터베이스에 즉시 반영한다. 그리고 장애 발생에 대비하기 위해 데이터 변경에 대한 내용을 로그 파일에도 기록한다.
데이터베이스 회복 시 로그를 정상적으로 사용하려면, 트랜잭션에서 데이터 변경 연산이 실행되었을 때 로그 파일에 로그 레코드를 먼저 기록한 후 데이터베이스에 변경 연산을 반영해야 한다.

아래 그림은 계좌 잔액이 10,000원인 성호가 계좌 잔액이 0원인 은경에게 5,000원을 이체하는 계좌이체 트랜잭션이 순차적으로 수행되는 과정을 나타낸다. 즉, 트랜잭션이 수행되면서 로그 파일에 기록되는 로그 레코드와 데이터베이스에 트랜잭션의 수행 결과를 반영한 모습을 순서대로 보여준다.

즉시 갱신 회복 기법은 장애가 발생하면 로그 파일에 기록된 내용을 참조하여, 장애 발생 시점에 따라 redo나 undo 연산을 실행하여 데이터베이스를 복구한다.

트랜잭션에 redo 연산을 실행할 것인지 undo 연산을 실행할 것인지는 위 그림의 기준에 따른다.

A 계좌에서 B 계좌로 1,000원을 이체하는 계좌이체 트랜잭션 T1과 C 계좌에서 D 계좌로 2,000원을 이체하는 계좌이체 트랜잭션 T2가 순차적으로 수행되는 두 트랜잭션이 실행하는 연산의 내용과 트랜잭션 수행 순서는 아래 그림과 같다.

순차적으로 수행되는 두 트랜잭션의 로그 파일 내용과 데이터베이스 반영 결과

위 그림에서 각 트랜잭션이 수행되고 있는 시점에 장애가 발생했을 때 즉시 갱신 회복 기법을 적용하면 데이터베이스가 어떻게 복구되는지 살펴보면 아래와 같다.

1시점 -> T1 트랜잭션이 수행되기 전이므로 로그파일에 <T1, start> 로그 레코드는 있으나 <T1, commit> 로그 레코드가 존재하지 않으므로 T1 트랜잭션에 undo(T1) 연산을 실행해야 한다.
2시점 -> T1 트랜잭션은 수행이 완료되었으므로 <T1, start>, <T1, commit> 로그 레코드가 모두 존재하고, T2 트랜잭션은 <T2, start> 로그 레코드만 존재하고 <T2, commit> 로그 레코드는 없으므로, 회복을 위해 T2 트랜잭션에 undo(T2) 연산을 먼저 실행한 후 T1 트랜잭션에 redo(T1) 연산을 실행한다.

지연 갱신 회복 기법

지연 갱신(deferred update) 회복 기법은 트랜잭션이 수행되는 동안에는 데이터 변경 연산의 결과를 데이터베이스에 즉시 반영하지 않고 로그 파일에만 기록해두었다가, 트랜잭션이 부분 완료된 후에 로그에 기록된 내용을 이용해 데이터베이스에 한 번만 반영한다.
트랜잭션이 수행되는 동안 장애가 발생할 경우 로그에 기록된 내용을 버리기만 하면 데이터베이스가 원래 상태를 그대로 유지하게 된다.
지연 갱신 회복 기법에서는 undo 연산은 필요 없고 redo 연산만 필요하므로 로그 레코드에 변경 이전 값을 기록할 필요가 없다.
그러므로 변경 연산 실행에 대한 로그 레코드는 <t1, x_new_value=""> 형식으로 기록된다.
장애가 발생했을 때 지연 갱신 회복 기법이 취하는 조치는 아래 그림의 기준에 따라 결정한다.

아래 그림은 2개의 계좌이체 트랜잭션이 순차적으로 수행되면서 로그 파일에 기록된 내용과 데이터베이스에 데이터 변경 연산의 결과가 반영된 모습이다. 두 계좌이체 트랜잭션에 장애가 발생했을 때 지연 갱신 회복 기법을 적용하는 방법을 생각해보자.

위 그림에서 각 트랜잭션이 수행되고 있는 시점에 장애가 발생했을 때 지연 갱신 회복 기법을 적용하면 데이터베이스가 어떻게 복구되는지 살펴보면 아래와 같다.

1시점 -> T1 트랜잭션이 수행되기 전이므로 로그파일에 <T1, start> 로그 레코드는 있으나 <T1, commit> 로그 레코드가 존재하지 않으므로, 트랜잭션이 실행한 데이터 변경 연산의 결과를 아직 데이터베이스에 반영하기 전이므로 로그에 기록된 내용만 버리면 다른 회복 조치를 하지 않아도 된다.
2시점 -> T1 트랜잭션은 수행이 완료되었으므로 <T1, start>, <T1, commit> 로그 레코드가 모두 존재하고, T2 트랜잭션은 <T2, start> 로그 레코드만 존재하고 <T2, commit> 로그 레코드는 없으므로, T2 트랜잭션에 대한 로그 레코드를 무시하고 T2 트랜잭션에는 별다른 회복 조치를 하지 않아도 되고, 수행이 완료된 T1 트랜잭션에는 redo(T1) 연산을 실행하면 된다.

검사 시점 회복 기법

검사 시점 회복 기법은 로그 회복 기법과 같은 방법으로 로그 기록을 이용하되, 일정 시간 간격으로 검사 시점(checkpoint)을 만들어두고, 장애가 발생하면 가장 최근 검사 시점 이전의 트랜잭션에는 회복 작업을 수행하지 않고, 이후의 트랜잭션에만 회복 작업을 수행하는 방법이다.
로그 전체를 대상으로 회복 기법을 적용하면 데이터베이스 회복에 너무 많은 시간이 걸리고 redo 연산을 수행할 필요가 없는 트랜잭션에도 redo 연산을 실행하는 일이 발생하는 비효율성을 해결하기 위해 제안된 방법이다.

미디어 회복 기법

미디어 회복 기법은 전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사해두는 덤프를 이용하는 방법이다. 디스크 장애가 발생하면 가장 최근에 복사해둔 덤프를 이용해 장애 발생 이전의 일관된 데이터베이스 상태로 복구하고, 필요에 따라 로그의 내용을 토대로 redo 연산을 실행한다.
디스크는 휘발성 저장 장치인 메인 메모리보다 장애가 드물게 발생하지만 디스크 헤더의 고장 등으로 장애가 발생할 수 있으므로, 디스크에 발생할 수 있는 장애에 대비한 회복 기법은 미디어 회복 기법이다.
전체 데이터베이스를 다른 저장 장치에 복사하는 것은 비용이 많이 들고 복사하는 동안에 트랜잭션 수행을 중단해야 하므로 미디어 회복 기법은 CPU가 낭비된다는 단점이 있다.

병행 제어

[ 병행 수행과 병행 제어 ]

데이터베이스 관리 시스템은 여러 사용자가 데이터베이스를 동시에 공유할 수 있도록 여러 개의 트랜잭션이 동시에 수행되는 병행 수행(concurrency)을 지원한다.
병행 수행은 실제로 여러 트랜잭션이 차례로 번갈아 수행되는 인터리빙(interleaving) 방식으로 진행된다.
but, 병행 수행은 병행 수행 되는 트랜잭션들이 서로 다른 데이터를 사용하는 연산은 괜찮지만, 동시에 같은 데이터에 접근하여 변경 연산을 실행하려고 하면 예상치 못한 결과가 나타날 수 있다. (갱신 분실, 모순성, 연쇄 복귀)
-> 병행 제어(concurrency control) 또는 동시성 제어는 여러 개의 트랜잭션이 병행 수행되면서 같은 데이터에 접근하여 연산을 실행하더라도, 문제가 발생하지 않고 정확한 수행 결과를 얻을 수 있도록 트랜잭션의 수행을 제어할 수 있다.

[ 병행 수행의 문제 ]

병행 수행을 특별한 제어 없이 진행하면 여러 문제가 발생할 수 있다. 대표적인 문제로 갱신 분실, 모순성, 연쇄 복귀가 있다.

갱신 분실

갱신 분실(lost update)은 하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어써 변경 연산이 무효화되는 것이다.

모순성

모순성(inconsistency)은 하나의 트랜잭션이 여러 개의 데이터 변경 연산을 실행할 때 일관성 없는 상태의 데이터베이스에서 데이터를 가져와 연산을 실행함으로써 모순된 결과가 발생하는 것이다.
예를 들어 어떤 연산은 현재의 트랜잭션이 실행되기 전 상태의 데이터베이스에서 데이터를 가져와 실행하고, 또 다른 연산은 다른 트랜잭션이 변경한 데이터베이스에서 데이터를 가져와 실행하면 모순성의 문제가 발생할 수 있다.

연쇄 복귀

연쇄 복귀(cascading rollback)는 트랜잭션이 완료되기 전에 장애가 발생하여 rollback 연산을 수행하면, 이 트랜잭션이 장애 발생 전에 변경한 데이터를 가져가 변경 연산을 실행한 또 다른 트랜잭션에도 rollback 연산을 연쇄적으로 실행해야 한다는 것이다.
그런데 장애가 발생한 트랜잭션이 rollback 연산을 실행하기 전에, 변경한 데이터를 가져가 사용하는 다른 트랜잭션이 수행을 완료해버리면 rollback 연산을 실행할 수 없어 큰 문제가 발생하게 된다.

[ 트랜잭션 스케줄 ]

트랜잭션 스케줄은 트랜잭션에 포함되어 있는 연산들을 수행하는 순서다.
일반적으로 하나의 트랜잭션에는 많은 연산들이 포함되어 있어 여러 트랜잭션을 병행 수행하는 경우 트랜잭션들의 각 연산을 실행시키는 순서인 트랜잭션 스케줄도 여러 가지가 있을 수 있다.
트랜잭션 스케줄의 유형은 직렬 스케줄, 비직렬 스케줄, 직렬 가능 스케줄로 나눌 수 있다.

직렬 스케줄

직렬 스케줄(serial schedule)은 인터리빙 방식을 이용하지 않고 트랜잭션별로 연산들을 순차적으로 실행시키는 것이다.
트랜잭션이 직렬 스케줄에 따라 수행되면, 모든 트랜잭션이 완료될 때까지 다른 트랜잭션의 방해를 받지 않고 독립적으로 수행된다.
그래서 직렬 스케줄에 따라 트랜잭션이 수행되고 나면 항상 모순이 없는 정확한 결과를 얻는다.
같은 트랜잭션들을 대상으로 하더라도 트랜잭션의 수행 순서에 따라 다양한 직렬 스케줄이 만들어질 수 있고, 직렬 스케줄마다 데이터베이스에 반영되는 최종 결과가 달라질 수 있다.
하지만 직렬 스케줄의 결과는 모두 정확하기 때문에 어떤 직렬 스케줄을 사용하는가는 중요하지 않다.

비직렬 스케줄

비직렬 스케줄(nonserial schedule)은 인터리빙 방식을 이용하여 트랜잭션을 병행해서 수행시키는 것이다.
비직렬 스케줄은 트랜잭션이 돌아가면서 연산들을 실행하기 때문에 하나의 트랜잭션이 완료되기 전에 다른 트랜잭션의 연산이 실행될 수 있다.
비직렬 스케줄에 따라 여러 트랜잭션을 병행 수행하면 갱신 분실, 모순성, 연쇄 복귀 등의 문제가 발생할 수 있어 최종 수행 결과의 정확성을 보장할 수 없다.

직렬 가능 스케줄

직렬 가능 스케줄(serializable schedule)은 직렬 스케줄에 따라 수행한 것과 같이 정확한 결과를 생성하는 비직렬 스케줄이다.
모든 비직렬 스케줄이 직렬 가능한 것은 아니다.
비직렬 스케줄 중에서 수행 결과가 동일한 직렬 스케줄이 없는 것들은 결과의 정확성을 보장할 수 없으므로 직렬 가능 스케줄이 아니다.
직렬 스케줄은 정확한 결과를 얻을 수 있지만, 인터리빙 방식을 이용하지 않고 트랜잭션들이 독립적으로 수행되므로 병행 수행이 아니다.
반면, 직렬 가능 스케줄은 인터리빙 방식을 이용하여 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있다.
단, 직렬 가능 스케줄을 이용해 트랜잭션을 병행 수행해야 하지만 직렬 가능 스케줄인지 여부를 판단하는 일은 쉽지 않으므로, 대부분의 DBMS에서 직렬 가능 스케줄인지를 검사하기보다는 직렬 가능성을 보장하는 병행 제어 기법을 사용한다.

[ 병행 제어 기법 ]

병행 제어 기법은 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있는 직렬 가능성을 보장받기 위해 사용한다.
병행 제어 기법의 기본 원리는 모든 트랜잭션이 따르면 직렬 가능성이 보장되는 나름의 규악을 정의하고, 트랜잭션들이 이 규약을 따르도록 하는 것이다.
그러므로 트랜잭션 스케줄이 직렬 가능 스케줄인지를 미리 검사할 필요가 없다.
스케줄 내의 모든 트랜잭션이 병행 제어 기법에서 정의한 규약을 따르면 해당 스케줄은 직렬 가능성을 보장할 수 있다.
가장 많이 사용되는 병행 제어 기법은 로킹 기법이 있다.

[ 로킹(locking) 기법 ]

로킹(locking) 기법은 병행 수행되는 트랜잭션들이 동일한 데이터에 동시에 접근하지 못하도록 lock과 unlock이라는 2개의 연산을 이용해 제어한다.
로킹 기법의 기본 원리는 한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 모두 마칠 때까지, 해당 데이터에 다른 트랜잭션이 접근하지 못하도록 상호 배제(mutual exclusion)하여 직렬 가능성을 보장하는 것이다.
로킹 기법에서 lock 연산은 트랜잭션이 사용할 데이터에 대한 독점권을 가지기 위해 사용한다.
반대로 unlock 연산은 트랜잭션이 데이터에 대한 독점권을 반납하기 위해 사용한다.
이 두 연산을 이용하여 다른 트랜잭션의 방해를 받지 않고 데이터에 독점적으로 접근할 수 있게 되는 것이다.

[ 로킹 기법의 규약 ]

로킹 기법을 사용해 트랜잭션이 데이터베이스에 있는 데이터에 접근하는 연산을 실행하려면 먼저 해당 데이터에 lock 연산을 실행하여 독점권을 획득해야 한다.
일반적으로 데이터베이스에 있는 데이터에 접근이 필요한 연산은 데이터를 읽어오는 read와 데이터를 기록하는 write다.
그러므로 트랜잭션이 데이터에 read 또는 write 연산을 실행하기 전에 반드시 lock 연산을 실행해야 한다.
하지만 다른 트랜잭션이 이미 lock 연산을 실행한 데이터에는 다시 lock 연산을 실행해야 한다.
트랜잭션이 lock 연산을 통해 독점권을 획득한 데이터에 대한 모든 연산을 수행하고 나면 unlock 연산을 실행해서 독점권을 반납해야 한다. -> 그래야 다른 트랜잭션이 해당 데이터에 접근할 수 있다.
그리고 데이터에 lock 연산을 실행한 트랜잭션만 해당 데이터에 unlock 연산을 실행할 수 있다.
즉, 데이터에 대한 독점권을 부여받은 트랜잭션만 해당 데이터에 독점권을 반납할 수 있으므로 다른 트랜잭션에 독점권을 뺏기지 않는다.

[ 로킹 단위 ]

이번에는 lock 연산을 실행하는 대상 데이터의 크기인 로킹 단위를 생각해보자. lock 연산은 크게는 전체 데이터베이스부터 작게는 데이터베이스를 구성하는 속성에 이르기까지 다양한 크기의 데이터를 대상으로 실행할 수 있다.
릴레이션이나 튜플도 lock 연산의 대상이 될 수 있다. 만약 전체 데이터베이스에 lock 연산을 실행하면 제어가 간단하다는 장점이 있지만 데이터베이스에 하나의 트랜잭션만 수행되므로 병행 수행이라 할 수 없다.
반면, 가장 작은 단위인 속성에 lock 연산을 하면 독점하는 범위가 좁아 많은 수의 트랜잭션을 병행 수 있다는 장점이 있지만, 제어가 복잡하다는 단점이 있다.
즉, 로킹 단위가 커질수록 병행성은 낮아지지만 제어가 쉽고, 로킹 단위가 작아질수록 제어가 어렵지만 병행성은 높아진다. 그러므로 시스템에 따라 적절한 로킹 단위를 선택하는 것이 중요하다.

[ 공용 lock과 전용 lock ]

기본 로킹 기법을 사용하면 병행 수행을 제어하는 목표는 이룰 수 있지만 너무 엄격한 제약으로 인해 어떤 순간이든 데이터에 대한 독점권을 하나의 트랜잭션만 가지게 된다.
물론 트랜잭션에 데이터를 변경시키는 write 연산을 실행할 때는 다른 트랜잭션이 방해하지 못하도록 독점권을 가져야 한다.
하지만 데이터를 단순히 읽어오기만 하는 read 연산의 경우, 다른 트랜잭션이 같은 데이터에 동시에 read 연산을 실행해도 문제가 생기지는 않는다.
그러므로 트랜잭션들이 하나의 데이터에 read 연산을 동시에 실행할 수 있도록 해서 처리 효율성을 높일 필요가 있다.

같은 데이터에 트랜잭션들이 read 연산을 동시에 실행하는 것을 허용하도록 하는 lock 연산을 두 종류로 구분할 수 있다.

공용(shared) lock -> 트랜잭션이 데이터에 대해 공용 lock 연산을 실행하면, 해당 데이터에 read 연산을 실행할 수 있지만 write 연산은 실행할 수 없다. 그리고 해당 데이터에 다른 트랜잭션도 공용 lock 연산을 동시에 실행할 수 있다. (데이터에 대한 사용권을 여러 트랜잭션이 함께 가질 수 있음)
전용(exclusive) lock -> 트랜잭션이 데이터에 전용 lock 연산을 실행하면 해당 데이터에 read 연산과 write 연산을 모두 실행할 수 있다. 그러나 해당 데이터에 다른 트랜잭션은 공용이든 전용이든 어떤 lock 연산도 실행할 수 없다. (전용 lock 연산을 실행한 트랜잭션만 해당 데이터에 대한 독점권을 가질 수 있음)

[ 양립성 ]

양립성은 서로 다른 트랜잭션이 동일한 데이터에 lock 연산을 동시에 실행할 수 있는지를 결정한다.

공용 lock과 전용 lock 연산 사이의 양립성은 위의 표와 같다.
공용 lock이 양립 가능하다는 것은 서로 다른 트랜잭션이 같은 데이터에 공용 lock 연산을 동시에 실행할 수 있다는 뜻이다.
하지만 다른 트랜잭션이 전용 lock 연산을 실행한 데이터에서는 공용 lock과 전용 lock을 모두 실행할 수 없고, 해당 데이터에 unlock 연산이 실행될 때까지 기다려야 한다.

또한, 기본 로킹 규약만으로는 트랜잭션 스케줄의 직렬 가능성을 완벽하게 보장할 수 없다. 즉, 모든 트랜잭션이 기본 로킹 규약을 지키더라도 트랜잭션 데이터에 너무 빨리 unlock 연산을 실행하거나 하면 다른 트랜잭션이 일관성 없는 데이터에 접근하여 잘못된 결과를 얻을 수도 있다.

-> 따라서 트랜잭션 스케줄의 직렬 가능성을 보장하려면 기본 로킹 규약으로는 부족하고, lock과 unlock 연산을 실행하는 시점에 대한 새로운 규약이 추가로 필요하다. 이것이 바로 이어서 살펴볼 2단계 로킹 규약이다.

2단계 로킹 규약

2단계 로킹 규약(2PLP: 2 Phase Locking Protocol)은 기본 로킹 규약의 문제를 해결하고 트랜잭션의 직렬 가능성을 보장하기 위해 lock과 unlock 연산의 수행 시점에 대한 새로운 규약을 추가한 것이다.
트랜잭션이 lock과 unlock 연산을 확장 단계와 축소 단계로 나누어 수행한다.
-> 트랜잭션 스케줄의 모든 트랜잭션이 2단계 로킹 규약을 준수하면 해당 스케줄은 직렬 가능성이 보장된다.
확장 단계 -> 트랜잭션이 lock 연산만 실행할 수 있고, unlock 연산은 실행할 수 없는 단계
축소 단계 -> 트랜잭션이 unlock 연산만 실행할 수 있고, lock 연산은 실행할 수 없는 단계

-> 트랜잭션이 처음에 수행되면 확장 단계로 들어가 lock 연산만 실행할 수 있다. 그러다가 unlock 연산을 실행하면 축소 단계로 들어가 그때부터는 unlock 연산만 실행할 수 있다. 2단계 로킹 규약을 준수하는 트랜잭션은 첫 번째 unlock 연산을 실행하기 전에 필요한 모든 lock 연산을 실행해야 한다.

위 그림은 트랜잭션 T1과 T2가 모두 2단계 로킹 규약을 준수하므로 직렬 가능성을 보장할 수 있다.
-> 하지만 교착상태(deadlock)가 발생할 수 있어 이에 대한 해결책이 필요하다.
교착 상태는 트랜잭션들이 상대가 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리면서 수행을 중단하고 있는 상태다. 교착 상태에 빠지면 트랜잭션들은 더 이상 수행하지 못하고 상대 트랜잭션이 먼저 unlock 연산을 실행해주기를 한없이 기다리게 된다.
ex) 예를 들어 트랜잭션 T1과 T2가 모두 데이터 X와 데이터 Y에 접근하는 상황을 생각해보자.
트랜잭션 T1이 T2가 lock한 데이터 X에 접근하기 위해 T2가 unlock 연산을 실행해주기를 기다리고 있고 T2는 T1이 lock한 데이터 Y에 접근하기 위해 T1이 unlock 연산을 실행해주기를 기다리고 있다면 교착 상태가 된다.
교착 상태는 처음부터 발생하지 않도록 예방하거나, 발생했을 때 빨리 탐지하여 필요한 조치를 취하는 방법으로 해결한다.

References

데이터베이스 개론, 김연희(2022)

저작자표시 비영리 변경금지