본문 바로가기
Database

9. 트랜잭션

by leko 2023. 6. 1.

트랜잭션 개요

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

트랜잭션

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

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

 

동시성제어란 (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)

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

T1 -> T2 : 25 70 

T2-> T1 : 25 70

but

변 x = 30

변 x = 20

 

변 x = 30 

변 x =35

 

메 x = 20

 변 y =60

 

메 x =35

 

변 y = 70

메 y = 70

 

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단계 로킹 프로토콜 지키기~!

데드록

 

 

 

다중로크단위

팬텀 문제

회복

회복의 개요

로그를 사용한 즉시 갱신

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

 

'Database' 카테고리의 다른 글

7. 릴레이션 정규화  (0) 2023.05.25
데베 용어 정리  (0) 2023.05.24
XAMPP 오류 해결  (0) 2023.05.22