Transactions
DBMS의 성능을 향상시키기 위해서는 사용자 프로그램의 동시 실행이 필수적이다.
디스크 액세스는 빈번하게 발생하며 비교적 느리기 때문에 CPU를 활용하여 여러 사용자 프로그램을 동시에 처리하는 것이 중요하다.
사용자 프로그램은 데이터베이스에서 검색한 데이터에 대해 많은 작업을 수행할 수 있지만, DBMS는 데이터베이스에서 읽거나 쓰는 데이터에만 관심이 있기 때문이다.
DBMS는 사용자 프로그램을 추상화하여 트랜잭션(Transaction)이라는 개념으로 표현한다.
트랜잭션은 읽기와 쓰기의 연속으로 구성된 DBMS의 추상적인 사용자 프로그램이다.
트랜잭션은 일련의 데이터베이스 작업으로 구성됩니다. 일반적으로 트랜잭션은 다음과 같은 단계로 진행된다.
- 시작 (Begin)
트랜잭션이 시작되는 단계로, 이 단계에서는 트랜잭션 내에서 사용될 수 있는 자원을 할당받는다. - 읽기 (Read)
트랜잭션이 데이터베이스에서 데이터를 읽는다. - 쓰기 (Write)변경된 데이터는 트랜잭션이 커밋될 때까지 임시로 보관된다.
트랜잭션이 데이터베이스에 데이터를 변경하거나 쓰기 작업을 수행한다. - 커밋 (Commit)
트랜잭션이 성공적으로 완료되었으며, 모든 작업이 데이터베이스에 영구적으로 적용된다. - 롤백 (Rollback)
트랜잭션 실행 중에 오류가 발생하거나 롤백 명령이 내려진 경우, 트랜잭션의 모든 작업이 취소되고 이전 상태로 되돌아간다.
트랜잭션은 원자성, 일관성, 고립성, 지속성(ACID)이라는 속성을 보장받는다.
이러한 속성은 데이터베이스의 일관성과 신뢰성을 유지하기 위해 중요하다.
트랜잭션은 데이터베이스에 안전하게 변경을 적용하고, 동시에 실행되는 다른 트랜잭션들과 충돌하지 않도록 제어한다.
Concurrency in DBMS
DBMS에서 동시성(Concurrency)은 사용자가 각각의 트랜잭션을 독립적으로 실행하는 것처럼 생각할 수 있도록 보장된다.
동시성은 DBMS에 의해 여러 트랜잭션의 작업(데이터베이스 객체의 읽기/쓰기)이 교차하여 실행됨으로써 달성된다.
트랜잭션이 시작될 때 데이터베이스가 일관성을 가지고 있다면, 각 트랜잭션이 실행을 마친 후에도 데이터베이스는 일관성을 유지해야 한다.
DBMS는 CREATE TABLE 문에서 선언된 무결성 제약 조건에 따라 일부 무결성 제약 조건을 강제한다.
이를 통해 데이터의 일관성과 무결성을 보장한다.
하지만 DBMS는 실제 데이터의 의미론적 이해를 가지고 있지는 않다.
동시성에서 주요한 문제점은 트랜잭션들의 교차 실행과 시스템 충돌의 영향이다.
여러 트랜잭션이 동시에 실행되면서 발생하는 교차 실행(interleaving)은 예기치 않은 결과를 초래할 수 있다.
트랜잭션 간에 어떤 순서로 작업이 교차되느냐에 따라 데이터의 일관성이 깨질 수 있다.
또한, 시스템 충돌(crash)은 데이터베이스 시스템에 영향을 줄 수 있는 다른 문제이다.
시스템 충돌이 발생하면 데이터 손실이 발생할 수 있고, 복구 메커니즘을 통해 이전 상태로 복구해야 한다.
이러한 동시성과 충돌 관련 문제들은 DBMS가 데이터베이스 시스템 내에서 적절한 병행 제어(Concurrency Control) 메커니즘을 사용하여 해결한다.
이는 트랜잭션들 간의 동시 실행을 조절하고 충돌을 방지하며, 데이터 일관성과 동시성을 보장한다.
Atomicity of transaction
트랜잭션의 원자성(Atomicity)은 데이터베이스 관리 시스템(DBMS)에서 보장하는 매우 중요한 속성이다.
원자성은 트랜잭션이 항상 모든 작업을 한 번에 실행하거나 전혀 실행하지 않는 것으로 간주될 수 있다는 것을 의미한다.
원자성은 또한 트랜잭션의 모든 작업이 원자적인 단위로 간주되어야 함을 의미한다.
트랜잭션이 시작되면 모든 작업이 완료될 때까지 트랜잭션의 실행은 완전히 숨겨져야 한다.
사용자는 트랜잭션을 단일 단위로 생각할 수 있으며, 중간 단계의 상태를 볼 수 없다.
따라서 트랜잭션은 모두 성공적으로 실행되거나 아무 작업도 수행하지 않은 것처럼 보여야 한다.
DBMS는 원자성을 보장하기 위해 로그(Log)를 사용한다.
로그는 트랜잭션의 모든 작업을 기록하여 트랜잭션의 실행 상태를 추적한다.
만약 트랜잭션 중간에 오류가 발생하여 트랜잭션이 롤백되어야 할 경우, DBMS는 로그를 사용하여 이전 상태로 되돌릴 수 있다.
롤백 작업은 로그에 기록된 작업들을 역순으로 실행하여 트랜잭션의 모든 변경사항을 취소한다.
원자성은 데이터베이스의 일관성과 신뢰성을 보장하기 위한 중요한 개념이다.
트랜잭션의 작업들이 원자적으로 처리되므로써 일관성이 유지되고, 중간 오류로 인해 데이터베이스가 손상되는 것을 방지할 수 있다.
Scheduling Transactions
트랜잭션들의 스케줄링(Scheduling)은 트랜잭션들이 어떤 순서로 실행되는지를 결정하는 것을 의미한다.
스케줄은 트랜잭션들의 작업들이 어떻게 교차하여 실행되는지를 정의한다.
Serial Schedule
직렬 스케줄(Serial Schedule)은 서로 다른 트랜잭션들의 작업들이 교차하지 않는 스케줄이다.
즉, 하나의 트랜잭션이 모든 작업을 완료한 후에 다음 트랜잭션이 작업을 수행하는 순차적인 스케줄을 의미한다.
직렬 스케줄은 트랜잭션들을 동시에 실행하지 않으므로 데이터 일관성은 보장된다.
Equivalent Schedule
등가 스케줄(Equivalent Schedules)은 실행된 첫 번째 스케줄과 실행된 두 번째 스케줄의 결과가 어떤 데이터베이스 상태에서도 동일하게 나타난다는 것을 의미한다.
즉, 스케줄의 순서를 변경하더라도 최종적인 데이터베이스 상태는 동일하게 유지된다.
이는 스케줄의 실행 순서가 변경되더라도 트랜잭션들이 동일한 결과를 도출한다는 것을 보장한다.
Serializable Schedule
직렬 가능한 스케줄(Serializable Schedule)은 트랜잭션들의 스케줄이 어떤 직렬 실행(Serial Execution)과 동등하다는 것을 의미한다.
직렬 실행은 트랜잭션들을 순차적으로 실행하는 것을 의미하며, 트랜잭션들의 작업들이 서로 교차하지 않는다.
따라서 직렬 가능한 스케줄은 데이터베이스 시스템이 동시성을 보장하면서도 결과적으로는 순차 실행과 동일한 결과를 보장한다.
직렬 스케줄은 직렬 가능한 스케줄의 특수한 경우이다.
모든 직렬 스케줄은 직렬 가능하며, 직렬 가능한 스케줄은 모든 트랜잭션이 일관성을 유지한다면 항상 일관성을 유지한다.
스케줄링은 병행 제어(Concurrency Control) 메커니즘을 통해 관리된다.
DBMS는 트랜잭션들 간의 동시 실행을 제어하여 직렬 가능한 스케줄이나 다른 적절한 스케줄을 유지하고, 데이터의 일관성과 동시성을 보장한다.
Anomalies with Interleaved Execution
데이터베이스에서 교차 실행(Interleaved Execution)으로 인해 발생할 수 있는 문제를 Anomalies라고 한다.
Anomalies는 트랜잭션들이 동시에 실행되면서 예기치 않은 결과가 발생할 수 있는 현상을 의미한다.
주요한 Anomalies에는 다음과 같은 세 가지가 있다.
- Dirty Read (더티 리드, WR Conflicts)
하나의 트랜잭션이 데이터를 수정 중인 동안 다른 트랜잭션이 해당 데이터를 읽는 경우 발생한다.
이로 인해 수정 중인 데이터에 대한 잘못된 정보를 읽게 되는데, 이 정보는 후에 롤백될 수 있어 실제로는 존재하지 않는 데이터일 수도 있다. - Unrepeatable Read (반복 불가능한 리드, RW Conflicts)
하나의 트랜잭션이 같은 데이터를 두 번 읽는 과정에서, 중간에 다른 트랜잭션이 해당 데이터를 수정하는 경우 발생한다.
이로 인해 첫 번째 읽은 값과 두 번째 읽은 값이 다를 수 있게 된다. - Overwriting Uncommitted Data (WW Conflicts)
하나의 트랜잭션이 일련의 데이터를 검색하는 도중에 다른 트랜잭션이 해당 데이터 집합에 새로운 행을 삽입하는 경우 발생한다.
이로 인해 처음에는 존재하지 않던 데이터가 나중에는 존재하는 것처럼 보이게 된다.
이러한 Anomalies들은 동시성 제어(Concurrency Control) 메커니즘이 적절하게 구현되지 않거나, Anomalies를 방지하기 위한 격리 수준(Isolation Level)이 낮게 설정된 경우에 발생할 수 있다.
DBMS는 동시성 제어 기법과 격리 수준 설정을 통해 이러한 Anomalies들을 방지하고 데이터의 일관성을 유지한다.
Lock-Based Concurrency Control
Strict 2PL
락 기반 병행 제어(Lock-Based Concurrency Control) 중에서도
"엄격한 이중 잠금(Strict Two-phase Locking, Strict 2PL)프로토콜"은
트랜잭션이 데이터에 대한 동시 액세스를 조율하기 위해 사용되는 프로토콜이다.
Strict 2PL 프로토콜은 다음과 같은 특징을 가지고 있다.
- 읽기 작업 이전에 S (공유) 잠금을 획득해야 하며, 쓰기 작업 이전에 X (배타적) 잠금을 획득해야 한다.
S 잠금은 다른 트랜잭션도 공유 잠금을 획득할 수 있도록 허용하지만, X 잠금은 다른 트랜잭션이 공유나 배타적 잠금을 획득할 수 없도록 차단한다. - 트랜잭션이 완료되면 해당 트랜잭션에 의해 보유된 모든 잠금이 해제된다.
이는 트랜잭션의 일관성을 유지하면서 다른 트랜잭션이 해당 데이터에 액세스할 수 있도록 한다. - X 잠금을 보유한 트랜잭션이 특정 객체에 대해 X 잠금을 보유하고 있는 경우, 다른 트랜잭션은 해당 객체에 대해 S나 X 잠금을 획득할 수 없다.
이로 인해 엄격한 일관성과 직렬 가능성(serializability)을 유지할 수 있다.
Strict 2PL 프로토콜은 직렬 가능한 스케줄만 허용한다.
이 프로토콜은 트랜잭션의 중단 처리를 간단하게 만들어 준다.
중단된 트랜잭션은 보유한 모든 잠금을 해제하여 다른 트랜잭션이 해당 데이터에 액세스할 수 있게 된다.
Non-strict Two-phase Locking
Strict 2PL과는 달리, 비엄격한 이중 잠금(Non-strict Two-phase Locking, Non-strict 2PL) 프로토콜은 잠금 해제를 언제든지 수행할 수 있지만, 한 번 잠금을 해제한 후에는 다시 잠금을 획득할 수 없다.
Non-strict 2PL도 직렬 가능한 스케줄만 허용하며, 중단 처리 과정이 더 복잡해진다.
이러한 락 기반 병행 제어 프로토콜들은 데이터베이스에서 동시성을 관리하고 데이터 일관성과 동시성을 유지하는 데 중요한 역할을 한다.
Aborting a Transaction
트랜잭션이 중단되는 경우, 해당 트랜잭션의 모든 작업은 원상태로 복원되어야 한다.
뿐만 아니라, 만약 다른 트랜잭션이 원래 트랜잭션에 의해 마지막으로 쓰인 객체를 읽는다면, 다른 트랜잭션도 중단되어야 한다.
이러한 상황을 Cascading Abort라고 한다.
많은 시스템에서는 트랜잭션의 락(Lock)을 커밋 시점에만 해제하여 Cascading Abort을 피한다.
따라서 Ti가 객체를 쓴 후에만 Tj가 해당 객체를 읽을 수 있다.
이를 통해 Cascading Abort을 방지하고 데이터의 일관성을 유지할 수 있다.
중단된 트랜잭션의 작업을 취소하기 위해 DBMS는 로그(Log)를 유지한다.
로그는 각 쓰기 작업이 기록되는 메커니즘으로, 중단된 트랜잭션의 작업을 원래의 상태로 복구하는 데 사용된다.
이 로그 메커니즘은 시스템 충돌로부터 복구하는 데에도 사용된다.
시스템이 충돌하는 경우, 충돌 당시 활성화된 모든 트랜잭션은 시스템이 다시 시작될 때 중단된다.
이러한 방식으로 중단된 트랜잭션의 작업을 취소하고, Cascading Abort를 방지하며, 시스템 충돌로부터 복구할 수 있다.
이는 데이터베이스 시스템의 일관성과 신뢰성을 보장하는 데 중요한 역할을 한다.
The Log
로그(Log)에는 다음과 같은 작업들이 기록된다.
- 기존 트랜잭션이 객체를 쓰는 경우
이전 값과 새 값이 로그에 기록된다.
변경된 페이지가 디스크로 기록되기 전에 로그 레코드가 기록되어야 한다. - 기존 트랜잭션의 커밋/중단
이 작업을 나타내는 로그 레코드가 생성된다.
이로써 해당 트랜잭션의 완료 상태를 나타내는 정보가 로그에 남게 된다.
로그 레코드는 트랜잭션 ID에 의해 연결되어 있으므로 특정 트랜잭션의 작업을 취소하는 것이 쉽다.
특정 트랜잭션의 로그 레코드를 찾아서 해당 작업을 취소하면 된다.
로그는 종종 이중화(Duplexing)되고 안정적인 저장소(Stable Storage)에 아카이브된다.
이를 통해 로그 데이터의 내구성을 보장하고 시스템 장애 발생 시에도 로그 데이터를 복구할 수 있다.
로그와 관련된 활동 및 락(Lock)/언락(Unlock), 교착 상태(Deadlock) 처리 등과 같은 모든 병행 제어 관련 활동은 DBMS에 의해 투명하게 처리된다.
사용자는 이러한 내부 작업에 대해 직접적인 관여나 조작을 할 필요 없이 데이터베이스 시스템을 사용할 수 있다.
'CS > 데이터베이스' 카테고리의 다른 글
| 통계 DB의 보안(내용보완필요) (0) | 2024.04.04 |
|---|---|
| 인터넷 응용프로그램의 보안 (0) | 2024.03.08 |
| 파일 구성과 인덱싱 (0) | 2024.03.01 |
| 디스크와 파일 (0) | 2024.03.01 |
| B+ Tree (0) | 2024.03.01 |
