데이터베이스 11주차 정리

트랜잭션

---

트랜잭션의 개념

트랜잭션(transaction): DBMS에서 데이터를 다루는 논리적인 작업의 단위

 

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

데이터베이스에서 데이터를 다룰 때 장애가 일어날 때 데이터를 복구하는 작업의 단위가 됨

데이터베이스에서 여러 작업이 동시에 같은 데이터를 다룰 때가 이 작업을 서로 분리하는 단위가 됨

 

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

예)은행 업무를 보는데 A 계좌(박지성)에서 B 계좌(김연아)로 10,000원을 이체할 경우

트랜잭션 수행 과정

 

① A 계좌(박지성)의 값을 하드디스크(데이터베이스)에서 주기억장치 버퍼로 읽어온다

② B 계좌(김연아)의 값을 하드디스크(데이터베이스)에서 주기억장치 버퍼로 읽어온다.

③ A 계좌(박지성)에서 10,000원을 인출한 값을 저장한다.

④ B 계좌(김연아)에 10,000원을 입금한 값을 저장한다.

⑤ A 계좌(박지성)의 값을 주기억장치 버퍼에서 하드디스크(데이터베이스)에 기록한다.

⑥ B 계좌(김연아)의 값을 주기억장치 버퍼에서 하드디스크(데이터베이스)에 기록한다.

 

트랜잭션의 종료(COMMIT)를 알리는 방법

[방법 1] ①-②-③-④-COMMIT-⑤-⑥

[방법 2] ①-②-③-④-⑤-⑥-COMMIT

→ DBMS는 사용자에게 빠른 응답성을 보장하기 위해 [방법 1]을 선택한다.

트랜잭션의 성질 *

원자성(Atomicity) : 트랜잭션에 포함된 작업은 전부 수행되거나 아니면 전부 수행되지 않아야 (all or nothing) 함

일관성(Consistency) : 트랜잭션을 수행하기 전이나 수행한 후나 데이터베이스는 항상 일관된 상태를 유지해야 함

고립성(Isolation) : 수행 중인 트랜잭션에 다른 트랜잭션이 끼어들어 변경 중인 데이터값을 훼손하는 일이 없어야 함

지속성(Durability) : 수행을 성공적으로 완료한 트랜잭션은 변경한 데이터를 영구히 저장해야 함

---

트랜잭션의 성질 – 원자성 (Atomicity)

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

일부만 수행되는 일이 없도록 전부 수행하거나 아예 수행하지 않아야(all or nothing) 함

COMMIT, ROLLBACK 같은 트랜잭션 제어 명령어 (Transaction Control Language)를 이용한다

---

트랜잭션의 성질 – 일관성 (Consistency)

트랜잭션은 데이터베이스의 일관성을 유지해야 함.

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

---

트랜잭션의 성질 – 고립성 (Isolation)

데이터베이스는 공유가 목적이므로 여러 트랜잭션이 동시에 수행됨

동시에 수행되는 트랜잭션은 상호 존재를 모르고 독립적으로 수행되는데, 이를 고립성이라고 함.

고립성을 유지하기 위해서는 트랜잭션이 변경 중인 임시 데이터를 다른 트랜잭션이 읽고 쓸 때 제어가 필요함

= 동시성 제어

---

트랜잭션의 성질 – 지속성 (Durability)

트랜잭션이 정상적으로 완료(commit) 혹은 부분완료(partial commit)한 데이터는 DBMS가 책임지고

데이터베이스에 기록하는 성질

 

버퍼내용 기록 전에 시스템 다운 등으로 실패하면 트랜잭션이 수행한 작업을 모두 원상복구한다

= 회복

---

트랜잭션의 성질

DBMS는 트랜잭션의 성질을 유지하기 위해 다음 기능들을 수행

---

동시성 제어

---

동시성 제어

