트랜잭션

Oak_Cassia·2023년 4월 15일
0

데이터베이스

목록 보기
5/6

트랜잭션

  • 하나의 논리적 기능을 수행하기 위한 일련의 연산들의 집합

트랜잭션의 특성

  • 원자성 Atomicity
    • 모든 연산이 완전히 실행되거나 아예 실행 되지 않음
  • 일관성 Consistency
    • 트랜잭션 실행 전후에 데이터베이스가 일관된 상태 유지
  • 고립성 Isolation
    • 동시에 실행되는 트랜잭션들이 서로 영향을 주지 않음
  • 지속성 Durability
    • 성공적으로 완료된 트랜잭션의 결과는 영구적으로 반영

트랜잭션의 상태

  • 활동 Active
  • 부분 완료 Partially Comitted
  • 완료 Comitted
  • 실패 Failed
  • 철회 Aborted

트랜잭션의 연산

  • commit : 완료를 알리는 연산, 이후 DB 저장
  • rollback : 실패를 알리는 연산, 이후 롤백

장애의 정의

  • 예기치 못한 상황이 발생하여 시스템이 중단되는 경우

장애의 유형

  • 트랜잭션 장애: 트랜잭션 수행 중 발생하는 오류
  • 시스템 장애: 하드웨어, 소프트웨어, 네트워크 문제로 인한 전체 시스템 장애
  • 미디어 장애: 저장 매체의 손상으로 인한 데이터 손실

디스크와 메모리 사이 저장 연산

  • input : 메모리에 입력
  • output : 디스크에 출력

응용 프로그램과 메모리 사이 저장 연산

  • read : 메모리로 부터 읽기
  • write : 메모리에 쓰기

회복

  • 데이터베이스 시스템이 장애 발생 후 원래의 일관된 상태로 복구하는 과정

회복 연산

  • undo : 로그를 이용해 지금까지 실행된 모든 변경 연산을 취소하여 원래 상태로 복구
  • redo : 최근에 저장한 복사본과 로그를 이용해 복사본이 만들어진 이후 실행된 변경 연산을 재실행
  • dump : 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사
  • log : 변경연산이 실행될 때마다 데이터의 변경 전, 후 값을 기록
    • 각 트랜잭션의 시작, 데이터 변경, 커밋, 롤백 정보가 포함

로그 기반 회복 : 변경 사항을 로그 파일에 기록, 장애 발생 시 이를 사용해 복구

  • Immediate Update (즉시 업데이트)
    • 트랜잭션 실행 중 변경된 데이터 즉시 데이터베이스에 반영
    • 데이터 변경 시 로그 파일에 기록 후 데이터베이스에 반영
    • 트랜잭션 완료 전 장애 발생 시: undo
    • 트랜잭션 완료 후 장애 발생 시: redo
  • Deferred Update (지연 업데이트)
    • 트랜잭션 실행 완료 후 변경된 데이터를 데이터베이스에 한 번에 반영
    • 데이터 변경 시 로그 파일 기록
    • 이후 부분 완료 시 로그 내용 데이터베이스에 반영
    • 트랜잭션 완료 전 장애 발생 시: 로그 삭제
    • 트랜잭션 완료 후 장애 발생 시: redo

검사 시점 회복

  • 검사 시점 생성, 주기적인 검사
    • 로그 레코드 stable 저장 장치에 기록, 변경 내용 데이터베이스에 반영
  • 장애 발생 시 최근 검사 시점 이후의 트랜잭션에 회복 작업

미디어 회복

  • 일정 주기마다 데이터 복사

병행 수행

  • 여러 트랜잭션 동시 실행

모순성

  • 트랜잭션이 여러 데이터를 변경할 때 일관성 없는 데이터베이스에서 데이터를 가져와 실행

연쇄 rollback

  • 트랜잭션이 rollback 되면 해당 트랜잭션이 변경한 데이터를 사용한 트랜잭션도 rollback 필요한 상황

동시성 문제와 격리 수준

  • Dirty read
    • 커밋되지 않은 트랜잭션에 의해 쓰여진 데이터를 읽을 때 발생
    • 다른 트랜잭션이 롤백될 때 불일치 발생
  • Non-repeatable read
    • 트랜잭션이 동일한 행을 여러번 읽을 때 read 간 다른 트랜잭션에 의한 변경으로 매번 다른 데이터 발견
  • Phantom read
    • 트랜잭션이 행 집합을 읽고 나중에 동일한 집합을 다시 읽을 때 그 사이에 다른 트랜잭션에 의해 삽입된 새 행을 발견
  • Isolation level
    • 데이터베이스에서 발생할 수 있는 동시성 문제를 처리량과 일관성을 고려하여 결정
    • Read Uncommitted: 위 세가지 문제 발생 가능
    • Read committed: 커밋된 데이터만 읽음, dirty read 제외
    • Repeatable read: phantom read만 허용
    • serializable: 전부 허용 안함, 아무 문제도 발생하지 않는 level
  • Dirty write
    • 커밋되지 않은 트랜잭션에 의해 쓰여진 데이터를 쓸 때 발생
    • 모든 레벨에서 허용하면 안됨
  • Lost update
    • 트랜잭션이 수행한 데이터 변경 연산 결과가 다른 트랜잭션의 결과로 덮어씌어져 사라지는 것
  • Read skew
    • 트랜잭션에서 서로 다른 시점의 값을 읽기 때문에 트랜잭션이 일관되지 않은 데이터를 읽을 때
    • 트랜잭션이 일부 데이터를 읽고 다른 트랜잭션이 업데이트한 다음 첫 번째 트랜잭션이 연관된 데이터를 다시 읽을 때 일관성이 깨짐
  • Write skew
    • 두 트랜잭션이 동일한 데이터를 동시에 읽고 관련된 데이터를 업데이트할 때 발생
  • Snapshot isolation
    • 트랜잭션이 시작할 때 스냅샷으로 데이터베이스와 분리된 위치에 작업할 값을 저장
      • 이후 작업 시작 시점 기준으로 진행
    • write 시점에서 불일치 발생 시 abort
      • 처음 커밋한 트랜잭션의 결과가 보존
    • 트랜잭션은 실행 중에 커밋되는 다른 트랜잭션에 의해 변경된 내용을 보지 않으므로 많은 동시성 관련 문제를 방지

