8장 트랜잭션, 동시성 제어, 회복

트랜잭션

• DZBMS에서 데이터를 다루는 논리적인 작업의 단위
• 원자성, 일관성, 고립성, 지속성의 성질을 가져야 한다.
• 데이터베이스에서 트랜잭션을 정의하는 이유
  • 데이터베이스에서 데이터를 다룰 때 장애가 일어날 때 데이터를 복구하는 작업의 단위가 됨.
  • 데이터베이스에서 여러 작업이 동시에 같은 데이터를 다룰 때가 이 작업을 분리하는 단위가 됨.
• 트랜잭션은 전체가 수행되거나 또는 전혀 수행되지 않아야 함(all or nothing)
• EX) 은행 업무를 보는데 A계좌(박지성)에서 B계좌(김연아)로 10000원을 이체할 경우

BEGIN
	A계좌에서 10000원을 인출하는 UPDATE문
	B계좌에서 10000원을 입금하는 UPDATE문
END

트랜잭션 수행 과정

1. A계좌의 값을 하드디스크(데이터베이스)에서 주기억장치 버퍼로 읽어온다
2. B계좌에 값을 하드디스크(데이터베이스)에서 주기억장치 버퍼로 읽어온다.
3. A계좌에서 10000원을 인출한 값을 저장한다.
4. B계좌에서 10000원을 입금한 값을 저장한다.
5. A계좌의 값을 주기억장치 버퍼에서 하드디스크(데이터베이스)에 기록한다.
6. B계좌의 값을 주기억장치 버퍼에서 하드디스크(데이터베이스)에 기록한다.

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

• 1~6의 과정을 수행 후 COMMIT
• 1~4의 과정을 수행 후 COMMIT 후 5~6의 과정을 수행 후 COMMIT

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

트랜잭션의 성질 (ACID)

원자성(Atomicity)

• 트랜잭션에 포함된 작업은 전부 수행되거나 아니면 전부 수행되지 않아야 함(all or nothing)
• 트랜잭션이 원자처럼 더 이상 쪼개지지 않는 하나의 프로그램 단위로 동작해야 한다.
• 오라클 트랜잭션 제어 명령어(TCL)

일관성(Consistency)

• 트랜잭션을 수행하기 전이나 수행한 후나 데이터베이스는 항상 일관된 상태를 유지해야 함.
• 일관성은 테이블이 생성 시 CREATE 문과 ALTER 문의 무결성 제약조건을 통해 명시됨.

고립성(Isolation)

• 수행 중인 트랜잭션에 다른 트랜잭션이 끼어들어 변경 중인 데이터 값을 훼손하는 일이 없어야 함.
• 데이터베이스는 공유가 목적이므로 여러 트랜잭션이 동시에 수행됨, 동시에 수행되는 트랜잭션은 상호 간의 존재를 모르고 독립적으로 수행되는데, 이를 고립성이라 함.
• 고립성을 유지하기 위해서는 트랜잭션이 변경 중인 임시 데이터를 다른 트랜잭션이 읽고 쓸 때 제어가 필요함.

지속성(Durability)

• 수행을 성공적으로 완료한 트랜잭션은 변경한 데이터를 영구히 저장해야 함.
• 정상적으로 완료(commit) 부분완료(partial commit)한 데이터는 DBMS가 책임지고 데이터베이스 기록하는 성질.

트랜잭션과 DBMS

• DBMS는 원자성을 유지하기 위해 회복(복구) 관리자 프로그램을 작동시킴.
• DBMS는 일관성을 유지하기 위해 무결성 제약조건을 활용함
• DBMS는 고립성을 유지하기 위해 일관성을 유지하는 것과 마찬가지로 동시성 제어 알고리즘을 작동시킴.
• DBMS는 지속성을 유지하기 위해 회복 관리자 프로그램을 이용함

동시성 제어

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

갱실손실 문제

