트랜잭션

트랜잭션 개요

트랜잭션관리란 동시성제어와 회복을 하는 것~!

트랜잭션

항공기 예약, 은행, 신용카드 처리, 대형 할인점 등에서는 대규모 데베를 수천명이상의 사용자들이 동시에 접근함

많은 사용자들이 동시에 데베의 서로다른 부분 또는 동일한 부분을 접근하면서 데베를 사용함

 

동시성제어란 (concurrency control) 

동시에 수행되는 트랜잭션들이 데베에 미치는 영향은 이들을 순차적으로 수행했을때 데베에 미치는 영향과 같도록

보장. (고립성)

다수의 사용자가 데베를 동시에 접근하도록 허용하면서

데베의 일관성을 유지함

 

회복 (Recovery)

데베를 갱신하는 도중에 시스템이 고장나도

데베의 일관성을 유지함 

 

(dbms 가 추가로 정보를 유지하지않는다면 dbms가 재기동된후 어느직원의 투플까지 수정되었는가를 알 수 없음 -> 로그 유지)

update customer

set balance = balance - 1000;

where cust_name = '정미림'

 

update customer

set balance = balance + 1000;

where cust_name = '정미림'

 

첫번째 update문을 수행한 후 두번째 update문을 수행하기 전에 컴퓨터가 다운되면 재기동한 후에 dbms가 어떻게 대응할까?

위의 두개 update 문 둘다 완전하게 수행되거나 한 update문도 실행되어서는 안된다. 즉 하나의 트랜잭션(단위)처럼 dbms가 보장해야 한다.

기본적으로 각각의 sql문이 하나의 트랜잭션으로 취급됨

두개이상의 sql 문들을 하나의 트랜잭션으로 취급하려면 사용자가 이를 명시적으로 표시해야 함

고객의 요청에 따른 항공기 예약 서비스~!

 DBMS는 3개의 SQL문들을 하나의 트랜잭션으로 취급하려면 사용자가 이를 명시적으로 표시해야 함

트랜잭션 특성(ACID)

원자성 atomicity (회복) 회원

한 트랜잭션 내의 모든 연산들이 완전히 수행되거나 전혀 수행되지않음 (all or nothing)

DBMS의 회복모듈은 시스템이 다운되는 경우에 부분적으로 데베를 갱신한 트랜잭션의 영향을 취소함으로써 트랜잭션의 원자성을 보장함

완료된 트랜잭션이 갱신한 사항은 트랜잭션의 영향을 재수행함으로써 트랜잭션의 원자성을 보장함

 

일관성 consistency (무결성 제약조건 , 동시성 제어) 무일동

어떤 트랜잭션이 수행되기전에 데베가 일관된 상태를 가졌다면 트랜잭션이 수행된 후에 데베는 또 다른 일관된 상태를 가짐 

트랜잭션이 수행되는 도중에는 데베가 일시적으로 일관된 상태를 갖지 않을 수 있음

 

 

고립성 isolation (동시성 제어)  똥고

한 트랜잭션이 데이터를 갱신하는 동안 이 트랜잭션이 완료되기 전에는 갱신중인 데이터를 다른 트랜잭션들이 접근하지 못하도록 해야 함

다수의 트랜잭션들이 동시에 수행되더라도 그 결과는 어떤 순서에 따라 트랜잭션들을 하나씩 차례대로 수행한 결과와 같아야  함...

DBMS 의 동시성 제어 모듈이 트랜잭션의 고립성을 보장함

DBMS는  응용들의 요구사항에 따라 다양한 고립 수준(level)을 제공함

 

 

 

지속성 durability (회복) 복지

일단 한 트랜잭션이 완료되면 이 트랜잭션이 갱신한 것은 그 후에 시스템에 고장이 발생하더라도 손실되지않음

완료된 트랜잭션의 효과는 시스템이 고장난 경우에도 데베에 반영됨

DBMS의 회복 모듈은 시스템이 다운되는 경우에도 트랜잭션의 지속성을 보장함.

 

트랜잭션의 완료 commit

트랜잭션에서 변경하려는 내용이 데베에 완전하게 반영됨

SQL구문상으로 COMMIT WORK

 

트랜잭션의 철회 abort

트랜잭션에서 변경하려는 내용이 데베에 일부만 반영된 경우에는 원자성을 보장하기위해서 트랜잭션이 갱신한 사항을 트랜잭션이 수행되기 전의 상태로 되돌림

