[JSCode] Database Week5

Database/JSCode

[JSCode] Database Week5

[dev] hiro 2023. 12. 5. 19:22

Commit에 대해서 설명해주세요.

> `Commit`은 데이터베이스에서 **하나의 트랜잭션 단위**로 트랜잭션을 종료하고 해당 업데이트 정상적으로 처리했다는 것을 의미하는 것으로 변경된 사항을 **데이터베이스에 영구적으로 반영**됩니다. Commit 이후에는 모든 사용자가 변경한 데이터의 결과를 조회할 수 있으며 명령어로는 DDL문(CREATE, ALTER, DROP) 또는 (INSERT, DELETE, UPDATE)이 있습니다.
> 

### 트랜잭션 종료

- **DDL 실행**(`CREATE`, `ALTER`, `DROP`)
- **DCL**(`GRANT`, `REVOKE`)
- DEADLOCK과 같은 ERROR
- **Transaction**(`INSERT`, `UPDATE`, `DELETE`) 작업내용 취소

### SAVEPOINT

- 현재 트랜잭션을 분할하는 명령어
- `SAVEPOINT`는 `ROLLBACK TO SAVEPOINT`로 원하는 곳까지 ROLLBACK가능
- 여러개의 SQL문을 수행하는 트랜잭션의 경우, SAVEPOINT 지정 가능.

Rollback에 대해서 설명해주세요.

> `ROLLBACK`은 데이터베이스 작업 중에 **트랜잭션 처리 과정에서 발생한 변경사항을 취소**하고 트랜잭션 과정을 종료하는 명령어로써, 마지막 COMMIT(트랜잭션의 결과)으로 돌아갑니다. 또는 SAVEPOINT명령어를 사용하여 원하는 지점까지로 설정할 수 있습니다.
> 
- Transaction(INSERT, DELETE, UPDATE) 내용을 취소.
- COMMIT 내용 복구

### COMMIT과 ROLLBACK 장점

- 데이터 무결성 보장
- 데이터 원자성 보장
- 데이터 변경사항 확인 가능
- 논리적인 작업 그룹화 가능

Auto Commit 설정에 대해서 설명해주세요.

> `Auto Commit`이란 사용자가 Commit 명령을 따로 하지 않아도 **자동으로 모든 명령을 Commit**되어 즉시 반영되는 명령어를 말합니다. SQL로는 SET AUTOCOMMIT = 1/0(true/false)로 활성화 비활성화 가능합니다. SELECT으로 @AUTOCOMMIT을 확인할 수 있습니다. Commit이 된 트랜잭션은 ROLLBACK이 불가능하기에 주의해서 사용해야 합니다.
> 

### Auto Commit Case

- SQL*PLUS가 정상 종료된 경우
- DDL, DCL 수행된 경우

### Auto ROLLBACK Case

- SQL*PLUS 비정상 종료
- 컴퓨터의 다운

- mySQL에서는 auto commit이 default로 enable
- autocommit이 켜진 상태에서 start transaction하면 auto commit이 끊기고 transaction을 종료하면(commit, rollback) 다시 원래의 auto commit 상태로

트랜잭션에 대해 설명해주세요.

> `트랜잭션`은 데이터베이스 내에서 하나의 그룹으로 처리되어야하는 **명령문들을 모아놓은 작업단위**로 데이터베이스에 영구 저장되는 단위를 말합니다. 이런 논리적인 조각을 통해서 **데이터 무결성**을 지키기 위한 `COMMIT`과 `ROLLBACK`을 할 수 있습니다.
> 

### 개념

- 데이터의 일관성과 무결성을 보장하기위한 트랜잭션 관리.
- 트랜잭션
    - 데이터베이스 내에서 하나의 그룹으로 처리되어야하는 명령문들을 모아놓은 작업단위.
    - DBMS의 상호작용의 단위

### 특성

- ALL-OR-NOTHING

### 사용법

- Begin_transaction으로 시작, END_TRANSACTION으로 마무리.
- 내부에 명령문 기술

트랜잭션의 성질 ACID에 대해서 설명해주세요.ACID
- 원자성(Atomicity)
  - 트랜잭션 내의 쿼리는 모두 성공하거나 모두 실패해야 .
  - 트랜잭션은 논리적으로 쪼개질 수 없는 작업 단위이기 때문에 SQL문이 실패하면 지금까지의 모든 작업을 취소해서 아무 일도 없었던 것처럼 ROLLBACK을 해야함.
  - 이 속성에서 개발자은 언제 Commit 할 지 ROLLBACK할 지 판단.
  - 나머지 DB에 영구적으로 저장하는 것과 이전 상태로 되돌리는 것은 DBMS가 담당.
