ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Transaction
    Computer Science 2023. 9. 6. 00:21
    728x90

    데이터베이스의 목적은 기업의 목표 달성을 위해 모순이 없는 정확한 데이터를 만들어내기 위함이다. 

    그러므로 데이터를 업데이트하고, 삭제하고, 추가하는 등의 DB 연산은 매우 중요하다.

    예를 들어, DB 내 삽입/ 삭제/ 갱신 연산 중 하드웨어의 이상, 소프트웨어 오류 등으로 연산의 실행이 취소된 상황에는, DB를 트랜잭션 이전 상황으로 돌려놓아야 한다.

    이 때 DB 연산 작업에 필요한 SQL 문들의 모임을 트랜잭션(Transaction) 이라고 한다.

    트랜잭션의 원리

    - 원자성, Atomicity : All or Nothing으로 정리할 수 있으며, 오류 발생 시 트랜잭션 이전 원래 상태로 복구해야 한다.

    - 일관성, Consistency : 트랜잭션 성공 이후 DB 내 데이터는 이전과 모순되지 않고 일관된 상태를 유지해야 한다.

    - 고립성, Isolation : DB 연산 중 중간 연산 결과에 타 트랜잭션의 접근을 불허한다.

    - 지속성, Durability :  트랜잭션 성공 후 DB 반영 결과는 영구적으로 남아있어야 한다.

    위 네 가지를 ACID로 정리하며, 이중 원자성과 지속성은 회복 기능에, 일관성과 고립성은 병행 제어 기능에 적용된다.

    트랜잭션의 상태

     

    - Active :  트랜잭션 수행이 시작된 단계

    - Partially committed : 트랜잭션의 모든 연산을 처리한 상태지만, DB에 반영되지 않은 단계

    - Committed : Commit 연산이 시작된 단계로, 트랜잭션이 DB에 성공적으로 반영된 단계

    - Failed : 트랜잭션 수행이 중단된 단계

    - Aborted : rollback 연산이 실행된 단계로, 하드웨어 이상, 소프트웨어 오류 시에는 rollback된 트랜잭션을 재시작하지만, 트랜잭션이 처리할 데이터가 DB에 존재하지 않거나 트랜잭션 내 논리적 오류 시에는 해당 트랜잭션을 폐기시킨다. 

     

    회복

    DB 장애 발생 전 일관된 상태로 복구하는 것을 의미한다

    장애, failure

    - Transaction 장애 : 트랜잭션의 논리적 오류, 잘못된 데이터 입력, 시스템 자원의 과다 사용 요구, 처리 대상 데이터 부재 등으로 발생

    - System 장애 : 하드웨어 이상으로 메인 메모리에 저장된 정보 손실 혹은 교착 상태 발생

    - Media 장애 : Disk 헤더의 손상, 고장으로 DB 내 데이터에 오류 발생

    저장 장치 설명
    휘발성 저장 장치 장애 발생 시 저장 데이터 손실
    비휘발성 저장 장치 장애 발생 시에도 저장된 데이터가 손실되지 않으나 디스크 헤더 손상 같은 저장 장치 자체 이상 시 데이터 손실 가능
    안정 저장 장치 비휘발성 저장 장치를 이용해 데이터 복사본 여러 개 만드는 방법으로, 어떤 장애가 발생하더라도 데이터 손실 우려 없이 영구적 저장 가능

    회복의 종류

    redo, 재실행 가장 최근에 저장한 데이터베이스 복사본을 가져온 후 로그를 이용해 복사본 생성 이후 실행된 모든 변경 연산 재실행하여 장애 발생 직전 데이터베이스 상태로 복구
    undo, 취소 로그 이용 지금까지 실행된 모든 변경 연산을 취소하여 데이터베이스를 원래의 상태로 복구

    즉시 갱신 회복

    - 트랜잭션 수행 중 데이터 변경 연산 결과를 즉시 DB에 반영하고, 장애 발생 대비 로그 파일에 기록

    - redo, undo 연산이 둘 다 필요한 경우 undo 연산을 먼저 한 후 이전 트랜잭션의 redo 연산을 수행한다

    - 트랜잭션에 데이터 변경 연산 실행 시 로그 파일에 로그 레코드를 먼저 기록 후 데이터베이스에 변경 연산 반영

    지연 갱신 회복

    - 트랜잭션 수행되는 동안 데이터 변경 연산의 결과를 데이터베이스에 즉시 반영하지 않고 로그 파일에 기록해두었다가 트랜잭션 부분 완료 후 로그에 기록된 내용을 이용해 데이터베이스에 한 번에 반영

    - 트랜잭션이 수행되는 동안 장애 발생 시 로그에 기록된 내용을 버리기만 하면 데이터베이스가 원래 상태로 그대로 유지

    검사 시점 회복

    - 로그 기록을 이용하되 일정 시간 간격으로 검사 시점(checkpoint)을 만들어준다.

    - 장애 발생 시 가장 최근 검사 시점 이전의 트랜잭션에는 회복 작업을 수행하지 안혹, 이후의 트랜잭션에만 회복 작업을 수행

    - 회복 작업의 범위가 검사 시점으로 정해지므로 불필요한 회복 작업을 수행하지 않아 데이터베이스 회복 시간 단축

    미디어 회복

    - 디스크에 발생할 수 있는 장애에 대비한 회복 기법

    - 전체 데이터베이스의 내용을 일정 주기마다 다른 안전한 저장 장치에 복사해두는 dump dldyd

    병행 제어

    DBMS는 여러 사용자가 데이터베이스를 동시에 공유할 수 있도록 여러 개의 트랜잭션이 동시에 수행되는 병행 수행을 지원한다. 병행 수행은 실제로 여러 트랜잭션이 차례로 번갈아 수행되는 인터리빙 방식으로 진행된다. 따라서 여러 개의 트랜잭션이 병행 수행되면서 같은 데이터에 접근하여 연산을 실행하더라도 문제가 발생하지 않고 정확한 수행 결과를 얻을 수 있도록 트랜잭션의 수행을 제어하는 것을 병행 제어라고 한다.

    병행 수행의 문제

    갱신 분실

    - 하나의 트랜잭션이 수행한 데이터 변경 연산의 결과를 다른 트랜잭션이 덮어써 변경 연산 무효화

    - 두 트랜잭션을 동시에 수행하더라도 갱신 분실 문제가 발생하지 않고 순차적으로 수행한 것과 같은 결과 값을 얻을 수 있어야 함

    모순성

    - 하나의 트랜잭션이 여러 개의 데이터 변경 연산을 실행할 때 일관성 없는 상태의 데이터베이스에서 데이터를 가져와 연산을 실행함으로써 모순된 결과 발생

    - 두 트랜잭션을 아무런 제어 없이 동시에 수행하면 정확한 트랜잭션 수행 결과를 얻을 수 없어 데이터베이스는 모순된 상태가 됨

    - 두 트랜잭션을 동시에 수행하더라도 모순성의 문제가 발생하지 않고 순차적으로 수행한 것과 같은 결과 값을 얻을 수 있어야 함

    연쇄 복귀

    - 트랜잭션이 완료되기 전에 장애가 발생하여 rollback 연산을 수행하면 트랜잭션이 장애 발생 전에 변경한 데이터를 가져가 변경 연산을 실행한 또다른 트랜잭션에도 rollback 연산을 연쇄적으로 실행해야 함

    - 장애 발생 트랜잭션의 rollback 연산 실행 전 변경된 데이터를 가져가 사용하는 다른 트랜잭션이 수행을 완료했다면 rollback 연산을 실행할 수 없어 큰 문제가 발생

    트랜잭션 스케줄

    - 여러 트랜잭션을 병행 수행할 때는 트랜잭션의 연산을 실행하는 순서가 중요

    - 트랜잭션 스케줄 : 트랜잭션에 포함되어 있는 연산들을 수행하는 순서

    - 하나의 트랜잭션에는 많은 연산들이 포함되어 있어 여러 트랜잭션을 병행 수행하는 경우 트랜잭션들의 각 연산을 실행시키는 순서인 트랜잭션 스케줄도 여러 가지 존재

    트랜잭션 스케줄 의미
    직렬 스케줄 - 인터리빙 방식을 이용하지 않고 트랜잭션 별로 연산들을 순차적으로 실행
    - 직렬 스케줄의 결과는 모두 정확하므로 어떤 직렬 스케줄을 사용하는가는 중요하지 않음
    - 각 트랜잭션을 독립적으로 수행하기 때문에 병행 수행이라고 할 수 없어 잘 사용하지 않음
    - 트랜잭션들의 순서에 따라 다양한 직렬 스케줄이 만들어질 수 있으나(결과 달라질 수 있음) 결과는 모두 정확
    비직렬 스케줄 - 인터리빙 방식을 이용하여 트랜잭션들을 병행해서 수행
    - 하나의 트랜잭션이 완료되기 전에 다른 트랜잭션의 연산이 실행 가능
    - 갱신 분실, 모순성, 연쇄 복귀 등의 문제가 발생할 수 있어 최종 수행 결과의 정확성 비보장
    - 트랜잭션들의 연산 실행 순서에 따라 다양한 비직렬 스케줄 생성, 결과의 정확도도 달라질 수 있음
    직렬 가능 스케줄 - 직렬 스케줄과 같이 정확한 결과를 생성하는 비직렬 스케줄
    - 모든 비직렬 스케줄이 직렬 가능한 것은 아님
    - 인터리빙 방식을 이용하여 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있음
    - 직렬 가능 여부 파악 어려움 -> 병행 제어 기법 등장

    병행 제어 기법

    - 여러 트랜잭션을 병행 수행하면서도 정확한 결과를 얻을 수 있는 직렬 가능성을 보장받기 위해 사용

    - 모든 트랜잭션이 따르면 직렬 가능성이 보장되는 나름의 규약을 정의하고, 트랜잭션들이 이 규약을 따르도록 하는 것

    locking 기법

    - 한 트랜잭션이 먼저 접근한 데이터에 대한 연산을 모두 마칠 때까지 해당 데이터에 다른 트랜잭션이 접근하지 못하더록 상호 배제하여 직렬 가능성 보장

    lock 트랜잭션이 사용할 데이터에 대한 독점권을 가지기 위해 사용
    unlock 트랜잭션이 데이터에 대한 독점권을 반납하기 위해 사용

    1. 해당 데이터에 대한 lock 연산 실행 -> 독점권 획득

    - 트랜잭션이 데이터에 read / write 연산 전 반드시 lock 연산 실행

    2. lock 연산을 실행한 데이터에는 트랜잭션이 unlock 연산을 실행하여 독점권을 반납할 때까지 타 트랜잭션 접근 불가

    로킹 단위

    - 전체 데이터베이스부터 작게는 데이터베이스를 구성하는 속성까지 다양한 크기의 데이터를 대상으로 실행 가능

    - 전체 데이터베이스에 lock 연산 실행시 제어가 간단하나 하나의 트랜잭션만 수행되므로 병행 수행이라 할 수 없음

    - 가장 작은 단위인 속성에 lock 연산 시 독점하는 범위가 좁아 많은 수의 트랜잭션의 병행 수행 가능, 그러나 제어가 복잡해짐

    로킹 단위가 커질수록 병행성은 낮아지지만 제어가 쉽고, 작아질수록 제어가 어려우나 병행성은 높아진다.

    기본 로킹 기법 사용 시 너무 엄격한 제약으로 인해 어떤 순간이든 데이터에 대한 독점권을 하나의 트랜잭션만 가지게 된다. 따라서 write 연산 실행 시 다른 트랜잭션이 방해하지 못하도록 독점권을 가져야 하지만, read 연산의 경우 다른 트랜잭션이 같은 데이터에 동시에 read 연산을 실행해도 문제가 발생하지 않는다.

    <기본 로킹 규약>

    연산 설명
    공용 lock 해당 데이터에 read 연산을 실행할 수 있지만 write 연산은 실행할 수 없다.
    해당 데이터에 다른 트랜잭션도 공용 lock 연산을 동시에 실행 가능하다.
    전용 lock 트랜잭션이 데이터에 전용 lock 연산 실행하면 해당 데이터에 read 연산과 write 연산 모두 실행
    그러나 해당 데이터에 다른 트랜잭션은 공용이든 전용이든 어떤 lock 연산도 실행 불가

    2단계 로킹 규약

    확장 단계 트랜잭션이 lock 연산만 실행할 수 있고, unlock 연산을 실행할 수 없는 단계
    축소 단계 트랜잭션이 unlock 연산만 실행할 수 있고, lock 연산은 실행할 수 없는 단계

    트랜잭션이 처음에 수행되면 확장 단계로 들어가 lock 연산만 실행할 수 이따. 그러다 unlock 연산을 실행하면 축소 단계로 들어가 그때부터 unlock 연산만 실행 가능해진다. 따라서 2단계 로킹 규약을 준수하는 트랜잭션은 첫번째 unlock 연산을 실행하기 전 모든 lock 연산을 실행해야 한다

    교착 상태

    트랜잭션들이 상대가 독점하고 있는 데이터에 unlock 연산이 실행되기를 서로 기다리며 수행을 중단하고 있는 상태

    처음부터 발생하지 않도록 예방하거나, 발생했을 때 빨리 탐지하여 필요한 조치를 취해야 한다. 

    728x90

    'Computer Science' 카테고리의 다른 글

    데이터베이스 관련 정리  (0) 2023.11.05
    Git  (1) 2023.10.30
    [OS] File System에서의 레코드와 필드  (0) 2023.06.22
    [Back-End] 웹 크롤러 작업 흐름  (0) 2023.06.14
    [API] 공공데이터 API 접속하기  (0) 2023.06.02
Designed by Tistory.