SQL구문상으로 ROLLBACK WORK

데베(디스크)일껄?

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

1. 시스템 (사이트) 고장, 주기억장치 중앙처리장치 전원 공급장치 등이 고장

2. 트랜잭션 고장 (근데 트랜잭션 수행도중 철회되긴 함)

3. 매체 고장, 디스크 헤드 , 디스크 콘트롤러 등이 고장나서 보조기억장치의 전부 또는 일부내용이 지워짐

4. 통신 고장

5. 자연재해

6. 부주의 , 고의적 고장

동시성 제어 

대부분의 DBMS들은 다수 사용자용 = 여러 사용자들이 동시에 동일한 테이블을 접근하기도 함

DBMS 성능을 높이기 위해 여러 사용자의 질의나 프로그램들을 동시에 수행하는 것이 필수적

동시성 제어 기법은 여러 사용자들이 다수의 트랜잭션들을 동시에 수행하는 환경에서 부정확한 결과를 생성할 수 있는 트랜잭션들 간의 간섭이 생기지 않도록 함. 

 

직렬 스케줄 serial schedule

여러 트랜잭션들의 집합을 한번에 한 트랜잭션씩 수행

 

비직렬 스케줄 non serial schedule

여러트랜잭션을 동시에 수행

 

직렬가능 serializable

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

 

데베 연산

input(X) : 데베 항목 X를 포함하고 있는 블록을 주기억장치의 버퍼로 읽어들임 (디스크 -> 주기억장치)

output(X) : 데베 항목 X를 포함하고 있는 블록을 디스크에 기록함 (주기억장치 -> 디스크)

read_item(X) : 주기억장치 버퍼에서 데베 항목 X의 값을 프로그램 변수 X로 복사함 (주기억장치 -> 응용프로그램)

write_item(X) : 프로그램 변수 X값을 주기억장치 내의 데베 항목 X에 기록함 (응용프로그램 -> 주기억장치)

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

1. 갱신 손실 (lost update)

수행중인 트랜잭셔인 갱신한 내용을 다른 트랜잭션이 덮어 씀으로써 갱신이 무효가 되는 것 

 

갱신 손실(Lost Update)은 여러 트랜잭션이 같은 데이터를 동시에 갱신할 때, 한 트랜잭션의 갱신 내용이 다른 트랜잭션의 갱신 내용에 의해 덮어씌워져 무효화되는 현상입니다. 주로 동시성 제어가 제대로 이루어지지 않은 경우에 발생합니다.

주어진 예를 상황에 따라 정리하면 다음과 같습니다.

---

1. 문제 상황 정리

1. T1과 T2가 동시에 시작:
   • 변수 xx와 yy를 각각 갱신하는 작업이 포함됨.
2. 갱신 순서 및 값:
   • T1: x=30, y=60
   • T2: x=35, y=70
3. 갱신 손실 발생:
   • T1과 T2가 서로의 갱신 내용을 덮어쓰는 상황.

---

2. 상세 수행 과정

초기 값:

• x=25, y=70

수행 순서 (동시 발생):

1. T1: x = 30으로 갱신
   (T1이 xx를 수정한 상태)
2. T2: x = 35으로 갱신
   (T2가 xx를 수정하면서 T1의 갱신이 덮어씌워짐 → 갱신 손실 발생)
3. T1: y = 60으로 갱신
   (T1이 yy를 수정한 상태)
4. T2: y = 70으로 갱신
   (T2가 yy를 수정하면서 T1의 갱신이 덮어씌워짐 → 갱신 손실 발생)

---

3. 최종 상태

• x=35x = 35 (T1의 갱신은 손실됨)
• y=70y = 70 (T1의 갱신은 손실됨)

---

4. 해결 방안

갱신 손실 문제를 방지하기 위해서는 동시성 제어 기법을 사용해야 합니다.

동시성 제어 기법:

1. 로킹(Locking):
   • T1이 xx를 갱신하는 동안 T2가 xx에 접근하지 못하도록 배타적 로킹(Exclusive Lock) 사용.
2. 격리 수준 설정:
   • 트랜잭션의 격리 수준을 Serializable로 설정하여 순차적으로 처리되도록 보장.
