모두의 SQL - 데이터 무결성, Transaction

-·2022년 6월 27일
0

데이터 무결성

데이터는 잘못된 입력, 갱신, 삭제로 부터 보호되어야 한다.

ex) 기본키는 데이터값을 구별할 수있는 유일한 값이어야 한다. 이를 위배하면 데이터식별에 문제가 생긴다.

이를 위해서 여러가치 규칙들로 데이터를 보호한다.

데이터가 입력될 때마다 부적절한 입력인지 검사하여 데이터의 무결성을 유지한다.

유형설명
개체 무결성(entity integrity)기본 키(primary key)로 선택된 열은 고유해야 하며 null 값을 가질 수 없다.
참조 무결성(reference integrity)기본 키와 외래 키의 관계이다. 외래 키가 있는 테이블의 경우에는 기본 키와 외래 키 간의 관계가 항상 유지됨을 보장한다. 참조하는 외래 키가 존재하면 행은 삭제될 수 없고 기본 키도 변경될 수 없다.
영역 무결성(domain integrity)데이터 형태, 범위, 기본값, 유일성에 관한 제한이다.주어진 속성 값은 그 속성이 정의된 도메인에 속한 값이어야 한다.예 값이 0 이상, YN 값 준수 여부, 기본값은 1 등
비즈니스 무결성(business integrity)사용자의 업무 규칙에 따른 비즈니스적인 제약 조건이다.예 제약 조건, DEFAULT, TRIGGER 등의 사용자 정의

제약조건

정해놓은 규칙에 맞는 데이터만 입력

제약조건을 위반하면 오류를 뱉는다.

예시

기본키 - NOT NULL, UNIQUE

외래키 - 반드시 부모테이블의 값을 참조해야함, 참조되는 열은 UNIQUE or 기본키

유일키(UNIQUE) - 중복X, NULL 허용

CHECK - 특정범위, 지정값만 허용

여러가지 방법으로 제약조건을 걸어서 무결성을 보호가능하다.

Transaction(트랜잭션)

무결성이 보장되는 상태에서의 기본 작업 단위

트랜잭션으로 비정상종료, 프로세스 실패, 신뢰성을 체크

일련의 과정이 시작되고 완료되어서 성공or실패의 과정을 트랜잭션이라고 표현

ex) SELECT -> UPDATE, DELETE, INSERT -> COMMIT -> 성공or실패

특징DB 기능설명
원자성 (Atomicity)회복성의 보장
Commit/ Rollback
트랜잭션은 분해가 불가능한 논리적 최소 단위로 실행 전체가 승인되거나 취소 되어야 함. (All or Nothing)
일관성(Consistency)무결성 제약조건
동시성 제어
트랜잭션의 수행 이후 데이터는 무결성이 유지되고 모순되지 않아야 함.
ex) 계좌에 100원이 입금되었으면 100원이 추가 되어있어야됨
입출금이 되었으면 +-가 맞아야됨
고립성(Isolation)Isolation Level
분산트랜잭션
Lock
다수의 트랜잭션이 동시에 수행되더라고 개별 트랜잭션의 결과에 영향을 미쳐서는 안됨.
트랙잭션이 진행되는 중간에는 절대 간섭할 수없음
지속성(Durability)회복기법
회복 컴포넌트관리
성공적으로 수행된 트랜잭션은 해당 요인에 의해 변경 및 손실되지 않아야 함.

이 특성을 ACID라고 부르기도 한다.

결과적으로 한개이상의 트랜잭션이 순차처리 or 병렬처리가 되더라도 결과는 변하지 않아야한다.

트랜잭션의 상태

상태설명
실행(active)트랜잭션이 정상적으로 개시되었으며 정상적으로 진행중인 상태
부분완료(partially commited)트랜잭션에 정의된 모든 연산이 종료된 상태
완료(commited)트랜잭션의 성공적 종료
실패(failed)비정상적인 트랜잭션 종료상태
중단, 철회(aborted = rollback)트랜잭션이 실패하여 실행되기 이전으로 복귀된 상