- 일관성(Consistency)
  - 트랜잭션이 DB에 정의된 rule을 위반했는지 DBMS가 커밋하기 전에 확인 및 통지.
  - DB에 정의된 role 외에 애플리케이션 관점에서 트랜잭션이 consistent하게 동작하는 지는 개발자가 확인.
- 독립성(Isolation)
  - 서로 다른 트랜잭션은 서로에게 영향을 주면 안됨. 다른 얘기로 여러 트랜잭션이 동시에 실행될 때도 혼자 실행되는 것처럼 동작하게 만듭니다. ⇒ 병행성
  - 동시성을 컨트롤할 때 성능 저하의 문제 발생 가능.
  - 따라서 DBMS의 종류에 따라 여러 종류의 isolation level을 제공.
    개발자는 isolation level 중에 어떤 level로 트랜잭션을 동작시킬지 설정 가능.
- 지속성(Durability)
  - 커밋된 트랜잭션은 DB에 영구적으로 저장.
  - DB System에 문제가 발생하더라도 COMMIT된 트랜잭션은 DB에 남아있어야 하는 속성.
  - 영구적으로 저장한다는 뜻은 비휘발성 메모리(hdd, ssd …)에 저장함.
    이 속성은 기본적으로 DBMS에서 보장.

ACID는 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가르키는 약어로
원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 지속성(Durability)이 있습니다.

트랜잭션 격리 수준이 뭘까요?

> `트랜잭션 격리 수준`이란 여러 트랜잭션이 동시에 처리될 때, 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 **허용할지 여부를 결정하는 것**입니다. 고립 수준이 높은 순서대로 `SERIALIZABLE`, `REPEATABLE READ`, `READ COMMITTED`, `READ UNCOMMITED`가 있습니다. 이 트랜잭션슬은 AUTO COMMIT이 FALSE인 상태에서만 발생합니다.
> 

|  | Dirty READ | Non-Repeatable Read | Phantom Read |
| --- | --- | --- | --- |
| READ UNCOMMITED | 발생 | 발생 | 발생 |
| READ COMMITTED | 없음 | 발생 | 발생 |
| REPEATABLE READ | 없음 | 없음 | 발생 |
| SERIALIZABLE | 없음 | 없음 | 없음 |

트랜잭션 격리 수준 READ UNCOMMITTED에 대해서 설명해주세요.

> `READ UNCOMMITTED`는 **커밋하지 않은 데이터에 접근할 수 있는 격리 수준**으로 다른 트랜잭션 중에도 작업 중인 데이터 조회가 가능하여 부정합 문제인 **Dirty READ**를 유발합니다. 따라서 MySQL에서는 최소한 READ COMMITTED 이상의 격리 수준을 사용해야합니다.
> 

### READ UNCOMMITTED

- **커밋하지 않은 데이터조차도 접근할 수 있는 격리수준**.
- 어떤 트랜잭션의 작업이 완료되지 않았는데도, 다른 트랜잭션에서 볼 수 있는 부정합 문제 ⇒ Dirty READ
    - 데이터가 조회되었다가 사라지는 현상
- 정합성이 많은 격리 수준이므로 MySQL을 사용하면 최소한 READ COMMITTED 이상의 격리 수준 사용해야함.

트랜잭션 격리 수준 READ COMMITTED에 대해서 설명해주세요.READ COMMITTED
- 커밋된 데이터만 조회.
- Phantom Read에 더해 Non-Repeatable Read(반복 읽기 불가능)문제가 발생.
- READ COMMITTED에서는 커밋된 데이터만 조회할 수 있으므로, REPEATABLE READ와 마찬가지로 언두 로그에서 변경 전의 데이터를 찾아서 반환.

READ COMMITTED는 커밋된 데이터만 조회할 수 있는 격리 수준으로 SELECT 조회 시 다른 트랜잭션에 의해 추가된 레코드를 발견하는 Phantom Read나 Non-Repeatable Read가 발생할 수 있습니다.

트랜잭션 격리 수준 REPEATABLE READ에 대해서 설명해주세요.

> `REPEATABLE READ`는 **MVCC를 이용하여 한 트랜잭션 내에서는 동일한 결과를 보장하지만, 새로운 래코드의 추가를 막지 않는 격리수준**으로 `Pahntom Read`가 발생할 수 있으며
> 

