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