트랜잭션 매커니즘 - redo, undo, log,

트랜잭션 매커니즘

데이터베이스 시스템은 보통 비휘발성 저장 장치인 디스크에 데이터를 저장하며 전체 데이터베이스의 일부분을 메인 메모리에 유지한다.

 

DBMS는 데이터를 고정 길이의 페이지(page)로 저장하며, 디스크에서 읽거나 쓸 때에 페이지 단위로 입출력이 이루어진다.

 

메인 메모리에 유지하는 페이지들을 관리하는 모듈을 보통 페이지 버퍼(page buffer) 관리자 또는 버퍼 관리자라고 부르는데,

 

DBMS의 많은 주요 모듈 중에서 매우 중요한 모듈 중의 하나이다.

 

DBMS는 각 제품마다 구조가 다르기는 하지만, 크게 질의 처리기(Query Processor)와 저장 시스템(Storage System)으로 나눠볼 수 있다.

 

 

아직 완료되지 않은 트랜잭션이 수정한 페이지들도 디스크에 출력될 수 있으므로,

• 페이지 : 데이터를 고정 길이의 페이지(page)로 저장한것

 

만약 해당 트랜잭션이 어떤 이유든 정상적으로 종료될 수 없게 되면 트랜잭션이 변경한 페이지들은 원상 복구되어야 한다.

이러한 복구를 UNDO라고 한다.

 

Undo 복구는 수정된 페이지를 디스크에 쓰는 시점을 기준으로 다음과 같은 두 개의 정책으로 나누어 볼 수 있다.

• STEAL(Stel, 기록): 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
• ¬STEAL (No-Steal, 기록하지 않음): 수정된 페이지들을 최소한 트랜잭션 종료 시점(EOT, End of Transaction)까지는 버퍼에 유지하는 정책
  • 트랜잭션이 완료되지 않았으므로 당연히 기록하면 안될 것 같지만 성능 효율 등을 이유로, 대부분의 DBMS는 적당히 미리 기록하는 메커니즘을 사용한다.

 

커밋한 트랜잭션의 수정은 어떤 경우에도 유지(durability)되어야 한다.

이미 커밋한 트랜잭션의 수정을 재반영하는 복구 작업을 REDO 복구라고 한다,

REDO 복구 역시 UNDO 복구와 마찬가지로 버퍼 관리 정책에 영향을 받는다.

 

Redo 복구는 트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 페이지들을 디스크에도 쓸 것인가 여부로 두 가지 정책이 구분된다.

• FORCE (바로 기록) : 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
• ¬FORCE(No-Force, 기록하지 않음) : 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책
  • 트랜잭션이 완료되었으므로 당연히 기록할 것 같지만 성능 효율 등을 이유로, 대부분의 DBMS는 적당히 기록해야 할 때 기록하는 메커니즘을 사용한다.

 

• 대부분의 DBMS는 No-Force, Steal 사용
  • Steal (Undo) : 거의 모든 DBMS가 쓰는 정책은 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
  • No-Force (Redo) : 수정한 모든 페이지를 트랜잭션의 commit 시점에 디스크로 반영하지 않는 정책
  • 즉, Undo와 Redo 사용 필요
• 일반적인 트랜잭션 속성과 어긋나게 동작함을 표현하기 위해 No-Force, Steal 사용

 

UNDO(언두 복구)

• Undo는 원상태로 되돌리다 라는 의미. 복구, 롤백을 의미

• undo 복구란 수정된 페이지를 디스크에 출력 됐을때 이 페이지가 잘못된 페이지일 경우에 이전의 상태로 되돌리는 복구를 뜻 함
• 만약, 트랜잭션이 모두 수행되고 commit 되기 전까지 디스크에 아무것도 쓰지 않고 버퍼에 쌓아 놓는다면 undo 복구는 버퍼에대해서만 수행하면 되기 때문에 매우 간단해질 수 있다

 

 

REDO(리두 복구)