동시성 제어(concurrency control) : 트랜잭션이 동시에 수행될 때, 일관성을 해치지 않도록 트랜잭션의 데이터 접근을 제어하는 DBMS의 기능

 

같은 데이터를 접근하는 두 트랜잭션의 작업(읽기, 쓰기)에 따라 발생하는 상황

위 [상황 3]을 '갱신손실 문제 (LOST UPDATE)'라고 하며
두 개의 트랜잭션이 한 개의 데이터를 동시에 갱신(update)할 때 발생하며,
데이터베이스에서 절대 발생하면 안 되는 현상

 

갱신손실 문제

[작업 설명]

1. T1 트랜잭션은 계좌 X에서 100을 인출하고(UPDATE)

2. T2 트랜잭션은 계좌 X에서 100을 입금한다(UPDATE)

 

[시나리오]

두 개의 트랜잭션이 동시에 작업을 진행한다

데이터베이스를 읽을 때 주기억장치의 버퍼로 가져와야 읽을 수 있다

트랜잭션은 버퍼의 저장 값을 가지고 작업을 수행한다.

 

[문제 발생]

T2는 잘못된 데이터로 작업하여 잘못된 결과를 만든 다음, T1의 갱신 작업을 무효화하고 덧쓰기를 수행한 것임

T1의 갱신이 손실된 갱신손실(lost update) 문제가 발생한 것

락

- 갱신손실 문제를 해결하려면 상대방 트랜잭션이 데이터를 사용하는지 여부를 알 수 있는 규칙이 필요함

- 데이터를 수정 중이라는 사실을 알리는 방법의 잠금 장치

 

1.T1 트랜잭션에 X 데이터를 이용하면 락을 설정한다

2.T2 트랜잭션은 자신이 원하는 데이터를 얻지 못하고 대기(WAIT)한다

3.T1 트랜잭션이 작업을 완료하고 언락(UNLOCK)하면 T2 트랜잭션이 진행된다

 

- 데이터를 수정이 순차적으로 진행되므로 갱신손실 문제를 해결할 수 있다

락 유형

공유락(LS, shared lock): 트랜잭션이 읽기를 할 때 사용하는 락

배타락(LX, exclusive lock): 읽고 쓰기를 할 때 사용하는 락

 

공유락과 배타락을 사용하는 규칙

- 데이터에 락이 걸려있지 않으면 트랜잭션은 데이터에 락을 걸 수 있다.

- 트랜잭션이 데이터 X를 읽기만 할 경우 LS(X)를 요청하고, 읽거나 쓰기를 할 경우 LX(X)를 요청한다.

- 다른 트랜잭션이 데이터에 LS(X)을 걸어둔 경우, LS(X)의 요청은 허용하고 LX(X)는 허용하지 않는다.

- 다른 트랜잭션이 데이터에 LX(X)을 걸어둔 경우, LS(X)와 LX(X) 모두 허용하지 않는다.

- 트랜잭션이 락을 허용받지 못하면 대기 상태가 된다.

- 밑은 허용 관계를 학 호환 행렬 (Compatibility Matrix)로 표시한 것이다.

---

2단계 락킹

2단계 락킹 기법 :

락을 걸고 해제하는 시점에 제한을 두지 않으면 두 개의 트랜잭션이 동시에 실행될 때

데이터의 일관성이 깨질 수 있어 이를 방지하는 방법

 

확장단계(Growing phase, Expanding phase) :

트랜잭션이 필요한 락을 획득하는 단계로, 이 단계에서는 이미 획득한 락을 해제하지 않음

 

수축단계(Shrinking phase) :

트랜잭션이 락을 해제하는 단계로, 이 단계에서는 새로운 락을 획득하지 않음.

 

데드락

두 개 이상의 트랜잭션이 각각 자신의 데이터에 대하여 락을 획득하고 상대방 데이터에 대해 락을 요청하면 무한 대기 상태에 빠질 수 있는 현상으로, 교착상태라고도 함

