25.04.02 트랜잭션

트랜잭션 - DBMS에서 데이터를 다루는 논리적인 작업 단위 (여러개 읽기/쓰기를 논리적으로 하나로 묶음)

DB에서 쓰는 이유

▪ DB 장애 발생 시 데이터 복구하는 단위

▪ DB에 동시 작업 시 작업을 분리하는 단위

 

과정

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

성질

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

   성공 or 실패만 존재 (부분이 없음)

일관성(consistency) - 트랜잭션 수행 전이나 후에 데이터베이스는 항상 일관된 상태를 유지해야 함

   시스템이 가지고 있는 고정요소는 트랜잭션 수행 전/후 같아야 함

고립성(isolation) - 수행 중인 트랜잭션에 동시 작업이 생겨 방해 받아 데이터가 훼손되면 안됨

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

 

원자성

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

일부만 수행되면 안됨(all or nothing)

tcl 명령어

고립성

db는 공유가 목적이므로 여러 트랜잭션이 동시에 수행되는데 서로 독립적으로 간섭받지 않아야 함

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

> 동시성 제어

 

지속성

트랜잭션이 정상적으로 완료 혹은 부분완료한 데이터를 db에 기록하는 성질

 

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

 

동시성 제어

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

사용자들이 다수의 트랜잭션을 동시에 수행하는 환경에서 부정확한 결과를 생성할 수 있는 트랜잭션 간 간섭이 없도록 함

읽기:읽기 > 동시접근 허용

읽기:쓰기 > 오손읽기, 반복 불가능, 유령데이터 읽기 발생 > 허용 또는 불가

쓰기:쓰기 > 갱신손실 발생 > 허용불가(lock 이용)

 

갱신손실

두개의 트랜잭션이 한 개의 데이터를 동시에 갱신할 때 발생

 

락

갱신손실 사전 방지 > 데이터를 수정 중이라는 사실을 알리는 방법

트랜잭션이 다루는 데이터를 다른 트랜잭션이 접근하지 못하도록 막아 대기상태로 둠

 

공유락 - 트랙잭션이 읽기 할 때 사용함

배타락 - 읽기/쓰기 할 때 사용함

규칙

▪ 데이터에 락이 걸려있지 않으면 트랜잭션은 데이터에 락을 걸 수 있다.
▪ 트랜잭션이 데이터 X를 읽기만 할 경우 LS(X)를 요청하고, 읽거나 쓰기를 할 경우 LX(X)를 요청한다.
▪ 다른 트랜잭션이 데이터에 LS(X)을 걸어둔 경우, LS(X)의 요청은 허용하고 LX(X)는 허용하지 않는다.
▪ 다른 트랜잭션이 데이터에 LX(X)을 걸어둔 경우, LS(X)와 LX(X) 모두 허용하지 않는다.
▪ 트랜잭션이 락을 허용받지 못하면 대기 상태가 된다.

 

2단계 락킹

락을 걸고 해제하는 시점에 제한 두지 않으면 두개의 트랜잭션이 동시에 실행될 때 데이터 일관성 깨짐 방지

▪ 확장단계 - 트랜잭션이 필요한 락을 획득하는 단계로,이미 획득한 락을 해제하지 않음
▪ 수축단계 - 트랜잭션이 락을 해제하는 단계로, 이 단계에서는 새로운 락을 획득하지 않음

 

데드락

두 개 이상의 트랜잭션이 각각 자신의 데이터에 대해 락 획득하고 상대방 데이터에 락 요청 시 무한 대기 상태

>교착상태 (서로 락 해제하길 기다림)

>해결방법 - 둘 중 하나를 강제 중지시킴(변경한 데이터는 원래 상태로 되돌림)

 

오손읽기 - 결과값이 상이한 현상

변경 후 아직 커밋되지 않는 데이터를 읽고 롤백 후 값을 다시 읽어 발생함

 

 

반복불가능 읽기 - 트랜잭션이 읽기 작업을 다시 한번 반복할 경우 이전의 결과가 반복되지 않는 현상

반복불가능 읽기(non-repeatable read)
• 트랜잭션 1이 데이터를 읽고 트랜잭션 2가 데이터를 쓰고(갱신, UPDATE)