### REPEATABLE READ

- 일반적인 RDBMS는 **변경 전 레코드를 UNDO 공간에 백업**. ⇒ 변경 전/후 데이터가 모두 존재하므로 동일한 레코드에 대해 여러 버전의 데이터가 존재하는 것을 `MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어)`라고 부름.
- 이를 통해서 트랜잭션이 롤백된 경우 데이터 복원이 가능 및 트랜잭션 간에 데이터 제어 가능.
- 각각의 트랜잭션은 고유한 **트랜잭션 번호**가 존재하고 백업 레코드는 어느 트랜잭션에 의해 백업되었는지를 함께 저장.
- 데이터가 불필요하다고 판단되는 시점에 주기적으로 백그라운드 스레드를 통해 삭제.
- MVCC를 이용하여 한 트랜잭션 내에서는 동일한 결과를 보장하지만, 새로운 레코드가 추가되는 경우 부정합이 생길 수 있음.
- REPEATABLE READ는 새로운 레코드의 추가까지는 막지 않는다고 하였다. 따라서 SELECT로 조회한 경우 트랜잭션이 끝나기 전에 다른 트랜잭션에 의해 추가된 레코드가 발견될 수 있는데, 이를 유령 읽기(Phantom Read).
- 하지만 MVCC 덕분에 일반적인 조회에서 유령 읽기(Phantom Read)는 발생하지 않는다. 왜냐하면 자신보다 나중에 실행된 트랜잭션이 추가한 레코드는 무시하면 되기 때문
- Phantom Read가 발생하는 순간은 잠금이 사용되는 경우.
    - MySQL은 다른 RDBMS와 다르게 특수한 갭 락이 존재
- 트랜잭션 안에서 실행되는 SELECT라면 항상 일관된 데이터를 조회하게 된다. 하지만 트랜잭션 없이 실행된다면, 데이터의 정합성이 깨지는 상황 발생 가능

트랜잭션 격리 수준 SERIALIZABLE에 대해서 설명해주세요.

> `SERIALIZABLE`은 가장 엄격한 격리 수준으로 **트랜잭션을 순차적으로 진행하는 격리 수준**입니다. 동시 성능이 매우 떨어집니다. 이는 `SELECT FOR SHARE/UPDATE` 구문에서 사용합니다.
> 

### SERIALIZABLE

- 가장 엄격한 격리 수준
- 트랜잭션을 순차적으로 진행
- 여러 트랜잭션이 동일한 레코드에 동시 접근 불가능.
- 순차적으로 트랜잭션이 처리되어야 하므로 동시처리 성능이 매우 떨어짐
- MySQL에서 SELECT FOR SHARE/UPDATE는 대상 레코드에 읽기 쓰기 잠금을 걸음.
- 순수한 SELECT는 아무런 레코드 락이 없는데, SERIALIZABLE 격리 수준에서는 순수한 SELECT에서도 대상 레코드에 넥스트 키락을 읽기 잠금을 걸음.

DB 동시성 제어에 대해서 설명해주세요.

> `동시성 제어`는 여러개의 트랜잭션이 작업을 성공적으로 마칠 수 있도록 **트랜잭션의 실행 순서를 제어**하는 기법입니다. 이를 통해 데이터 무결성 및 일관성을 보장할 수 있습니다. 이를 위한 방법으로 Lock, TimeStamp, MVCC 등의 기법들이 있습니다.
> 

### 동시성 제어

- 여러개의 트랜잭션이 작업을 성공적으로 마칠 수 있도록 트랜잭션의 실행 순서를 제어하는 기법
- 목적
    - 트랜잭션의 직렬성 보장
    - 공유도 최대, 응답시간 최소, 시스템 활동의 최대 보장
    - 데이터 무결성 및 일관성 보장
