DBMS - TCL, 트랜잭션, 동시성 제어 모듈, 회복 모듈

 

 

트랜잭션

하나의 작업단위를 말한다

수행할 명령들을 하나의 단위로 묶은것

범위는 사용자가 트랜잭션 명령어를 통해 표기 한다.

 

하나의 트랜잭션은 commit되거나 rollback 되어야 함

 

commit : 트랜잭션 완료. 성공적인 종료. 수행한 명령어는 DB에 반영되어야 함 

rollback : 트랜잭션 철회. 비성공적인 종료(DB 불일치, 일부를 성공적으로 끝내지 못함)

 

DB 반영?

디스크 입출력은 CPU수행 속도에 비해 속도가 느리다.

여러 트랜잭션이 같은 데이터를 디스크에서 참조하고 갱신한다면

연산을 디스크에서 계속 입출력 하지않고, 한번 주기억 장치에 읽고

주기억장치 버퍼 내에서 데이터를 유지하다가 트랜잭션이 모두 완료될때 디스크에 기록한다.

 

---

 

 

MS-SQL 트랜잭션 명령어 

 

- 트랜잭션 시작

BEGIN TRAN;

 

- 커밋(트랜잭션 완료하기)

COMMIT TRAN;

하나의 트랜잭션 단위를 완료함

 

- 롤백(트랜잭션 취소하기)

ROLLBACK TRAN;

명령이 모두 취소된다

 

 

- 구조

BEGIN TRAN; 
--이 안에 수행할 명령어들을 표기한다
COMMIT TRAN | ROLLBACK TRAN; 

 

 

---

 

지켜져야할 트랜잭션 특성 (ACID 특성)

특성	설명
원자성 Atomicity	트랜잭션의 결과는 명령어가 모두 수행되거나 아니면 아예 수행되지 않거나 해야한다 all or nothing
일관성 Consistency	트랜잭션 수행 이후에는 또하나의 일관된 DB가 유지된다. 트랜잭션 실행 전과 후가 같아야 한다는 성질. 트랜잭션 수행도중에는 일관된 상태를 갖지 않을 수 있음
독립성 Isolation	트랜잭션이 어떤 데이터를 참조중이면 다른 트랜잭션은 접근 못한다.
지속성 Durability	한번 갱신된건 고장나도 손실되면 안됨. 적용되어 있어야함.

 

이를 위해 트랜잭션 관리 모듈이 존재한다.

 

---

 

 

트랜잭션 관리 모듈

> 동시성 제어모듈(일관성,독립성 보장) + 회복 모듈(원자성, 지속성 보장)

 

 

동시성 제어모듈

> 다수 사용자가 동시에 DB를 접근하므로 일관성과 무결성을 위해

동시성 제어를 함

> 사용기법 : Locking 

 

회복 모듈 

> DB 갱신도중 시스템이 고장나도 일관성을 유지함 

> 사용기법 : Log DB

 

---

 

동시성 제어 

> 여러 사용자가 다수 트랜잭션을 동시에 수행할때, 트랜잭션간 간섭이 안생기도록 함 

> 직렬성이 보장되어야 한다.

> 어떻게 일관성과 독립성을 보장하는가 ?

> 가장 널리 사용하는 기법 : 로킹

 

*직렬가능(serializable)

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

 

 

동시성 제어의 목적

DB 공유도 최대화

사용자 응답시간 최소화

시스템 활용도 최대화

DB 일관성 유지

 

 

 

 동시성 제어를 하지 않을때 문제점 

- 갱신 손실(lost update) : 수행 중인 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어써서 갱신이 무효가됨

- 오손 데이터 읽기(dirty read) : 완료되지 않은 트랜잭션이 갱신한 데이터를 읽음

- 반복할 수 없는 읽기(unrepeatable read) : 한 트랜잭션 내에 동일한 데이터를 두 번 읽을때 읽은 값이 서로 다름

 

 

 데이터베이스 연산 종류 

Input(X) : X를 포함하는 디스크 블록 -> 주기억장치 버퍼로 읽어오기

Output(X) : 주기억장치 버퍼 -> X를 포함하는 디스크 블록  으로 쓰기

read_item(X) : 주기억장치 버퍼 -> 프로그램변수 로 읽어오기

write_item(X) : 프로그램변수 -> 주기억장치 버퍼 로 쓰기

 

 

---

 

로킹 locking

 

> 데이터에 로크를 걸어서 동시 접근 조정

> 해당 데이터에 대해 로크를 가지고 있어야 접근 가능

> 트랜잭션이 데이터에 접근을 끝내면 로크 해제 (unlock)

 

> 로크(lock) : 각 데이터 항목에 연관된 하나의 변수

> 로크정보는 lock table 로 유지

 

 

 

 로크종류 

독점로크(X-lock) : 갱신을 목적으로 데이터를 접근할때 요청하는 로크 eXclusive lock 

공유 로크(S-lock) :  읽기를 목적으로  Shared lock

 

 

 요청 허용여부 

- 현재 해당 데이터에 대해 걸려있는 로크가 공유 로크일때

> 요청로크 : 공유 => 허용

> 요청로크 : 독점 => 대기

 

- 현재 걸려있는 로크가 독점 로크면 요청 대기