트랜잭션 1이 다시 한 번 데이터를 읽을 때 생기는 문제
• 트랜잭션 1이 읽기 작업을 다시 한 번 반복할 경우 이전의 결과와 다른 결과가 나오는 현상

 

■ [작업 설명] 두 개의 트랜잭션을 동시에 실행
▪ 트랜잭션 T1, T2가 동시에 실행됨
▪ T1은 읽기만 하고 T2는 쓰기(갱신, UPDATE)를 함
▪ T1은 데이터를 읽고 작업을 한 후, T2가 변경한 데이터를 다시 한 번 읽어와 작업을 함

■ [문제 발생] 반복불가능 읽기
▪ T1이 데이터를 읽고 작업하던 중 T2가 데이터를 변경함
▪ T1은 변경한 데이터를 보고 다시 한 번 작업을 함
▪ 오손 읽기와 달리 이번에는 T2가 COMMIT을 했기 때문에 틀린 데이터는 아님
▪ T1 입장에서는 같은 SQL 문이 다른 결과를 도출한다.

 

 

유령데이터 읽기(phantom read)
• 트랜잭션 1이 데이터를 읽고 트랜잭션 2가 데이터를 쓰고(삽입) 트랜잭션 1이 다시 한 번 데이
터를 읽을 때 생기는 문제
• 트랜잭션 1이 읽기 작업을 다시 한 번 반복할 경우 이전에 없던 데이터(유령 데이터)가 나타나는 현상

■ [작업 설명] 두 개의 트랜잭션을 동시에 실행
▪ 트랜잭션 T1은 읽기만 하고 T2는 쓰기(삽입, INSERT)를 함
▪ T1은 데이터를 읽고 작업을 한 후, T2가 변경한 데이터를 다시 한 번 읽어와 작업을 함

■ [문제 발생] 유령데이터 읽기
▪ T1이 T2가 새로운 데이터를 삽입한 사실을 모르고 작업을 함
▪ T2가 COMMIT을 했기 때문에 틀린 데이터는 아님
▪ 그러나 T1 입장에서는 새로운 데이터가 반영되어 반복불가능 읽기와 마찬가지로 같은 SQL 문이 다른 결과를 도출함
▪ 유령데이터 읽기는 반복불가능 읽기와 비슷하지만 없던 데이터가 삽입되었기 때문에 다르게 구분함

READ UNCOMMITTED(Level = 0) : 트랜잭션이 커밋되지 않은 데이터를 다른 트랜잭션 read 허용

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

 

모드  | READ UNCOMMITTED
LOCK 

  SELECT 문 - 공유락 걸지 않음
   UPDATE 문 - 배타락 설정
   다른 트랜잭션의 공유락과 배타락이 걸린 데이터를 읽음
SQL 문 | SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
문제점  | 오손 읽기, 반복불가능 읽기, 유령데이터 읽기

 

READ COMMITTED(Level=1) - 트랜잭션이 커밋되어 확정된데이터만 읽는 것을 허용

오손(dirty) 페이지의 참조를 피하기 위해 자신의 데이터를 읽는 동안 공유락을 걸지만 

트랜잭션이 끝나기 전에라도 해지 가능함

 

모드 | READ COMMITTED
LOCK
   SELECT 문 - 공유락을 걸고 끝나면 바로 해지
   UPDATE 문 - 배타락 설정
   다른 트랜잭션이 설정한 공유락은 읽지만 배타락은 읽지 못함
SQL문 | SET TRANSACTION ISOLATION LEVEL READ COMMITTED
문제점 | 반복불가능 읽기, 유령데이터 읽기

 

REPEATABLE READ(Level=2) - 선행 트랜잭션이 읽은 데이터를 종료시까지 갱신/삭제 불허

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

 

모드 | REPEATABLE READ
LOCK
   SELECT 문 - 공유락을 걸고 트랜잭션을 끝까지 유지
   UPDATE 문 - 배타락 설정
   다른 트랜잭션이 설정한 공유락은 읽지만 배타락은 읽지 못함
SQL문 | SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
문제점 | 유령데이터 읽기

 

SERIALIZABLE(Level=3) – Index에 공유 Lock설정하여 다른 트랜잭션의 INSERT문까지 금지

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

 