TCL(트랜잭션 제어어)

  • COMMIT

    모든 미결정데이터를 반영, 저장

  • ROLLBACK

    모든 미결정데이터변경 포기, 되돌리기

커밋은 수동/자동으로 실행

DML은 수동, DDL은 자동으로 된다고 하지만

auto commit 설정으로 변경가능

또한, 커밋 이전의 데이터는 현재 사용자만 확인가능하며 변경중인 행은 간섭이 불가능하다.

커밋완료후에는 데이터가 변경되며 접근제어가 해지되어 다른사용자가 접근이 가능

동시성 제어

동시에 실행되는 여러개의 트랜잭션을 안전하게 마무리 할수있게 지원

하나의 데이터에 대해서 동시에 접근하게 되면 중간에 데이터가 변경되어서 서로 다른 데이터로 작업을 하게 되는경우가 생겨버린다.

접근제어 실패로 생기는 오류상황의 종류
문제점설명예시상황
갱신손실(Lost Update)트랜잭션이 동일 데이터를 동시에 갱신을 할 경우 발생.
트랜잭션 종료 이전 다른 트랜잭션이 갱신을 수행하는 경우 발생
Tx1과 Tx2가 동시에 갱신을 시도하여 늦게 발생된 Tx2에의해 Tx1의 수행이 무효화됨.
현황파악오류(Dirty Read)트랜잭션 중간 수행결과를 다른 트랜잭션이 참조함으로써 발생하는 오류Tx1에서 일어난 트랜잭션 실행이 Tx2에도 영향을 미침.
모순성(Inconsistency)복수개의 트랜잭션이 동시에 실행될때 데이터베이스가 상호 간섭으로 인해 일관성 없는 상태로 변질된 오류Tx1와 Tx2가 동시에 실행되는 과정에서 데이터 값이 상호 연관 없이 변질됨.
연쇄복귀(Cascading Rollback)복수 개의 트랜잭션 중 실행 실패로 인해 하나의 트랜잭션이 취소될 경우 다른 트랜잭션도 영향을 받는 경우의 오류Tx1이 실행 실패로인해 롤백되어야 하는데 성공적으로 실행된 Tx2도 롤백되는

이러한 오류현상을 방지하기 위해서 여러가지 기법을 사용

동시성 제어 기법
기법설명
Locking모든 트랜잭션을 Lock과 Unlock로 나누어 직렬성을 보장하는 기법

Lock이 걸리면 Unlock 될 때까지 접근/수정/삭제 모두 불가
확장단계, 차단단계, 수축단계로 구분되어 실행됨.
TimestampOrdering데이터베이스에서 부여되는 식별자인 Timestamp를 이용하여 시간대 별로 직렬화를 시켜 동시성을 제어하는 기법.
직렬성보장, 교착상태 방지 등의 장점을 가지고 있음.
시스템 시계 (System Clock) 사용 방법과 논리적 계수기 사용 방법으로 나뉨.
낙관적 검증기법,
적합성 검증
트랜잭션을 수행하는 동안 어떠한 검증도 수행하지 않고 트랜잭션 종료 시 동시성 검증을 수행하여 데이터베이스에 최종적으로 반영하는 방식.
확인 검사 시 직렬 가능성 검사를 실시함.

직렬화(serialization)를 보장해서 동시에 들어오는 요청을 순차적으로 반영

격리 수준 - Isolation Level

보통 DB시스템이 보장해주기 때문에 이것까지 신경쓸일은 많이 없을듯 하지만 일단 개념은 더 파악해보자

데이터의 안전을 위해서는 어떤종류의 트랜잭션이든지 하나가 완벽하게 끝난뒤(Lock, Unlock을 활용하여)에 다른 트랜잭션을 수행하는것이 가장 이상적일 것이다.

하지만 이렇게 되면 동시성이 전혀 없어진다. 퍼포먼스적으로는 별로 좋지못한 현상이다.