• Redo는 ''다시 하다'' 라는 의미, 트랜잭션을 재수행해서 복구
• 트랜잭션을 commit한 내용은 반드시 기록되야 한다.(트랜잭션의 지속성)
• redo는 이미 커밋한 내용을 재반영하는 복구
• 트랜잭션이 수정했던 내용들을 디스크에 반영하지 않을 수 있기 때문에 log에 기록하고 이후에 수정된 내용들을 redo 복구를 통해서 디스크에 반영
• 트랜잭션이 수정했던 내용들을 디스크에 반영하지 않을 수 있기 때문에 log에 기록하고 이후에 수정된 내용들을 redo 복구를 통해서 디스크에 반영

로그(log)

UNDO 복구와 REDO 복구를 위해서 가장 널리 쓰이는 구조는 로그(log)이다.

Redo Log, Undo Log

 

Redo Log - 이미 커밋한 내용을 재반영하는 복구, 장애발생시 복구에 사용

• 데이터베이스는, 쿼리가 실행 된 후 데이터를 바로 디스크에 저장하지 않고 일부분을 메인 메모리에 유지한다.

• DB는 메모리 위에 Buffer Pool을 두고 Table Caching 및 Index Data Caching을 위해 데이터를 고정 길이의 페이지(page)로 보관한다.

• DB에서 Commit이 발생하면 바로 디스크 로 들어가는 것이 아닌 메모리 영역(Buffer Poll & Log Buffer)에 으로 데이터가 옮겨간다.
• 이 메모리 공간이 캐싱영역이 되므로 Disk I/O가 줄어들어 DB의 성능 향상으로 이어진다.
  • 하지만 Buffer Pool은 메모리 공간이기 때문에 장애 발생시 Buffer Pool에 있는 내용은 사라지게 된다.
  • 이 때 장애 발생 시나, 사용자의 요청 또는 오류 발생으로 인해서 트랜잭션을 철회하는 경우에 Redo Log File로 복구한다.

Checkpoint 이벤트 발생시점, 트랜잭션 커밋 시점에 Redo Log Buffer에 있던 데이터들을 Disk에 File로 저장한다.

• Checkpoint 이벤트가 발생하기 전 장애가 발생한다면 Buffer Pool에 있던 데이터들은 유실되지만 마지막 Checkpoint가 수행된 시점의 Redo log file로 데이터를 복구한다.

 

Redo Log에 기록할 때는 데이터 변경이 있을 때.

DML, DDL, TCL 작업 등 DATA 변경이 일어나는 모든 것을 기록. (SELECT문은 데이터 변경 x)

• INSERT, UPDATE, DELETE , CREATE, ALTER, DROP, TRUNCATE

 

언제 LGWR(log write)가 실행될까.

• 데이터베이스 커밋(commit)이 수행되었을 때.
• 리두 로그 버퍼가 1/3이상 찼을 때
• DBWR이 변경된 데이터 블록을 저장하기 전
• 3초마다.
• LOG_CHECKPOINT_TIMEOUT파라미터 설정 시간에 의해 TIME-OUT이 발생할 때 로그를 기록 한다.

 

UndoLog - 원상태로 되돌리다. 롤백. 이전데이터로 돌아감

실행 취소 로그 레코드의 집합으로 트랜잭션 실행 후 Rollback 시 Undo Log를 참조해 이전 데이터로 복구할 수 있도록 로깅 해놓은 영역이다.

만약 해당 트랜잭션이 어떤 이유든 정상적으로 종료될 수 없게 되면 트랜잭션이 변경한 페이지들은 원상 복구되어야 한다.

이러한 복구를 UNDO라고 한다.

 

Undo Log도 Redo Log와 마찬가지로 Log Buffer에 기록.

Undo Recodrs영역에 기록.

• 저장되는 데이터는 PK값과 변경되기 전의 데이터 값

CheckPoint 시점에 디스크에 저장한다.

 

Redo Log : 변경 후의 값을 기록 - 이미 커밋한 내용을 재반영하는 복구

Undo Log : 변경 전의 값을 기록 - 롤백에 사용

 

참조

• https://velog.io/@pk3669/Mysql-Redo-Undo-Log
• http://wiki.gurubee.net/display/STUDY/LGWR
• https://d2.naver.com/helloworld/407507