모드 | SERIALIZABLE
LOCK
   SELECT 문 - 공유락을 걸고 트랜잭션을 끝까지 유지
   UPDATE 문 - 배타락 설정
   다른 트랜잭션이 설정한 공유락은 읽지만 배타락은 읽지 못함
   인덱스에 공유락을 설정하여 다른 트랜잭션의 INSERT 문이 금지됨
SQL문 | SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
문제점 | 없음

 

 

 

회복

데이터베이스에 장애 발생 시 데이터베이스를 일관성 있는 상태로 되돌리는 dbms 기능

db 손상 시 손상 이전의 정상 상태로 복구하는 작업

 

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

 

중복저장 기법 - dbms는 데이터베이스에 포함된 정보를 시스템 내 별도로 중복 저장하고 장애 발생 시 해당 정보로 회복함

   dackup - 다른 하드디스크에 데이터베이스 주기적으로 저장

   dump - 데이터 자체의 복사본

   log - 트랜잭션 별 연산 이전, 이후의 값을 저장

방법

▪  dump 이용 - 그림자 기법 : 원본의 그림자인 복사본으로 덮어 원본 복구

▪  log 이용 - 데이터베이스에 있는 값을 검사해 회복

 

로그파일

트랜잭션이 수행 중이거나 수행 종료된 후 발생한 데이터베이스 손실 방지 위해 트랜잭션의 기록 추적하는 로그파일 사용

 

로그파일 - 트랜잭션이 반영한 모든 데이터 변경사항을 db에 기록하기 전 미리 기록해두는 별도의 db

   하드디스크에 저장되면 전원과 관계없이 남아있음

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

로그타입 - 트랜잭션 연산 타입 (insert, start, update, delete, abort, commit 등 )

 

장애 발생 후 시스템 재가동 > 트랜잭션 종료 여부 판단

> 종료된 트랜잭션 - 종료 확정 위해 재실행(redo) 진행

> 중단된 트랜잭션 - 되돌리기 위해 취소(undo) 진행 

 

redo 

로그 파일에 트랜잭션 시작(START)이 있고 종료(COMMIT) 가 있는 경우

COMMIT 연산이 로그에 있다는 것은 트랜잭션이 모두 완료되었다는 의미

다만 변경 내용 이 버퍼에서 데이터베이스에 기록되지 않았을 가능성이 있음

 

undo

로그 파일에 트랜잭션의 시작(START)만 있고 종료(COMMIT)가 없는 경우

COMMIT 연산이 로그에 보이지 않는다는 것은 트랜잭션이 완료되지 못했다는 의미로 트랜잭션이 한 일을 모두 취소

완료하지 못했지만 버퍼의 변경 내용이 데이터베이스에 기록되어 있을 가능성이 있기 때문에 

로그를 보면서 트랜잭션이 변경한 내용을 데이터베이스에서 원상복구시켜야 함

 

즉시 갱신 방법

갱신 데이터 > 로그 / 버퍼 > 데이터베이스  작업이 부분완료 전 동시 진행 가능 (부분완료 시 갱신데이터 로그 기록 끝)

 

지연 갱신 방법

갱신 데이터 > 로그 > 부분완료 >  버퍼 > 데이터베이스   작업 진행

 

로그 회복은 시점이 명확하지 않음 > 트랜잭션 많을 수록 시점을 기준으로 복구 힘듦

 

체크포인트(검사점)

회복 시 많은 양의 로그를 검색 및 갱신 시간 줄이기 위해 트랜잭션 로그 파일 동기화

> 동기화 한 시점을 로그파일에 기록 

 

작업 순서

▪ 주기억장치의 로그 레코드를 모두 하드디스크의 로그 파일에 저장
▪ 버퍼에 있는 변경된 내용을 하드디스크의 데이터베이스에 저장
▪ 체크포인트를 로그 파일에 표시

 

체크포인트 + 로그 회복

체크포인트 이전 commit 기록 - 로그에 체크포인트 나타나는 시점 = 변경 내용이 db에 기록된 이후

체크포인트 이후 commit 기록 - redo 진행 (변경 내용이 db 기록 미반영)

체크포인트 이후 commit  없음 - undo 진행 

 

백업 - db에서 예상 못한 장애에 대비해 db 복제해 보관하는 작업

복원 - 장애 발생 해 운영중인 데이터 손상 발생 해 기존 복사해 둔 파일 사용해 복구