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`라고 합니다.
>

'Database > JSCode' 카테고리의 다른 글

[JSCode] Database 면접 스터디 회고록  (3) 2023.12.08
[JSCode] Database Week4  (0) 2023.11.28
[JSCode] Database Week3  (1) 2023.11.21
[JSCode] Database Week2  (2) 2023.11.14
[JSCode] Database Week1  (1) 2023.11.07

+ Recent posts

티스토리툴바