Notice
Recent Posts
Recent Comments
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Archives
Today
Total
관리 메뉴

SYDev

[데이터베이스] 9장. 트랜잭션 본문

3학년 1학기 전공/데이터베이스

[데이터베이스] 9장. 트랜잭션

시데브 2024. 6. 18. 18:04
경희대학교 이영구 교수님의 데이터베이스 수업 복습용 게시물입니다.

 

9.1. 트랜잭션 개요

동시성 제어와 회복

동시성 제어(concurrency control)

  • 동시에 수행되는 트랜잭션들이 DB에 미치는 영향 -> 이들을 순차적으로 수행했을 때 데이터베이스에 미치는 영향과 같도록 보장
  • 다수 사용자가 DB에 동시에 접근하도록 허용하면서, DB의 일관성을 유지

회복(recovery)

  • 데이터베이스 갱신 도중 시스템이 고장나도 데이터베이스의 일관성을 유지

 

트랜잭션(transaction)

  • 데이터베이스 응용에서 하나의 논리적인 단위를 수행하는 데이터베이스 연산들의 모임 -> SQL문이 모인 형태(read 연산과 write 연산이 섞일 수 있음)
  • 데이터 객체(tuple, relation)들을 접근하고, 갱신도 하는 프로그램 수행의 단위

-> 이때 500명 전원의 급여 수정 or 한 명의 급여도 수정 X을 DBMS가 보장

-> 320번째 사원까지 수정한 상태에서 컴퓨터 시스템 다운된 경우? -> log를 유지해서 재기동 후에 어느 직원의 tuple까지 수정되었는지 정보를 유지해야 함

 

-> 첫 번째 UPDATE문이 수행되었으면, 두 번째 UPDATE문도 수행되는 것을 보장해야 함

-> 하나의 트랜잭션(단위)처럼 DBMS가 보장해야 함

 

  • 기본적으로 각각의 SQL문 -> 하나의 트랜잭션으로 취급
  • 두 개 이상의 SQL문들을 하나의 트랜잭션으로 취급하려면 -> 사용자가 이를 명시적으로 표시

 

-> if문이 충족되지 않으면, 트랜잭션 작업을 모두 취소하고 트랜잭션 종료, Abort

-> 트랜잭션 작업이 모두 정상적으로 수행되었으면, Commit

-> DBMS는 각 SQL문의 의미를 알 수 없으므로, 하나의 트랜잭션으로 취급해야 하는 SQL문들의 범위를 사용자가 명시적으로 표시

1. FLIGHT의 SEAT_SOLD, CAPACITY를 temp1, temp2로 저장
2. 팔린 좌석 수와 총 좌석의 수가 같으면 트랜잭션 종료
3. else일 시에, SEAT_SOLD 1 증가
4. RESERVED 테이블에 예약한 유저 정보 삽입

 

트랜잭션의 특성(ACID 특성)

원자성(Atomicity)

  • 한 트랜잭션 내의 모든 연산들이 완전히 수행되거나 전혀 수행되지 않음을 의미 -> all or nothing 
  • DBMS의 회복 모듈 - 시스템이 다운되는 경우 -> 부분적으로 DB를 갱신한 트랜잭션의 영향을 취소 -> 트랜잭션의 원자성 보장
  • 완료된 트랜잭션이 갱신한 사항 -> 트랜잭션의 영향을 재수행 -> 트랜잭션의 원자성 보장

 

일관성(Consistency)

  • 어떤 트랜잭션 수행되기 전 DB가 일관된 상태를 가졌다면 -> 트랜잭션 수행된 후에 DB는 또 다른 일관된 상태를 가짐
  • 트랜잭션 수행 도중 일시적으로 일관성이 깨질 수 있음

 

고립성(Isolation)

  • 한 트랜잭션이 데이터를 갱신 -> 트랜잭션이 완료되기 전에는 갱신 중인 데이터를 다른 트랜잭션들이 접근하지 못하도록 해야 함
  • 다수의 트랜잭션 동시 수행 -> 그 결과는 어떤 순서에 따라 트랜잭션들을 하나씩 차례대로 수행한 결과와 같아야 함
  • DBMS의 동시성 제어 모듈 -> 트랜잭션의 고립성 보장
  • DBMS는 응용들의 요구사항에 따라 -> 다양한 고립 수준(isolation level)을 제공

 

지속성(Durability)

  • 일단 트랜잭션이 완료되면 -> 이 트랜잭션이 갱신한 것은 후에 시스템 고장 발생해도 -> 손상 X
  • DBMS 회복 모듈 - 시스템 다운되는 경우에도 -> 트랜잭션 지속성 보장

 

트랜잭션의 완료(Commit)

  • 트랜잭션에서 변경하려는 내용 -> DB에 완전하게 반영
  • SQL 구문상으로 COMMIT WORK
  • DBMS의 트랜잭션 관리 모듈에 알리는 사항: 트랜잭션의 성공적 종료, DB는 새로운 일관된 상태를 가짐, 트랜잭션이 수행한 갱신을 DB에 반영해야 함

 

트랜잭션의 철회(Abort)

  • 트랜잭션에서 변경하려는 내용이 DB에 일부만 반영된 경우 -> 원자성 보장을 위해서 -> 트랜잭션이 수행되기 전의 상태로 되돌림
  • SQL 구문 상으로 ROLLBACK WORK
  • DBMS의 트랜잭션 관리 모듈에 알리는 사항: 트랜잭션의 일부를 성공적으로 끝내지 못함, DB가 불일치 상태를 가질 수 있음, DB에 반영된 트랜잭션의 갱신 취소해야 함

 