lock을 너무 많이 걸면 성능이 떨어지고 너무 안걸면 오류상황이 생길가능성이 높아진다. (이걸 동시성과 격리성은 Trade-off관계라고 하더라)

따라서 효율적인 수준을 찾아야된다.

그래서 나온 개념이 격리수준이라는 개념이다.

성능을 위해서 어느정도는 트랜잭션에서 일관성없는 데이터를 허용할 수있어야 된다는 거다.

여기서부터는 알고만 있으면 되지않을까? 아직 내가 DB설계하는 입장도 아니고 이걸 써서 뭔가를 할일을 없을듯?

격리 수준 ( 아래로 갈수록 강해짐 )설명
Read Uncommitted트랜잭션에서 처리 중인 아직 COMMIT 되지 않은 읽기를 허용한다.
Read Committed트랜잭션이 COMMIT 확정된 데이터만 다른 트랜잭션이 읽도록 허용(shared lock)한다.
Dirty Read를 방지해준다. 하지만 COMMIT된 데이터만 읽더라도 Non-Repeatable Read와 Phantom Read 현상을 막지는 못한다.
Repeatable Read같은 쿼리를 두 번 이상 수행할 때, 첫 번째 쿼리에 있던 레코드가 사라지거나 값이 바뀌는 현상을 방지하기 위해 사용한다.
트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸린다.
Serializable같은 쿼리를 두 번 이상 수행할 때, 첫번째 쿼리에 있던 레코드가 사라지거나 값이 바뀌지 않음은 물론 새로운 레코드가 나타나지도 않는 것을 보장하기 위해 사용한다.
모든 작업을 하나의 트랜잭션에서 처리하는 것과 같은 가장 높은 고립 수준.
효율성이 너무 떨어져서 RDB에서는 잘 사용하지않는다.

낮은 단계의 Isolation Level을 활용할 때 발생하는 현상들

현상 종류설명
Dirty Read트랜잭션에서 처리 중인 아직 COMMIT 되지 않은 읽기를 허용한다.
아직 커밋 되지 않은 값을 읽었는데 변경을 가한 트랜잭션이 최종적으로 롤백 된다면 그 값을 이미 읽은 트랜잭션은 일관성을 잃어버린 상태(Inconsistent)에 놓이게 된다.
Non-Repeatable Read한 트랜잭션 내에서 같은 쿼리를 두 번 수행했는데,
그 사이에 다른 트랜잭션이 값을 수정 또는 삭제하고 COMMIT하는 바람에 두 쿼리 결과가 다르게 나타나는 현상
Phantom Read한 트랜잭션 내에서 같은 쿼리를 두 번 이상 수행할 때, 없던 레코드(Phantom Record)가 두 번째 쿼리에서 나타나는 현상
이는 트랜잭션 도중 새로운 레코드가 삽입되는 것을 허용하는 경우 나타난다.

LOCK의 종류?

  • S Lock(Shared Lock, 공유 잠금)

    읽기 잠금(Read lock)이라고도 한다.
    데이터를 다른 사용자가 동시에 읽을 수 있도록 하되, 변경은 불가능하게 하는 lock이다.

  • X Lock(Exclusive lock, 배타적 잠금)

    쓰기 잠금(Write lock)이라고도 한다.
    어떤 트랜잭션에서 데이터를 변경하고자 할 때 해당 트랜잭션이 완료될 때까지 해당 테이블 혹은 레코드를 다른 트랜잭션에서 읽거나쓰지 못하게 하기 위해 Exclusive lock을 걸고 트랜잭션을 진행시키는 것이다.

더 깊게 들어가면 RX, RS, SRX, X 등 다양한 Lock 이 존재한다.

데드락(DeadLock)

익히아는 그 데드락현상이 맞다.

여러 개의 트랜잭션(Transaction)들이 실행을 하지 못하고 서로 무한정 기다리는 상태

일단 문제에 빠지면 어느한쪽을 취소하는게 가장 좋은방법이 아닐까.

profile
거북이는 오늘도 걷는다

0개의 댓글