- 동시성 제어를 하지 않은 경우 발생하는 문제점
    - **갱신손실(Lost Update)**
        - 하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 **갱신이 무효화**되는  것을 의미.
        - 두개이상 트랜잭션이 한개의 **데이터를 동시에 Update**할 때 발생.
    - **현황 파악 오류(Dirty Read)**
        - 읽기 작업을 하는 트랜잭션 1이 쓰기 작업을 하는 트랜잭션 2가 **작업한 중간에 데이터**를 읽기 때문에 발생하는 문제.
        - 작업중인 트랜잭션 2가 작업을 롤백한 경우 트랜잭션 1은 무효가 된 데이터를 읽게되고 잘못된 결과를 도출
    - **모순성(Inconsistency)**
        - 다른 트랜잭션들이 해당 항목 값을 갱신하는 동안 한 트랜잭션이 두개의 항목 값 중 **어떤 것은 갱신되기 전의 값을 읽고 다른 것은 갱신된 후의 값을 읽게되어** 데이터의 불일치가 발생하는 상황
    - **연쇄 복귀(Cascading Rollback)**
        - 두 트랜잭션이 **동일한 데이터 내용을 접근**할 때 발생
        - 한 트랜잭션이 데이터를 갱신한 다음 실패하여 Rollback 연산을 수행하는 과정에서 갱신과 Rollback 연산을 실행하고 있는 사이에 해당 데이터를 읽어서 사용할 때 발생할 수 있는 문제.
- 기법
    - Lock
        - shared Lock
        - Exclusive Lock
    - 2 Phase Locking
    - Timestamp Ordering
        - 트랜잭션을 식별하기 위하여 DBMS가 부여하는 유일한 식별자인 타임스탬프를 지정하여 트랜잭션 간의 순서를 미리 선택하는 동시성 제어 기법
        - 시스템에 들어오는 트랜잭션의 순서대로 시간 스탬프를 지정하여 동시성 제어의 기준으로 사용
        - 교착 상태를 방지하지만 Rollback 발생률이 높고 연쇄 복귀를 초래할 수 있음.
    - Validation
        - 트랜잭션을 수행하는 동안 어떠한 검사도 하지 않고, 트랜잭션 종료시에 일괄적으로 검사하는 기법
        - 트랜잭션 수행동안 그 트랜잭션을 위해 유지되는 데이터 항목들의 지역 사본에 대해서만 갱신이 이루어짐.
        - 트랜잭션 종료시에 동시성을 위한 트랜잭션 직렬화가 검증되면 일시에 DB로 반영
    - MVCC

| 기법 | 장점 | 단점 |
| --- | --- | --- |
| Locking(2PL) | 1. 데이터 오류 가능성 예방
2. 간단한 알고리즘 | 1. Lock 대기 시간 발생
2. Deadlock 발생 |
| Timestamp | 1. Dealock 발생 없음
2. 트랜잭션 대기 시간 없음 | 1. Rollback 발생확률 낮음
2. Cascading Rollback 가능 |
| Validation | 1. 동시 처리 능력 증가
2. 트랜잭션 대기 시간 없음 | 1. 장기 트랜잭션 철회시 자원낭비 |
| MVCC | 1. 최근 데이터 값을 선택
2. 동시성, 일관성 동시 해결 | 1. Undo 블록 IO에 따른 오버헤드 발생 |

갱신 손실 문제에 대해 설명해주세요.

> `갱신 손실 문제`는 **하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 갱신이 무효화** 되는 것을 의미합니다. 두개 이상의 트랜잭션이 한개의 데이터를 동시에 갱신할 때 발생하는 것으로 Lock을 통해서 해결가능합니다.
> 

### 갱신 손실 문제

- 하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 갱신이 무효화 되는 것.
- 두개 이상의 트랜잭션이 한개의 데이터를 동시에 갱신할 때 발생

DB 락에 대해서 설명해주세요.Locking 기법
- Locking은 하나의 트랜잭션이 실행하는 동안 특정 데이터 항목에 대해서 다른 트랜잭션이 동시에 접근하지 못하도록 Mutual Exclusive 기능을 제공하는 기법
- 종류
  - Shared lock
    - 읽기 연산만 가능
    - 하나의 데이터 항목에 대해 여러개의 공유 잠금이 가능
  - Exclusive lock
    - 배타 잠금을 설정한 트랜잭션은 데이터 항목에 대해서 읽기 연산과 쓰기 연산 가능
    - 동시에 여러개의 배타 잠금 불가능
- 잠금 단위 ⇒ 잠금의 대상이 되는 데이터 객체의 크기를 의미.
  - 레코드의 필드 값. 레코드, 디스크 블럭, 테이블, 데이터베이스까지 하나의 잠금 단위가 될 수 있음.
  - 잠금 단위가 클수록 동시성 수준은 낮아지고 동시성 제어 기법은 간단해짐
  - 잠금단위가 작을 수록 동시성 수준은 높아지고 관리가 복잡해짐.