트랜잭션이 성공하지 못하는 원인

  • 시스템(사이트) 고장: CPU, Memory, Power supply(전원 공급 장치) 등의 고장
  • 트랜잭션 고장: 트랜잭션이 수행되는 도중 철회
  • 매체 고장: 저장 장치의 고장 -> 저장 장치의 데이터에 액세스하지 못하는 경우, Disk head, Disk controller 등이 고장 -> 보조 기억 장치의 전부/일부 내용이 지워짐
  • 통신 고장
  • 자연적 재해
  • 부주의 또는 고의적 고장

 

9.2. 동시성 제어

동시성 제어

  • 여러 사용자들이 동시에 동일한 테이블 접근 -> DBMS의 성능 향상을 위해 -> 여러 사용자의 질의나 프로그램들을 동시에 수행하는 것이 필수적
  • 동시성 제어 기법 -> 여러 사용자들이 다수의 트랜재션을 동시에 수행하는 환경에서, 트랜잭션들 간의 간섭이 생기지 않도록 함

 

직렬 스케줄(serial schedule)

  • 여러 트랜잭션들의 집합을 한 번에 한 트랜잭션씩 차례대로 수행
T1: 011, 012, 013
T2: 021, 022

1. T1 -> T2: 011, 012, 013, 021, 022
2. T2 -> T1: ...

n개의 트랜잭션: n!

비직렬 스케줄(non-serial schedule)

  • 여러 트랜잭션들을 동시에 수행
T1: 011, 012, 013
T2: 021, 022

- 011, 012, 021, 013, 022
- 021, 011, 022, 012, 013
-> 섞이긴 섞이더라도, 같은 트랜잭션 내의 순서는 유지

n개의 트랜잭션 연산 수가 각각 m_1, ..., m_n

(m1 + m2 + ... + mn)! / m1!m2!..mn!
-> 직렬 스케줄의 경우의 수 보다 압도적으로 많다.

DB를 일관되게 하는 비직렬 스케줄과 직렬 스케줄만 수행되도록 하는 것 -> 동시성 제어

직렬가능(serializable)

  • 비직렬 스케줄의 결과가 -> 어떤 직렬 스케줄의 수행 결과와 동등(equivalent)
충돌(conflict)에 기반한 equivalent

충돌 -> write 연산이 하나라도 포함된 두 개의 연산은 문제를 일으킬 수 있다. -> read/write, write/write

 

 

데이터베이스 연산

  • Input(X): 데이터베이스 항목 X를 포함하고 있는 Block을 주기억 장치의 버퍼로 읽어들임
  • Output(X): 데이터베이스 항목 X를 포함하고 있는 Block을 디스크에 기록
  • read_item(X): 주기억 장치 버퍼에서 데이터베이스 항목 X의 값을 프로그램 변수 X로 복사함
  • write_item(X)프로그램 변수 X의 값을 주기억 장치 내의 데이터베이스 항목 X에 기록

 

동시성 제어를 하지 않고, 다수의 트랜잭션을 동시에 수행할 때 발생할 수 있는 문제

  • 갱신 손실(lost update): 수행 중인 트랜잭션이 갱신한 내용다른 트랜잭션이 덮어씀-> 갱신 무효
  • 오손 데이터 읽기(dirty read)완료되지 않은 트랜잭션이 갱신한 데이터를 읽는 것
  • 반복할 수 없는 읽기(unrepeatable read): 한 트랜잭션이 동일한 데이터를 두 번 읽을 때 -> 서로 다른 값 

 

-> T1에서 적용된 연산을 write_item으로 적용하기 전 X를 T2에서 read_item으로 읽어와서 문제가 발생

 

-> T1의 변화는 ROLLBACK되었으나, 해당 변화를 반영한 값을 T2에서는 그대로 사용하기에 문제가 발생한다.

 

-> 동일한 연산을 반복하는데, 두 연산의 결과가 다른 경우

 

9.1 절의 항공기 예약 트랜잭션

  • 동일한 날짜에 출발하는 항공기의 빈 좌석 유무를 여러 고객이 동시에 수행할 경우
  • SQL문 (1)의 수행 결과로 특정 항공기에 빈 좌석이 1개 남아 있다는 사실 확인 -> 동시에 SQL (2)와 (3)을 수행하여 팔린 좌석 수를 1씩 증가 -> 자신의 고객 정보를 항공사 DB에 입력 -> 이때 DBMS가 아무런 조치를 취하지 않으면 -> 1개 남은 좌석에 2명의 고객이 배정됨

 

 

로킹(locking)

  • 로크(lock): DB 내의 각 데이터 항목과 연관된 하나의 변수
  • 각 트랜잭션이 수행을 시작 -> 데이터 항목에 접근할 때마다 요청한 lock에 관한 정보 -> 로크 테이블(lock table) 등에 유지됨
  • 트랜잭션에서 데이터 항목에 접근할 때 -> lock 요청 
  • 접근을 끝낸 후 -> lock 해제(unlock)
  • 갱신 목적 접근: 독점 로크(X-lock, eXclusive lock)를 요청
  • 판독(읽기) 목적 접근: 공유 로크(S-lock, Shared lock)를 요청