[Recovery] Log

트랜잭션에 대한 정보를 로그로 남겨 두어야 failure에 대한 대비로 기록해둘 수 있다. 이 정보를 통해 복구할 수 있는 것이다.

 

recovery approach

1. log-based recovery: write 연산을 수행하기 전에 로그를 stable storage에 남기는 방법이다.

2. shadow-paging: 데이터를 업데이트 하면 old page의 copy를 갖고 있는 것이다. 초기 db 에서 사용하였다. 

 

shadowing

concurrent transaction 상황에서 쓰기 어렵다.

seeking작업을 줄이기 위해서 이웃시키는게 좋은데 이 방법에서는 어렵다.

텍스트 에디터에서 사용한다.

 

 

db 데이터를 업데이트하면 page를 추가하여 새로운 페이지에 업데이트하는 값을 쓰는 방식이다. before update가 p1~p3이 있었고 p2를 업데이트 한다고 하면 p2에 데이터를 업데이트하지 않고 새로운 페이지 p4를 만들어서 업데이트 하는 방식이다. 대용량의 db에서는 사용하기 힘든 방식이다. 

 

logging

복구와 관련된 연산은 write이다. write연산을 하면 <Ti , 데이터 X, 쓰기 이전 값 V1, 쓰기 이후 값 V2) 같은 기록들을 로그에 남기는 것이다. 이를 위해 log용 db를 둔다.

 

strict 2PL을 가정한다. write하면 바로 commit 하여서 잘못된 값을 사용하는 것을 막는다.

check point 이라는 로그를 두어서 system failure가 발생했을 때 모든 로그에 대해서 undo, redo를 전부 다 하는 것을 막는다. 백워드 스캐닝을 할 때 check point 까지만 진행하여 롤백의 양을 줄인다. 단, check point가 있으면 그 전까지 consistency가 보장한다는 뜻이다. <check point L> 을 만들 때 메인 메모리에 존재하는 로그 레코드를 로그 디비에 저장하고 시스템 버퍼에 있는 더티 블락을 찾아서 디비를 업데이트한다. 이후에 로그 레코드를 stable storage에 쓴다. L은 현재 기준으로 실행 중인 트랜잭션 리스트이다.

 

 

<checkpoint T2> 로그를 남기면서 메인메모리에 있는 로그를 로그 디비에 기록하고 시스템 버퍼에 있는 더티 블락들을 저장하고 나면 checkpoint 가 된다. T2 트랜잭션은 1/4정도 실행한 시점이 checkpoint이다. 

따라서, Tf 시점에 failure가 발생하면 T2, T3은 redo를 하고 T4는 undo 해야한다.

redo할 대상인 T3은 failure 시점에 이미 commit된 트랜잭션이다. 따라서, <T3, W, X , 10, 15>를 로그 디비에 남겨 두었을 것이다. 따라서 failure가 발생하고 redo하게 되면 로그를 보고 X의 값을 15로 바꾸면 된다. 

undo할 대상인 T4는 failure 시점에 commit이 안되어 로그 디비에 아무 기록이 없을 것이다. 따라서 했던 작업들을 롤백해야 한다.