트랜잭션 스케줄

  • 여러 트랜잭션의 실행 순서를 정의한 것
  • 직렬 스케줄
    • 각 트랜잭션의 연산들을 순차적으로 실행
    • 트랜잭션이 완료된후 다음 트랜잭션 수행
  • 비직렬 스케줄
    • 인터리빙 방식 이용, 트랜잭션 병행 수행
    • 트랜잭션이 완료되기전 다른 트랜잭션 수행
  • 직렬 가능 스케줄
    • 직렬 스케줄같은 정확한 결과를 생성하는 비직렬 스케줄
  • unrecoverable 스케줄
    • A 트랜잭션의 write 했지만 커밋되지 않은 데이터를 B 트랜잭션이 사용하고 커밋한 뒤에, A에서 문제가 발생하여 B의 롤백이 불가능한 상태
    • rollback을 해도 회복이 불가능
  • recoverable 스케줄
    • 자신이 읽은 데이터를 write한 트랜잭션이 commit 하기 전에 commit 하지 않으면 회복 가능
  • cascadeless 스케줄
    • commit 되지 않은 트랜잭션이 write한 데이터를 읽지 않게 함
  • strict 스케줄
    • commit 되지 않은 트랜잭션이 write한 데이터를 읽거나 쓰지 않게 함
    • rollback 할 때 트랜잭션 이전 상태로 돌려놓기만 하면 된다.

충돌

  • 두 트랜잭션이 동일한 데이터 항목에 접근하고, 그 중 하나가 쓰기 연산인 경우 발생
  • conflict equivalent
    • 스케줄 A, B가 같은 트랜잭션들을 보유
    • 어떤 conflicting operations의 순서도 양쪽 스케줄 모두 동일
    • A에서 발생하는 모든 충돌 쌍은 B에서도 발생
    • 하나의 스케줄이 안전하면 다른 스케줄도 안전하다고 간주
  • conflict serializable
    • 비직렬 스케줄A가 직렬 스케줄B 와의 충돌 동치가 존재하는 경우
    • 비직렬 스케줄이 충돌 동치인 직렬 스케줄과 동일한 데이터베이스 일관성을 가지니, 충돌 동치인 직렬이 안전하다면, 해당 비직렬 스케줄도 안전하다고 간주할 수 있다.
    • 이를 활용하여 안전하고 빠른 작업 수행이 가능

병행 제어 기법

  • 여러 트랜잭션을 동시에 실행하면서 데이터 일관성을 유지하기 위한 방법
  • 로킹 기법
    • 데이터베이스의 일부 영역에 대한 접근을 제한하여 트랜잭션 간의 상호 작용을 관리
    • 로킹은 공유(shared) 및 배타적(exclusive) 두 가지 유형
      • 공유 락: read 락
      • 배타적 락: write 락
  • 2단계 로킹 규약(Two-Phase Locking Protocol, 2PL)
    • 확장 단계(Expanding Phase)
      • 트랜잭션은 필요한 모든 데이터에 대한 락을 획득
      • 아직 락 해제는 할 수 없음
    • 축소 단계(Shrinking Phase)
      • 트랜잭션은 데이터를 변경한 후 락 해제
      • 새로운 락 획득 안 함

2단계 로킹 규약을 사용하면 직렬 가능성을 보장할 수 있습니다. 하지만, 이 규약을 사용하면 성능이 저하되거나 교착상태(deadlock)가 발생할 수 있습니다. 교착상태는 여러 트랜잭션 간에 자원을 요청하는 순서가 순환적으로 되어 있어 어떤 트랜잭션도 진행할 수 없는 상태를 말합니다. 이러한 교착상태를 해결하기 위해 시간 제한, 교착상태 탐지 및 복구, 교착상태 예방 등의 기법이 사용됩니다.


Bulk Insert

  • 다수의 값을 Insert 할 때 개별 쿼리로 요청하게 되면 느려진다.
  • undo 로그, redo 로그 작성 시간 (디스크 i/o 발생)
  • 트랜잭션을 위한 비용
  • 쿼리 파싱 비용
  • 작업 시 트리거
  • 작업 전 인덱스 삭제
  • 일괄 처리: 전체 롤백 문제. 데이터 파일보다 작은 일련의 일괄 처리로 로드, 각 일괄 처리별로 로드, 커밋
  • index 업데이트와, 무결성 체크 작업을 작업 완료 시로 미룰 수 있다.

InnoDB

  • 레코드 기반락, gap 락, next key 락
  • 주로 read committed, repeatable read 많이 사용
profile
어떻게 살아야 하나

0개의 댓글