- 걸려있는 로크가 없으면 요청 허용 

 

로킹 문제점

로킹 기법을 사용한다고 해서 동시성 제어 문제가 완전히 해결되지 못함

 

 

2단계 로킹 프로토콜 (2-phase locking protocol)

- 1 단계 ; 로크 확장(요청) 단계

> 새로운 로크를 요청할 수 있지만, 보유하고 있던 로크는 해제할 수 없음

 

- 2 단계 : 로크 수축(축소) 단계

> 보유하는 로크를 해제할 수 있지만, 새로운 로크는 요청불가

>  해제하는 방법에는 조금씩 해제 or 완료시점에서 한꺼번에 해제. 보통은 한꺼번에 해제함

 

 

로크 포인트(lock point) : 한 트랜잭션에서 필요로 하는 모든 로크를 걸어놓은 시점

 

 

데드락 (deadlock, 교착상태)

두 개 이상의 트랜잭션이 서로 상대방이 보유하고 있던 로크를 요청하면서 무한 대기하는 상태

해결 => 데드록 방지 기법 적용, 희생자 선정

 

 

 

다중 로크 단위

> 한 트랜잭션에서 로크할 수 있는 데이터 항목이 두 가지 이상 있는것

> 문제점 : 여러 튜플 접근시 튜플단위로 로크하면 다루는 시간이 오래걸림

 

로킹 단위 : DB단위, 릴레이션단위, 디스크 블록단위, 튜플단위

 

로킹 단위를 작게 했을때

- 병행수준이 뛰어나지만 관리 어려움

- 데이터 공유도 증가

- 병행제어 기법이 복잡

 

크게 했을때

- 병행 수준이 낮지만 관리 수월

- 데이터 공유도 감소

- 병행제어 기법 간단

 

 

---

 

회복

> 장애 발생시 이전의 일관된 상태가 되도록 복원하는 일

> 어떻게 원자성과 지속성을 보장할 것인가?

> 회복기법 : 로그(log) 를 남긴다 

 

 

 회복을 위해 DBMS가 하는 3가지 

- 백업 : 자기테이프에 로그를 백업한다 

- 로깅 : 트랜잭션 연산에 대해 로그를 남긴다 

- 체크포인트 : 트랜잭션이 디스크에 반영 완료된 시점을 기록

 

 

고장 유형

- 재해적 고장 발생

> 백업한 자기테이프 이용

- 비재해적 고장 발생

> 회복 알고리즘 적용 ex)로그를 이용한 즉시갱신, 로그를 이용한 지연 갱신, 그림자 페이징(shadow paging)

> 대부분 DBMS는 로그를 이용한 즉시갱신 방식을 사용

 

 

 로그를 기반으로 한 즉시 갱신 

> 모든 트랜잭션 연산에 대해 로그 레코드 기록

> 각 레코드는 로그 순서 번호 (LSN : Log Sequence Number) 로 식별됨 

> 각 로크 레코드마다 어떤 트랜잭션에 속하는지 식별하기 위해 트랜잭션ID 포함

> 이중로그(dual logging) 사용 (로그를 두 개의 디스크에 중복 저장)

 

 

 로그 레코드 유형 

[Trans-ID, start] : 트랜잭션이 생성될때 기록

[Trans-ID, X, old_value, new_value] : X 값이 수정될때. old_value는 취소에 new_value는 재수행에 사용 

[Trans-ID, commit] : 트랜잭션이 완료될때 기록. 트랜잭션의 완료점(commit point)

[Trans-ID, abort] : 트랜잭션이 철회될때 기록

 

 

트랜잭션이 주기억 버퍼에는 갱신 사항을 반영했으나,

 디스크에 기록되기 전에 고장이 발생했다면? 

=> 로그 조사

> [Trans-ID, commit] 가 존재하면 갱신 사항을 재수행(REDO)

> 없으면 취소(UNDO)

 

 

로그 먼저쓰기(WAL : Write-Ahead Logging)란?

> 트랜잭션이 DB를 갱신하면

1. 주기억 데이터베이스 버퍼에 갱신사항을 기록

2. 로그 버퍼에는 이에 대응되는 로그 레코드를 기록

이때 데이터 보다 로그 버퍼가 디스크에 먼저 기록되어야 한다.

 

 

 

 체크포인트(checkpoint) 

> DBMS는 회복시 수행할 트랜잭션 수를 줄이기 위해 주기적으로 체크포인트 수행

> 보통 체크포인트는 10~20분에 한번씩 수행함

> 체크포인트 작업이 끝나면 로그에 [checkpoint] 레코드가 기록됨

 

 

 체크포인트 작업 

1. 수행중인 트랜잭션 중지

2. 주기억 로그 버퍼를 디스크로 강제 출력

3. 주기억 데이터베이스버퍼를 디스크로 강제 출력

4. [checkpoint] 로그 레코드를 로그 버퍼에 기록하고 디스크로 강제 출력

>  체크포인트 시점에 수행중이던 트랜잭션 ID도 [checkpoint] 로그 레코드에 함께 기록

5. 트랜잭션 수행 재개

 

체크포인트 이전에 수행완료된 트랜잭션은

디스크에 이미 반영 완료된것임

따라서 그건 REDO 안해도됨