DB 락은 하나의 트랜잭션이 실행되는 동안 특정 데이터 항목에 대해서 다른 트랜잭션이 동시에 접근하지 못하도록 하는 기법으로 종류로는 Shared Lock과 Exclusive Lock이 있습니다. 잠금 단위는 레코드의 필드 값부터 테이블, 데이터베이스까지 될 수 있습니다.

DB 데드락에 대해서 설명해주세요.데드락
- 두 트랜잭션이 각각 Lock을 정하고 다음 서로의 Lock에 접근하여 값을 얻어오려고 할 때 이미 각각의 트랜잭션에 의해 Lock이 설정되어 있기 때문에 양쪽 트랜잭션 모두 영원히 처리되지 않는 상태.
- 데이터의 일관성과 무결성을 유지
- 종류
- row-level lock
  - shared lock
    - 데이터를 읽을 때 사용하는 Lock
    - Select문과 같이 클라이언트가 읽기 작업하는 데이터 영역
    - 하나의 데이터 항목에 대해서 동시에 두개 이상의 S-lock 설정이 가능.
  - exclusive lock
    - 데이터를 변경할 때 사용하는 lock
    - 트랜잭션이 완료될 때까지 Exclusive lock이 끝나기 전까지 어떠한 접근도 허용하지 않는다.
- Table-level lock(Intention lock)
  - SQL server에서 shared lock이나 exclusive lock
- Record lock
  - DB의 Index record에 걸리는 lock
  - shared lock과 exclusive lock
- gap lock
  - 실제 존재하는 인덱스 레코드에 락을 거는 것이 아니고 범위를 지정하기 위해 인덱스 레코드 사이의 범위에 락을 거는 것.
  - DB index record의 gqp에 걸리는 lock ⇒ gap이란 index 중 DB에 record가 없는 부분.
  데드락 발생 줄이기
- 인덱스 설정 → 인덱스가 없으면 Lock이 걸리는 범위가 훨씬 넓어지기 때문에 교착상태가 발생하기 쉬워진다. ex) update
- Isolation Level 조정
  - 1) READ UNCOMMITED : Share-lock 사용안함.
  - 2) READ COMMITED : 매번의 read 마다 Consistent read를 통한 새로운 snap shot을 생성하며, Share-lock을 사용안함
  - 3) REPEATABLE READ : Shared Lock도 트랜잭션 종료시까지 지속된다. UPDATE, DELETE 상태일때 unique index에 대해 찾으면 → index record에만 lock (record lock)
  - range-type (범위로) 찾으면 → gap lock 사용
  - 4) SERIALIZABLE : Shared Lock이 트랜잭션 종료시까지 지속된다.
- Lock Timeout 설정 ( 트랜잭션 처리속도를 최소화 )
- 프로시저 우선순위 설정. 트랜잭션 진행방향을 같은방향으로 처리
- 데드락 발생시 DBMS는 둘 중 한 트랜잭션에 에러를 발생시킴으로써 문제를 해결.

DB 데드락은 두 트랜잭션의 Lock을 논리적으로 설정을 잘못하여 두 트랜잭션 모두 기다리고 있는 상태를 의미합니다. 이를 예방하기 위해서는 개발자가 Lock을 사용할 때에는 논리적으로 설계를 해야합니다.

DB 회복에 대해서 설명해주세요.DB 회복
- 트랜잭션들을 수행하는 도중 장애로 인해 손상된 데이터 베이스를 손상되기 이전의 정상적인 상태로 복구시키는 작업.
- 유형
  - 트랜잭션 장애: 트랜잭션의 실행 시 논리적인 오류로 발생하는 에러
  - 시스템 장애: HW 시스템 자체에서 발생할 수 있는 에러
  - 미디어 장애: 디스크 자체의 손상으로 발생할 수 있는 에러
  로그
- 트랜잭션이 반영한 모든 데이터의 변경사항을 데이터베이스에 기록하기 전에 미리 기록해두는 별도의 데이터베이스
- 안전한 하드디스크에 저장되며 전원과 관계없이 기록이 존재
- 로그의 구조: <트랜잭션 번호, 로그의 타입, 데이터 항목 이름, 수정 전 값, 수정 후 값>
- 로그의 타입: START, INSERT, UPDATE, DELETE, ABORT, COMMIT 등 트랜잭션의 연산 타입
- 로그파일을 이용한 복구
  - 로그파일에 트랜잭션의 시작(START)과 종료(COMMIT)가 있는 경우 REDO 수행
  - 로그파일에 트랜잭션의 시작(START)은 있고 종료(COMMIT)는 없는 경우 UNDO 수행