---

트랜잭션 고립 수준

---

트랜잭션 고립 수준

- 앞서 배운 락은 [상황 3] (쓰기, 쓰기)의 상황을 해결하기 위해 사용된다.

 

- [상황 2]에도 락을 사용할 수 있지만 이는 두 트랜잭션의 동시 진행 정도를 과도하게 막는다

 

- [상황 2]의 동시성을 높이기 위해 사용한 완화된 방법들에도 문제들이 발생한다.

---

오손 읽기 (Dirty Read)

- 읽기 작업을 하는 트랜잭션 1이 쓰기 작업을 하는 트랜잭션 2가 작업한 중간 데이터를 읽기 때문에 생기는 문제

 

- 작업 중인 트랜잭션 2가 어떤 이유에서 작업을 철회(ROLLBACK)할 경우
트랜잭션 1은 무효가 된 데이터를 읽게 되고 잘못된 결과를 도출하는 현상

---

반복불가능 읽기 (Non-Repeatable Read)

 

- 트랜잭션 1이 데이터를 읽고 트랜잭션 2가 데이터를 쓰고(갱신, UPDATE)

트랜잭션 1이 다시 한 번 데이터를 읽을 때 생기는 문제

- 트랜잭션 1이 읽기 작업을 다시 한 번 반복할 경우 이전의 결과와 다른 결과가 나오는 현상

---

유령데이터 읽기 (Phantom Read)

 

- 트랜잭션 1이 데이터를 읽고 트랜잭션 2가 데이터를 쓰고(삽입, INSERT)

트랜잭션 1이 다시 한 번 데이터를 읽을 때 생기는 문제

 

- 트랜잭션 1이 읽기 작업을 다시 한 번 반복할 경우 이전에 없던 데이터(유령 데이터)가 나타나는 현상

---

트랜잭션 고립 수준 명령어 (Transaction Isolation Level Instruction)

DBMS는 트랜잭션을 동시에 실행시키면서 락보다 좀 더 완화된 방법으로 문제를 해결하기 위해 제공하는 명령어

 

트랜잭션 고립 수준 명령어와 발생 현상

---

회복

---

회복

데이터베이스에 장애가 발생했을 때 데이터베이스를 일관성 있는 상태로 되돌리는 DBMS의 기능

데이터베이스 시스템에서 발생할 수 있는 장애 유형

 

시스템 충돌 : 하드웨어 혹은 소프트웨어의 오류로 인하여 주기억장치가 손실되는 것을 말한다. 주기억장치에 상주하여 처리 중인 프로그램과 데이터의 일부 혹은 전부가 손실된다.

미디어 장애 : 헤드의 충돌이나 읽기 장애에 의하여 보조기억장치의 일부 데이터가 손실되는 것을 말한다. 보조기억장치에 저장 중인 데이터의 일부 혹은 전부가 손실된다.

응용 소프트웨어 오류 : 데이터베이스에 접근하는 소프트웨어의 논리적인 오류로 트랜잭션의 수행이 실패하는 것을 말한다.

자연재해 : 화재, 홍수, 지진, 정전 등에 의해 컴퓨터 시스템이 손상되는 것을 말한다.

부주의 혹은 태업(sabotage) : 운영자나 사용자의 부주의로 데이터가 손실되거나 의도적인 손상을 입는 것을 말한다.

 

트랜잭션과 회복

- 트랜잭션은 변경 내용을 한순간에 모두 기록하지 않는다.

- 변경한 내용(버퍼)을 로그(임시 디스크)에 기록한 후 데이터베이스에 반영한다.

- DBMS의 회복 관리자(Recovery Manager)는 트랜잭션의 원자성과 지속성을 보장하여

장애로부터 데이터베이스를 보호한다.

---

로그 파일

- 트랜잭션이 수행 중이거나 수행이 종료된 후 발생하는 데이터베이스 손실을 방지하기 위해