• 갱실손실(lost update) : 두 개의 트랜잭션이 한 개의 데이터를 동시에 갱신(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단계 락킹

• 2단계 락킹(2 phase locking) 기법: 락을 걸고 해제하는 시점에 제한을 두지 않으면 두 개의 트랜잭션이 동시에 실행될 때 데이터의 일관성이 깨질 수 있어 이를 방지하는 방법.
  • 확장단계(Growing phase, Expanding phase) : 트랜잭션이 필요한 락을 획득하는 단계로, 이 단계에서는 이미 획득한 락을 해제하지 않음.
  • 수축단계(Shrinking phase) : 트랜잭션이 락을 해제하는 단계로, 이 단계에서는 새로운 락을 획득하지 않음.

락을 사용하되 2단계 락킹 기법을 사용하지 않아 문제가 발생한 경우

2단계 락킹 기법을 사용하여 문제 해결한 경우

데드락

• 데드락(deadlock) : 두 개 이상의 트랜잭션이 각각 자신의 데이터에 대하여 락을 획득하고 상대방 데이터에 대하여 락을 요청하면 무한 대기 상태에 빠질 수 있는 현상. 교착상태라고도 함.
• 일반적으로 데드락이 발생하면 DBMS는 T1 혹은 T2의 작업 중 하나를 강제로 중지시킴.
• 그 결과 나머지 트랜잭션은 정상적으로 실행됨. 이때 중지시키는 트랜잭션에서 변경한 데이터는 원래 상태로 되돌려 놓음.

트랜잭션 고립 수준

• T1은 읽고 T2는 쓰는 경우 발생하는 문제(트랜잭션 동시 실행 문제)

오손 읽기(dirty read)

• 읽기 작업을 하는 T1이 쓰기 작업을 하는 T2가 작업한 중간 데이터를 읽기 때문에 생기는 문제
• 작업 중인 T2가 어떤 이유에서 작업을 철회(ROLLBACK)할 경우 T1은 무효가 된 데이터를 읽게 되고 잘못된 결과를 도출하는 현상

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

• T1이 데이터를 읽고 T2가 데이터를 쓰고(갱신, UPDATE) T1이 다시 한번 데이터를 읽을 대 생기는 문제
• T1이 읽기 작업을 다시 한번 반복할 경우 이전의 결과와 다른 결과가 나오는 현상.
• 오손 읽기와 다르게 T2에서 정상 저장(COMMIT)되었기 때문에 틀린 데이터는 아니나 T1 입장에서는 같은 SQL 문이 다른 결과를 도출하게 된다.

유령 데이터 읽기(phantom read)

• T1이 데이터를 읽고 T2가 데이터를 쓰고(삽입, INSERT) T1이 다시 한번 데이터를 읽을 때 생기는 문제
• T1이 읽기 작업을 다시 한번 반복할 경우 이전에 없던 데이터(유령 데이터)가 나타나는 현상
• 반복 불가능 읽기와 마찬가지로 정상 저장(COMMIT)되었기 때문에 틀린 데이터는 아니지만 T1은 없던 데이터가 삽입되었기 때문에 SQL문이 다른 결과를 도출하게 된다.

트랜잭션 고립 수준 명령어

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

READ UNCOMMITED(Level = 0)

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

READ COMMITED(Level = 1)

• 오손 페이지의 참조를 피하기 위해 자신의 데이터를 읽는 동안 공유락을 걸지만 트랜잭션이 끝나기 전에라도 해지 가능함.

REPEATABLE READ(Level = 2)

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

SERIALIZABLE(Level = 3)

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

회복

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

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

• 시스템 충돌 : 하드웨어 혹은 소프트웨어의 오류로 인하여 주기억장치가 손실되는 것을 말한다. 주기억장치에 상주하여 처리 중인 프로그램과 데이터의 일부 혹은 전부가 손실된다.
• 미디어 장애 : 헤드의 충돌이나 읽기 장애에 의하여 보조기억장치의 일부 데이터가 손실되는 것을 말한다. 보조기억장치에 저장 중인 데이터의 일부 혹은 전부가 손실된다.
• 응용 소프트웨어 오류 : 데이터베이스에 접근하는 소프트웨어의 논리적인 오류로 트랜잭션의 수행이 실패하는 것을 말한다.
• 자연재해 : 화재, 홍수, 지진, 정전 등에 의해 컴퓨터 시스템이 손상되는 것을 말한다.
• 부주의 혹은 태업(sabotage) : 운영자나 사용자의 부주의로 데이터가 손실되거나 의도적인 손상을 입는 것을 말한다.

로그 파일

• DBMS는 트랜잭션이 수행 중이거나 수행이 종료된 후 발생하는 데이터베이스 손실을 방지하기 위해 트랜잭션의 데이터베이스 기록을 추적하는 로그 파일을 사용한다.
• 로그 파일은 트랜잭션이 반영한 모든 데이터의 변경사항을 데이터베이스에 기록하기 전에 미리 기록해 두는 별도의 데이터베이스이다.
• 안전한 하드디스크에 저장되며 전원과 관계없이 기록이 남아있다.
• <트랜잭션번호, 로그의 타입, 데이터 항목 이름, 수정 전 값, 수정 후 값> 형태로 로그 파일을 저장한다.

로그 파일을 이용한 회복

• 데이터의 변경 기록을 저장해 둔 로그 파일을 이용하면 시스템 장애도 복구할 수 있다.
• DBMS는 트랜잭션이 종료되었는지 혹은 중단되었는지 여부를 판단하여 종료된 트랜잭션은 종료를 확정하기 위해 재실행(REDO)을 진행하고, 중단된 트랜잭션은 없던 일로 되돌리기 위해 취소(UNDO)를 진행한다.

트랜잭션의 재실행 REDO

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

트랜잭션의 취소 UNDO

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

즉시 갱신 방법 immediate update

• 갱신 데이터 → 로그, 버퍼 → 데이터베이스 작업이 부분완료 전에 동시에 진행될 수 있으며, 부분완료가 되면 갱신 데이터는 로그에 기록이 끝난 상태

 

지연 갱신 방법 deffered update

• 갱신 데이터 → 로그 가 끝난 후 부분완료를 하고 버퍼→데이터베이스 작업이 진행되는 방법

체크포인트를 이용한 회복

• 로그를 이용한 회복은 시스템 장애가 일어났을 때 어느 시점까지 되돌아가야 하는지 알 수 없다.
• 트랜잭션이 많은 응용의 경우 하루 이상 되돌아가서 복구하는 것은 사실상 불가능하다,
• 회복 시 많은 양의 로그를 검색하고 갱신하는 시간을 줄이기 위하여 몇십 분 단위로 데이터베이스와 트랜잭션 로그 파일을 동기화한 후 동기화한 시점을 고르 파일에 기록해 두는 방법 혹은 그 시점을 체크포인트라고 한다.