DB 회복은 트랜잭션을 수행하는 도중 장애로 인해 손상된 데이터베이스를 손상되기 전 상태로 복구시키는 작업으로 REDO와 UNDO를 통해 복구합니다.

REDO, UNDO에 대해서 설명해주세요.

> `UNDO`는 트랜잭션 **로그를 이용**하여 오류와 관련된 모든 변경을 **취소하여 복구**를 수행하고, `REDO`는 트랜잭션 **로그를 이용**하여 오류가 발생한 트랜잭션을 **재실행하여 복구를 수행**하는 것을 의미합니다.
> 

### REDO, UNDO

- REDO
    - 영속성을 보장
    - 무언가를 다시하는 행위(복구)
    - **REDO**는 복구를 할때 사용자가 했던 작업을 그대로 다시
- UNDO
    - 원자성을 보장
    - 무언가를 되돌리는 것.(작업 롤백, 읽기 일관성, 복구)
    - **UNDO**는 사용자가 했던 작업을 반대로 진행
    - 기록되는 데이터
        - INSERT시, insert된 로우의 id 기록
        - UPDATE시, 바뀐 칼럼의 바뀌기 전 값 기록
        - DELETE시, 지워진 모든 데이터 기록
- 복구 방법의 차이
    - UNDO를 통해 복구. ⇒ ROLLBACK
    - 시스템의 장애가 발생하면 UNDO 데이터도 모두 날아감
    - 시스템 장애시 REDO 데이터를 이용해서 마지막 CHECK POINT부터 장애까지 DB BUFFER CACHE를 복구. 이후 UNDO를 이용하여 COMMIT되지 않은 데이터를 모두 ROLLBACK 함으로써 복구 완료.

체크포인트 회복 기법에 대해서 설명해주세요.

> `체크포인트 회복 기법`은 **DB 회복을 하는 방법**으로 지연 갱신 회복 기법, 즉시 갱신 회복 기법 등이 있습니다.
> 

### 회복 기법

- 지연 갱신 회복 기법
    - 트랜잭션 커밋 완료까지 갱신 내용을 로그에 저장하고 DB에 저장하지 않고 지연
    - 중간에 갱신을 하지 않았으므로 undo는 필요 없고 원자성 보장
    - REDO만 하면 됨.
- 즉시 갱신 회복 기법
    - 데이터 변경 시 로그와 DB에 즉시 갱신
    - 커밋되기 전에 장애가 나면 UNDO 커밋 후에 장애가 나면 Redo
- 체크포인트 회복 기법
    - REDO, UNDO를 해야할 트랜잭션을 결정하기 위해서 이론적으로 로그 전체를 확인해야하는데 시간 소요 및 REDO. 필요없는 트랜잭션을 REDO해야하는 문제를 해결하는 기법
    - UNDO를 수행하여 회복하는 것을 후진 회복, REDO를 수행하여 회복하는 것을 전진회복.
- 그림자 페이징 회복 기법
    - 로그를 사용하지 않고 트랜잭션 실행동안 현재 페이지 테이블과 그림자 페이지 테이블 2개 관리기법.
    - 데이터 변경시 현재 테이블만 변경, 회복 시 현재 페이지 테이블을 그림자 테이블로 대체
    - UNDO 연산이 간단하며, REDO 연산이 필요 없기에 신속한 회복 가능
    - DB 페이지 변경 시 물리적 위치의 변경으로 인해 단편화가 발생.
- 미디어 회복 기법
    - 비휘발성 저장장치가 손상될 경우 사용되는 회복 기법
    - 주기적으로 데이터를 덤프하여 장애 시 최근 덤프를 DB에 적재
    - 덤프를 다른 저장소에 옮길 때 대용량 데이터 전송이 필요하며 이때 트랜잭션 처리를 중단해야하기에 CPU 낭비가 되어 비용이 많이 소모

MySQL InnoDB의 기본 트랜잭션 고립 수준은 뭘까요?

> `REPEATABLE READ`입니다. 바이너리 로그를 가진 MySQL의 장비에서는 최소 REPEATABLE READ 격리 수준 이상을 사용해야 한다고 합니다. InnoDB 스토리지 엔진은 트랜잭션이 ROLLBACK될 가능성에 대비해 변경되기 전 레코드를 `언두(Undo) 공간`에 백업해두고 실제 레코드 값을 변경합니다. 이러한 변경 방식을 `MVCC`라고 합니다.
>