트랜잭션 (Transaction)
트랜잭션은 업무처리를 위한 논리적인 작업단위이다.
작업의 논리적 단위가 단일 연산이 아닐 수 있다.
즉, 하나의 트랜잭션이 두 개 이상의 갱신 연산일 수 있다.
은행의 "계좌이체" 트랜잭션을 예로 들면, 하나의 예금 계좌에서 인출하여 다른 예금 계좌에 입금하는
일련의 작업을 하나의 단위로 수행해야 한다.
데이터를 일관성 있게 처리하려면 트랜잭션에 속한 두 개 이상의 갱신 연산을 동시에 실행 할 수 있어야 하는데,
불행히도 이는 불가능한 일이다. 따라서 DBMS는 차선책을 사용한다.
즉, 여러 개의 갱신 연산이 하나의 작업처럼 전부 처리되거나 아예 하나도 처리되지 않도록 동시 실행을 구현한다.
- 데이터 무결성이 보장되는 상태에서 데이터 조작 언어(DML, Data Manipulation Language) 작업을
완수하기 위한 논리적인 작업 단위 - DML 실행과 동시성 제어를 위한 중요한 개념
- 데이터 처리시 정상 종료, 사용자 프로세스 실패, 시스템 실패와 같은 비정상 종료에 대한
데이터 신뢰성과 일관성 보장 - DML 작업인 삽입(INSERT), 수정(UPDATE), 삭제(DELETE)를 실행하여 COMMIT 또는 ROLLBACK을
실행하는 과정까지를 트랜잭션이라 부름 - * 트랜잭션은 데이터베이스 시스템에서 하나의 논리적 기능을 정상적으로 수행하기 위한 작업의 기본 단위
- * 트랜잭션은 인가받지 않은 사용자로부터 데이터를 보장하기 위해 DBMS가 가져야 하는 특성
- * 한꺼번에 모두 수행되어야 할 연산
- 트랜잭션의 특징
트랜잭션의 예로 계좌 간의 자금 이체가 많이 언급됨
한 계좌에서 10만원을 인출하여 다른 계좌로 10만원 입금하는 이체 작업은 전체 작업이 정상적으로 완료되거나,
만약 정상적으로 처리될 수 없는 경우에는 아무 것도 실행되지 않은 처음 상태로 되돌려져야 한다.
이러한 트랜잭션은 다양한 데이터 항목들을 액세스하고 갱신하는 프로그램 수행의 단위가 된다.
흔히 트랜잭션은 ACID 성질이라고 하는 다음의 네가지 특징으로 설명된다.
유형 | 설명 |
원자성(Atomicity) | 이체 과정 중에 트랜잭션이 실패하게 되어 예금이 사라지는 경우가 발생해서는 안되기 때문에 DBMS는 완료되지 않은 트랜잭션의 중간 상태를 데이터베이스에 반영해서는 안된다. 즉, 트랜잭션의 모든 연산들이 정상적으로 수행 완료되거나 아니면 전혀 어떤 연산도 수행되지 않은 상태를 보장해야 한다. atomicity는 쉽게 'all or nothing' 특성으로 설명된다. - 트랜잭션을 구성하는 연산 전체가 모두 정상적으로 실행되거나, 모두 취소되어야 하는 성질 - COMMIT / ROLLBACK 회복성보장 * 트랜잭션은 더 이상 분해가 불가능한 업무의 최소단위이므로 전부 처리되거나 아예 하나도 처리되지 않아야 한다. |
일관성(Consistency) | 고립된 트랜잭션의 수행이 데이터베이스의 일관성을 보존해야 한다. 즉, 성공적으로 수행된 트랜잭션은 정당한 데이터들만을 데이터베이스에 반영해야 한다. 트랜잭션의 수행을 데이터베이스 상태 간의 전이(transaction)로 봤을 때, 트랜잭션의 수행 전후의 데이터베이스 상태는 각각 일관성이 보장되는 서로 다른 상태가 된다. 트랜잭션 수행이 보존해야 할 일관성은 기본 키, 외래 키 제약과 같은 명시적인 무결성 제약조건들뿐만 아니라 자금 이체 예에서 두 계좌 잔고의 합은 이체 전후가 같아야 한다는 사항과 같은 비명시적인 일관성 조건들도 있다. - 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전 후의 상태가 같아야 하는 성질 - 무결성 제약조건, 동시성 제어 * 일관된 상태의 데이터베이스에서 하나의 트랜잭션을 성공적으로 완료하고 나면 그 데이터베이스는 여전히 일관된 상태여야 한다. 즉, 트랜잭션 실행의 결과로 데이터베이스 상태가 모순되지 않아야한다. |
고립성(Isolation) / 격리성 |
여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션의 수행에 영향을 받지 않고 독립적으로 수행되어야 한다. 즉, 한 트랜잭션의 중간 결과가 다른 트랜잭션에게는 숨겨져야 한다는 의미인데, 이러한 isolation 성질이 보장되지 않으면 트랜잭션이 원래 상태로 되돌아갈 수 없게 된다. Isolation 성질을 보장할 수 있는 가장 쉬운 방법은 모든 트랜잭션을 순차적으로 수행하는 것이다. 하지만 병렬적 수행의 장점을 얻기 위해서 DBMS는 병렬적으로 수행하면서도 일렬(serial) 수행과 같은 결과를 보장할 수 있는 방식을 제공하고 있다. - 동시에 실행되는 트랜잭션들이 서로 영향을 미치지 않아야 한다는 성질 - Read Uncommitted, Serializable .. * 실행 중인 트랜잭션의 중간결과를 다른 트랜잭션이 접근할 수 없다. |
지속성(Durability) | 트랜잭션이 성공적으로 완료되어 커밋되고 나면, 해당 트랜잭션에 의한 모든 변경은 향후에 어떤 소프트웨어나 하드웨어 장애가 발생되더라도 보존되어야 한다. - 성공이 완료된 트랜잭션의 결과는 영속적으로 데이터베이스에 저장되어야 하는 성질 - 회복 기법 * 트랜잭션이 일단 그 실행을 성공적으로 완료하면 그 결과는 데이터베이스에 영속적으로 저장된다. |
- 트랜잭션 격리성(Isolation)
트랜잭션의 격리성(Isolation)은 일관성(Consistency)와 마찬가지로 Lock을 강하게 오래 유지할수록 강화되고,
Lock을 최소화할수록 약화된다. 낮은 단계의 격리성 수준에서 어떤 현상들이 발생하는지 살펴보자.
낮은 단계의 격리성(Isolation) 수준에서 발생할 수 있는 현상들(시간차공격)
- Dirty Read:
다른 트랜잭션에 의해 수정됐지만 아직 Commit 되지 않은 데이터를 읽는 것을 말한다.
변경 후 아직 커밋되지 않은 값을 읽었는데 변경을 가한 트랜잭션이 최종적으로 Rollback된다면
그 값을 읽은 트랜잭션은 비일관된 상태에 놓이게 된다.
("어?! 그거 왜 가지고 있어? 그냥 더러워서 안할려고 포기했는데?") - Non-Repeatable Read:
한 트랜잭션 내에서 같은 쿼리를 두 번 수행했는데,
그 사이에 다른 트랜잭션이 값을 수정 또는 삭제하는 바람에 두 쿼리 결과가 다르게 나타나는 현상
("난 1,000원을 두번보내서 2,000원 보냈을텐데 왜 넌 1,000원만 가지고 있어?") - Phantom Read:
한 트랜잭션 내에서 같은 쿼리를 두 번 수행했는데,
첫번째 쿼리에서 없던 유령(Phanthom) 레코드가 두 번째 쿼리에서 나타나는 현상을 말한다.
("분명 1초전에 조회했을때는 없었는데 그 사이에 누가 등록했나보네?")
'SQL Server' 에서의 트랜잭션 3가지 방식
- Auto Commit:
SQL Server 의 기본방식이며 DML, DDL을 수행할 때마다 DBMS가 트랜잭션을 컨트롤하는 방식이다.
명령어가 성공적으로 수행되면 자동으로 COMMIT을 수행하고 오류가 발생하면 자동으로 ROLLBACK을 수행한다. - 암시적 트랜잭션:
Oracle과 같은 방식으러 처리된다.
즉, 트랜잭션의 시작은 DBMS가 처리하고 트랜잭션의 끝은 사용자가 명시적으로 COMMIT 또는
ROLLBACK으로 처리한다. 인스턴스 단위 또는 세션 단위로 설정할 수 있다. - 명시적 트랜잭션:
트랜잭션의 시작과 끝을 모두 사용자가 명시적으로 지정하는 방식이다.
BEGIN TRANSACTION(BEGIN TRAN 구문도 가능) 으로 트랜잭션을 시작하고
COMMIT TRANSACTION(TRANSACTION은 생략 가능) 또는 ROLLBACK TRANSACTION으로 트랜잭션을 종료
ROLLBACK 구문을 만나면 최초의 BEGIN TRANSACTION 시점까지 모둔 ROLLBACK이 수행된다.
- 트랜잭션 상태 변화
상태 | 설명 |
활성(Active) | 트랜잭션이 실행중인 상태 |
실패(Failed) | 트랜잭션 실행에 오류가 발생하여 중단된 상태 |
철회(Aborted) | 트랜잭션이 비정상적으로 종료되어 ROLLBACK 연산을 수행한 상태 |
부분완료 (Partially Committed) |
트랜잭션의 마지막 연산까지 실행하였지만, COMMIT 연산이 실행되기 직전의 상태 |
완료(Commit) | 트랜잭션이 성공적으로 종료되어 모든 데이터를 영구적으로 반영 |
롤백(Rollback) | 트랜잭션의 모든 데이터 변경을 포기 |
- Commit 이전
- 데이터 변경 이전 상태로 복구 가능
- 현재 사용자만 작업 결과 확인 가능
- 다른 사용자는 확인 불가
- 변경 중인 행은 접근 제어
- 다른 사용자가 변경 불가
- Commit 이후
- 데이터를 영구적으로 변경/적용
- 기존 데이터 상실
- 모든 사용자가 결과 확인 가능
- 접근 제어 해지
- 다른 사용자가 변경 가능
# 참조: https://d2.naver.com/helloworld/407507
SAVEPOINT
저장점(SAVEPOINT)을 정의하면 롤백(ROLLBACK)할 때 트랜잭션에 포함된 전체 작업을 롤백하는 것이 아니라
현 시점에서 SAVEPOINT까지 트랜잭션의 일부만 롤백할 수 있다.
따라서 복잡한 대규모 트랜잭션에서 에러가 발생했을 때 SAVEPOINT까지의 트랜잭션만 롤백하고 실패한 부분에
대해서만 다시 실행할 수 있다.(일부 툴에서는 지원이 안될 수 있음)
복수의 저장점을 정의할 수 있으며, 동일이름으로 저장점을 정의했을 때는 나중에 정의한 저장점이 유효하다.
"데이터 변경을 사전에 지정한 저장점까지만 롤백하라"
병행(동시성) 제어 (Concurrency Control)
- 다중 사용자(multi-user) 환경을 지원하는 데이터베이스 시스템에서 여러 트랜잭션들이 성공적으로 동시에 실행될 수 있도록 지원
- 다중 사용자 환경을 지원하는 데이터베이스 시스템의 경우 필수적으로 지원해야 하는 기능(병행 제어)
- 트랜잭션의 직렬화 수행 보장
- 정확한 접근 제어가 안되면 부정확한 데이터 발생
- 동시성 제어 실패 시 데이터 불일치, 갱신 손실 등의 오류 발생
- 병행 제어의 목적
- 데이터베이스의 공유를 최대화한다.
- 시스템의 활용도를 최대화한다.
- 데이터베이스의 일관성을 유지한다.
- 사용자에 대한 응답시간을 최소화한다.
- 병행 제어 미보장시 문제점
문제점 | 설명 |
갱신 손실 (Lost Update) |
- 하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어쓰게 되어 갱신이 무효화 - 두 개 이상의 트랜잭션이 한 개의 데이터를 동시에 갱신(Update)할 때 발생 - 먼저 실행된 트랜잭션의 결과를 나중에 실행된 트랜잭션이 덮어쓸 때 발생하는 오류 |
현황 파악 오류 (Dirty Read) |
- 읽기 작업을 하는 트랜잭션 1이 쓰기 작업을 하는 트랜잭션 2가 작업한 중간 데이터를 읽기 때문에 발생함 - 작업중인 트랜잭션 2가 작업을 RollBack한 경우 트랜잭션 1은 무효가 된 데이터를 읽어 잘못된 결과 도출 - 트랜잭션의 중간 수행 결과를 다른 트랜잭션이 참조하여 발생하는 오류 |
모순성 (Inconsistency) |
- 다른 트랜잭션들이 해당 항목 값을 갱신하는 동안 한 트랜잭션이 두 개의 항목 값 중 어떤 것은 갱신 되기 전의 값을 읽고 다른 것은 갱신된 후의 값을 읽게 되어 데이터 불일치 발생 - 두 트랜잭션이 동시에 실행되어 데이터베이스의 일관성이 결여되는 오류 |
연쇄복귀 (Cascading Rollback) |
- 두 트랜잭션이 동일한 데이터 내용에 접근할 때 발생 - 한 트랜잭션이 데이터를 갱신한 다음 실패하여 롤백 연산을 수행하는 과정에서 갱신과 롤백 연산을 실행하고 있는 사이에 해당 데이터를 읽어서 사용할 때 발생 - 복수의 트랜잭션이 데이터 공유 시 특정 트랜잭션이 처리를 취소할 경우 트랜잭션이 처리한 곳의 부분을 취소하지 못하는 오류 |
- 병행 제어 기법
기법 | 설명 |
로킹 (Locking) |
- Shared Lock : 데이터 항목에 대해 읽기(read)만 가능 - Exclusive Lock: 데이터 항목에 대해 읽기와 기록(입력/삭제) 모두 불가능 - 2 Phase Locking: 모든 트랜잭션들이 lock과 unlock 연산을 확장과 수축단계로 구분하여 수행 - 하나의 트랜잭션이 실행하는 동안 특정 데이터 항목에 대해서 다른 트랜잭션이 동시에 접근하지 못하도록 상호배제 (Mutual Exclusive) 기능을 제공하는 기법 - 로킹 단위가 커지면 병행성 수준이 낮아짐 - 로킹 특징 1. 데이터베이스, 파일, 레코드 등은 로킹 단위가 될 수 있음 2. 로킹 단위가 작아지면 데이터베이스 공유도가 증가 3. 로킹 단위가 작아지면 로킹 오버헤드가 증가 4. 한꺼번에 로킹할 수 있는 객체의 크기를 로킹 단위라고 함 |
낙관적 검증 (Optimistic Validation) |
- 트랜잭션이 어떠한 검증도 수행하지 않고 일단 트랜잭션을 수행하고, 트랜잭션 종료 시 검증을 수행하여 데이터베이스에 반영하는 기법 - 트랜 잭션 수행 동안은 어떠한 검사도 하지 않고, 트랜잭션 종료 시 일괄적 검사 기법 |
타임 스탬프 순서 (Time Stamp Ordering) |
- 트랜잭션과 트랜잭션이 읽거나 갱신한 데이터에 대해 트랜잭션이 실행을 시작하기 전에 타임 스탬프(Time Stamp)를 부여하여 부여된 시간에 따라 트랜잭션 작업을 수행하는 기법 - 데이터베이스 시스템에 들어오는 트랜잭션 순서대로 System Clock / Logical Counter를 할당하고 순서를 부여하여 동시성 제어의 기준으로 사용 |
다중 버전 동시성 제어 (MVCC: Multi Version Concurrency Control) |
- 트랜잭션의 타임스탬프와 접근하려는 데이터의 타임스탬프를 비교하여 직렬 가능성이 보장되는 적절한 버전을 선택하여 접근하도록 하는 기법 |
- 동시성 제어 기법 비교
제어 기법 | 장점 | 단점 |
2 Phase Locking | - 데이터 오류 가능성 예방 - 간단한 알고리즘 |
- Lock 대기시간 발생 - Deadlock 발생 |
Validation | - 동시 처리 능력 증가 - 트랜잭션 대기 시간 없음 |
- 장기 트랜잭션 철회 시 자원 낭비 |
Time Stamp Ordering | - Deadlock 발생 없음 - 트랜잭션 대기시간 없음 |
- Rollback 발생 확률 높음 - Cascading Rollback 가능 |
MVCC | - 최근 데이터 값 선택 - 동시성, 일관성 동시 해결 |
- Undo 블록 I/O에 따른 오버헤드 발생 |
'Language > RDBMS' 카테고리의 다른 글
뷰(View) (0) | 2023.03.06 |
---|---|
[DDL] 명령어를 활용한 테이블 정의 (0) | 2023.03.04 |
데이터 무결성과 제약 조건 (0) | 2023.03.03 |
[DML-DELETE] 데이터 삭제 (0) | 2023.03.03 |
[DML_UPDATE] 데이터 변경 (0) | 2023.03.03 |