3. 타임스탬프 관리:
   • 트랜잭션 시작 시간을 기반으로 충돌을 감지하고, 더 늦게 시작한 트랜잭션을 롤백.

---

5. 수정 후 동작 예시

수행 과정 (로킹 적용):

1. T1: x = 30으로 갱신 → xx에 배타적 로크 설정
2. T2: x = 35 시도 → T1의 작업 완료 후 실행 가능
3. T1: y = 60으로 갱신 → yy에 배타적 로크 설정
4. T2: y = 70 시도 → T1의 작업 완료 후 실행 가능

최종 상태 (로킹 적용 후):

• x = 35 (T1과 T2 모두 반영 가능)
• y = 70 (T1과 T2 모두 반영 가능)

---

 

2. 오손 데이터 읽기 (dirty read)

완료되지않은 트랜잭션이 갱신한 데이터를 읽는 것 

update account 

set balance = balance - 100000

where cust_name = '정미림'

 

select avg(balance)

from account;

 

ROLLBACK;

 

COMMIT;

T1이 어떤 이유로 철회되면 T1이 갱신한 정미림 계좌의 잔액은 원래 상태로 되돌아간다.

 

 

3. 반복할 수 없는 읽기 (unrepeatable read)

한 트랜잭션이 동일한 데이터를 두번 읽을때 서로 다른 값을 읽는 것

트랜잭션 T2가 완료되기 전에 트랜잭션 T1이 정미림의 잔액을 100000원 감소시키고 완료되었다.

 

select avg(balance)

from account;

 

update account 

set balance = balance - 100000

where cust_name = '정미림'

commit;

 

select avg(balance)

from account;

 

 

로킹(locking)

for 트랜잭션들의 동시성을 제어하기위해서~!

로크는 데베내의 각 데이터 항목과 연관된 하나의 변수

각 트랜잭션이 수행을 시작해 데이터 항목을 접근할때마다 요청한 로크에 관한 정보는 로크테이블 등에 유지됨

1. 트랜잭션에서 갱신을 목적으로 데이터 항목을 접근할때는 독점 로크 (X-lock, exclusive lock)를 요청함

2. 트랜잭션에서 읽을 목적으로 데이터 항목을 접근할때는 공유로크 (S-lock, shared)를 요청함

3. 트랜잭션이 데이터항목에 대한 접근을 끝낸 후에 로크를 해제함 (unlock)

 

현재 걸린 로크가 공유로크일 경우만 공유로크를 요청받았을때 허용! & 현재 로크가 걸리지않은 상태라면 공유든 독점이든 다 허용!

2단계 로킹 프로토콜 2 phase locking protocol

로크를 요청하는 것과 로크를 해제하는 것이 2단계로 이루어짐

로크 확장 단계가 지난 후에 로크 수축단계에 들어감

일단 로크를 한개라도 해제하면 로크 수축단계에 들어감

 

a =3 b=3 일때 a= 8 b=7로 문제가 발생...단순히 락으로만은  해결 불가능

로크확장단계 (1단계) 

로크 확장단계에서는 트랜잭션이 데이터 항목에 대하여 새로운 로크를 요청할 수 있지만 보유하고 있던 로크를 하나라도 해제할 수 없음

 

로크수축단계(2단계)

로크 수축단계에서는 보유하고 있던 로크를 해제할 수 있지만 새로운 로크를 요청할 수 없음

로크 수축단계에서는 로크를 조금씩 해제할 수도 있고 

트랜잭션 완료시점에 이르렀을 때 한꺼번에 모든 로크를 해제할 수도 있음

일반적으로 한꺼번에 모든 로크를 해제하는 방식이 사용됨

 

로크포인트(lock - point) 

한 트랜잭션에서 필요로 하는 모든 로크를 걸어 놓은 시점

 

2단계 로킹 프로토콜 지키기~!

데드록 (Deadlock)

데드록은 두 개 이상의 트랜잭션이 서로 자원을 점유한 상태에서, 상대방이 점유한 자원을 요청하며 대기하게 되어 영원히 작업이 진행되지 않는 상태를 말합니다.

• 예시:
  트랜잭션 T1이 데이터 A를 점유하고 데이터 B를 요청하며 대기하고, 동시에 트랜잭션 T2가 데이터 B를 점유하고 데이터 A를 요청하며 대기할 때 발생합니다.