트랜잭션의 데이터베이스 기록을 추적하는 로그 파일(log file)을 사용함

- 로그 파일 :

트랜잭션이 반영한 모든 데이터의 변경사항을 데이터베이스에 기록하기 전에 미리 기록해두는 별도의 데이터베이스로,

안전한 하드디스크에 저장되며 전원과 관계없이 기록이 남아 있음

 

- 로그 파일에 저장된 로그의 구조

 <트랜잭션번호, 로그의 타입, 데이터 항목 이름, 수정 전 값, 수정 후 값>

 

- ‘로그의 타입’은 트랜잭션의 연산 타입으로 START, INSERT, UPDATE, DELETE, ABORT, COMMIT 등이 있다.

'수정 전 값’은 데이터의 변경 전 값을 나타내고, '수정 후 값’은 연산의 결과로 변경된 값을 나타냄

---

로그 파일을 이용한 회복

데이터의 변경 기록을 저장해 둔 로그 파일을 이용하면 시스템 장애도 복구할 수 있음

 

아래 두 개의 트랜잭션이 실행된다고 하자.

편의상 트랜잭션의 연산 SELECT, UPDATE는 read_item( ), write_item( )으로 대체한다.

트랜잭션은 각각 데이터 A, B, C, D를 읽거나 쓰는 작업을 진행한다.

데이터(A, B, C, D)의 초깃값은 (100, 200, 300, 400)이다.

트랜잭션이 T1 → T2 순으로 실행된다면 다음과 같은 로그 파일이 생성된다

- 시스템 운영 중 장애가 발생하여 시스템이 다시 가동되었을 때 DBMS는 로그 파일을 먼저 살펴본다.

 

- DBMS는 트랜잭션이 종료되었는지 혹은 중단되었는지 여부를 판단하여 종료된 트랜잭션은 종료를 확정하기 위하여

재실행(REDO)을 진행하고, 중단된 트랜잭션은 없던 일로 되돌리기 위해 취소(UNDO)를 진행한다.

 

- 트랜잭션의 재실행(REDO)

장애가 발생한 후 시스템을 다시 가동 했을 때, 로그 파일에 트랜잭션 시작(START)이 있고 종료(COMMIT)가 있는 경우다. COMMIT 연산이 로그에 있다는 것은 트랜잭션이 모두 완료되었다는 의미다. 다만 변경 내용이 버퍼에서 데이터베이스에 기록되지 않았을 가능성이 있다. 따라서 로그를 보면서 트랜잭션이 변경한 내용을 데이터베이스에 다시 기록하는 과정이 필요하다. 이 과정을 REDO라고 한다.

- 트랜잭션의 취소(UNDO)

장애가 발생한 후 시스템을 다시 가동했을 때, 로그 파일에 트랜잭션의 시작(START)만 있고 종료(COMMIT)가 없는 경우다. COMMIT 연산이 로그에 보이지 않는다는 것은 트랜잭션이 완료되지 못했다는 의미로, 트랜잭션이 한 일을 모두 취소해야 한다. 이 경우 완료하지 못했지만 버퍼의 변경 내용이 데이터베이스에 기록되어 있을 가능성이 있기 때문에 로그를 보면서 트랜잭션이 변경한 내용을 데이터베이스에서 원상복구시켜야 한다. 이 과정을 UNDO라고 한다.

---

- 즉시 갱신 방법

즉시 갱신(immediate update)은 ‘갱신 데이터→로그’, '버퍼→데이터베이스’ 작업이 부분완료 전에

동시에 진행될 수 있으며, 부분완료가 되면 갱신 데이터는 로그에 기록이 끝난 상태

 

- 지연 갱신 방법

지연 갱신(deferred update)은 ‘갱신 데이터→로그’가 끝난 후 부분완료를 하고

‘버퍼→데이터베이스’ 작업이 진행되는 방법