• 해결 방안:
  • 예방(Prevention): 데드록 발생 조건을 사전에 방지하는 기법. (예: 자원 요청 순서 제한)
  • 회피(Avoidance): 자원 할당 그래프를 사용해 데드록 가능성을 예측하고 회피.
  • 탐지(Detection) 및 복구(Recovery): 데드록 발생을 탐지한 후 트랜잭션을 중단하거나 롤백하여 복구.

---

다중 로크 단위 (Granularity of Locks)

다중 로크 단위는 데이터베이스에서 로크의 적용 범위를 다양하게 설정하여 동시성 제어를 최적화하는 기법입니다.

• 로크 크기(단위):
  • 데이터베이스 전체
  • 테이블
  • 페이지(블록)
  • 레코드(행)
  • 필드(컬럼)
• 장단점:
  • 큰 단위: 관리 비용이 적지만 동시성 감소.
  • 작은 단위: 동시성 증가하지만 관리 비용 상승.
• 적용 방법: 트랜잭션이 어떤 단위를 로크할지 결정하고, 이를 관리하기 위해 다단계 로크를 사용하기도 함.

---

팬텀 문제 (Phantom Problem)

팬텀 문제는 트랜잭션이 범위 쿼리를 수행할 때, 다른 트랜잭션의 삽입으로 인해 범위 내 데이터가 변경되는 현상입니다.

• 예시:
  T1이 특정 범위의 데이터를 읽고 실행 중인데, T2가 그 범위 내 새로운 데이터를 삽입하면 T1의 데이터 일관성이 깨짐.
• 해결 방법:
  • 키-범위 로킹(Key-Range Locking): 범위 내 데이터뿐만 아니라 범위 자체에 대한 로킹을 설정.
  • Serializable Isolation Level: 팬텀 문제를 방지하기 위해 격리 수준을 높임.

---

회복 (Recovery)

회복은 데이터베이스가 고장(failure) 후에도 데이터 무결성을 유지하고 일관된 상태로 복원하는 과정입니다.

회복의 주요 목표

1. 일관성 유지: 트랜잭션의 원자성(atomicity) 보장.
2. 내구성 유지: 커밋된 데이터는 고장 후에도 손실되지 않음.

---

로그를 사용한 즉시 갱신 (Immediate Update Using Logs)

즉시 갱신은 트랜잭션의 변경 사항을 즉시 데이터베이스에 반영하는 방식으로, 회복 시 로그를 사용해 트랜잭션 상태를 복원합니다.

• 방식:
  1. 트랜잭션이 변경 사항을 데이터베이스에 기록.
  2. UNDO/REDO 로그 기록:
     • UNDO: 트랜잭션 취소를 위해 이전 값을 기록.
     • REDO: 트랜잭션 복구를 위해 변경 후 값을 기록.
  3. 고장이 발생하면 로그를 읽어 복구.
• 장점:
  • 데이터베이스와 로그의 즉시 일관성 유지 가능.
• 단점:
  • 로그 기록으로 인한 성능 저하.

---

데이터베이스 백업과 재해적 고장으로부터의 회복

데이터베이스의 재해 복구는 시스템 고장이나 자연재해와 같은 중대한 사고 후 데이터를 복구하기 위한 방법입니다.

주요 전략

1. 백업 (Backup):
   • 데이터베이스 전체를 주기적으로 백업.
   • 종류:
     • 전체 백업: 데이터베이스의 전체 복사.
     • 증분 백업: 변경된 데이터만 복사.
     • 차등 백업: 가장 최근 전체 백업 이후 변경된 데이터 복사.
2. 아카이브 로그 (Archived Logs):
   • 트랜잭션 로그를 주기적으로 저장.
   • 데이터베이스 복구 시 백업 파일과 로그를 조합해 사용.
3. 재해 복구 (Disaster Recovery):
   • 주기적 테스트: 복구 절차를 정기적으로 검증.
   • 다중 위치 저장소: 원격 서버에 데이터를 복제.
   • Failover 시스템: 고장 시 자동으로 대체 서버로 전환.

복구 과정

1. 백업 데이터 복구: 가장 최근 백업 데이터로 복원.
2. 로그 재적용: 백업 이후 로그를 적용해 데이터 복구.
   • UNDO/REDO 로그를 사용해 트랜잭션 상태 복구.
3. 검증: 데이터 일관성과 무결성을 확인.