3장 연습문제

3.1. undo-list에 있는 '트랜잭션에 대한 로그 레코드'는 왜 backward로 실행되고 redo-list는 forward로 실행되나?

데이터가 1->2, 2->3으로 총 2번 변경되었다고 가정하자.

이때, undo를 정방향으로 하면... 2->1 , 3->2를 진행하여 결국 1이 아닌 2라는 잘못된 값이 나온다.

redo도 마찬가지로 역방향으로 하면... 2->3, 1->2를 진행하여 3이 아닌 2라는 잘못된 값이 나온다.

그래서 복구 시 undo는 역방향으로, redo는 정방향으로 진행한다.

 

3.2. 

(a) 모든 저장 기기는 HW로 만들어져 있고 이 HW는 전자, 전기적 장치 장애에 취약하기에 stable storage는 실현될 수 없다.

(b) DB 시스템은 데이터를 여러 저장소에 동시에 저장함으로서 이를 비슷하게 실현이 가능하다. 어느 한 장치가 망가져도 다른 장치로 데이터를 이용할 수 있다.

 

3.3. 블록이 디스크에 output 전에 블록과 관련된 일부 로그 레코드가 stable storage로 output되지 않을 경우 버퍼 매니저가 DB의 일관성(Consistency)을 잃게 되는 이유는?

만약 x값을 변경하였는데 이를 디스크에 먼저 쓴 후 바로 장애가 발생한다고 가정하자.

x의 이전 값에 대한 정보를 유일하게 갖고 있는 로그 레코드가 메인 메모리에 있는데 메인 메모리는 장애 시 버퍼를 손실되기에 commit이 되지 않았다면 복구가 불가능해진다.

∴ WAL을 반드시 지켜야 한다.

 

3.4.

- Not Steal 정책의 단점: commit된 트랜잭션의 업데이트들로만 이뤄진 블록만이 디스크에 write될  수 있는데, 이로 인해 디스크로 보내지지 않고 버퍼에 수많은 블록들이 잔존해 있을 수 밖에 없게 되어 금방 꽉 차게 되고 이로 인해 이후의 트랜잭션에 영향을 미친다. 특히, 크고 다수의 업데이트의 경우 이로 인해 진행이 어렵다.

 

- Force 정책의 단점: 업데이트된 블록들을 commit 시 바로 디스크에 output하기에 commit 속도가 늦춰질 수가 있다. 

 

3.7.

(a) commit 혹은 abort 된 T0, T1을 제외한 나머지(T2, T4)는 undo-list에 담긴다.

(b) redo한 것들은 로그 레코드에 안담기고 undo내용만 로그 레코드에 담긴다.

undo는 backward로 진행되므로

<T4, B, 50>

<T2, C, 110>

<T4 abort>

<T2, A, 0>

<T2 abort> <-이건 checkpoint의 active 상태인 T2인 것을 보고 undo임을 알 수 있기에 abort 로그

레코드를 쓸 수 있다.

 

3.8.

(a) T1에서 delete한 공간을 T2가 insert를 통해 자리를 차지한다고 가정하자. 이때 T1이 abort하여 다시 그 공간을 빼앗는 것은 불가능하다.

 

(b) 로깅을 할 때 보통 logical 로깅을 주로 함. physical 로깅은 별로 좋지 않음. abort를 통해 다시 insert 시에 이는 logical 로깅 방식으로 다른 공간에 insert함.

physical 로깅은 abort 시 값을 overwritten 하기에 문제가 생길 수 있음.

 

(c) Would this problem be an issue if page-level locking is used instead of tuple-level locking?

tuple 단위로 locking을 하면 해당 tuple이 포함된 page에는 lock이 안걸려있어서 다른 트랜잭션이 이 page에

insert할 수 있고 이에 따라 문제가 발생할 수 있는 반면 page-level locking의 경우엔 page 전체에 lock이 걸려있기에

다른 트랜잭션이 수정을 할 수 없기에 문제가 발생하지 않는다.

 

3.9.

system crash는 단순히 CPU가 죽고 디스크가 손상되는 것이기에 stable storage에 있는 것은 살아남을 수 있는 반면,

disaster는 해당 site에 있는 모든 것들이 파괴되는 것이다.

 

3.10.

(a) 데이터 손실을 방지해야 하지만 일부 가용성 손실은 용인될 수 있습니다.

-> Two-very-safe 방식(availability는 낮지만, durability는 보장하니까)
(b) 트랜잭션 커밋은 재해 시 일부 커밋된 트랜잭션을 손실하더라도 신속하게 수행되어야 합니다.

-> one-safe 방식(data 손실이 있을 수 있기에 durability는 낮지만, 빠른 commit으로 인해 availability는 높으니까)
(c) 높은 수준의 가용성과 내구성이 요구되지만 트랜잭션 커밋 프로토콜에 대해 더 긴 실행 시간이 허용됩니다.

-> Two-safe 방식(위 두 방식의 절충안으로 one-safe에서 제공하는 commit 속도보다는 느리지만, 적정 수준의 availatbility와 durability는 보장이 되니까)

 

3.11.

버퍼 매니저는 (1) 과거 접근 빈도(적을 수록), (2) 접근 시 비용(낮을 수록), (3) 크기(클 수록) 먼저 evict 대상으로 고른다.

 

3.12.

(1) 트랜잭션 수행 시에 발생하는 로그 레코드가 stable storage에 내려간 후 해당 데이터 페이지가 디스크에 쓰인다.

-> 이런걸 WAL이라고 함.

 

(2) 트랜잭션이 commit하려면 트랜잭션이 생성한 모든 로그 레코드가 stable storage에 ouput되어야 함.

 

(3) 트랜잭션이 생성하는 (로그 레코드가 아니라) 데이터 버퍼는 DB 시스템에서 버퍼링을 하며 이에 대한 page replacement 정책은

LRU 알고리즘을 쓴다.

 

(4) No steal 방식의 회복 기법을 지원하는 경우, 데이터 페이지의 버퍼 크기가 매우 커야 한다.

-> commit 되지 않은 건 디스크에 저장을 하지 않으니, 버퍼에 큰 용량을 계속 차지하게 되니까.

 

(5) Steal 방식의 버퍼 관리 환경에서, 아직 완료되지 않고 수행 중인 트랜잭션이 갱신한 페이지는 디스크에 write될 수 있다.

-> commit되지 않아도 디스크에 쓰일 수 있는게 steal 방식의 정의니까.

 

(6) WAL은 데이터 페이지가 디스크에 write되기 전에 그에 관한 로그 레코드가 먼저 디스크에 반영되는 것이다.

 

(7)

not force = REDO

steal = UNDO

-> steal/force는 undo만 지원함. steal/not force가 redo, undo 모두 지원함.

 

(10) one-safe 방식의 commit은 트랜잭션의 로그 레코드가 primary site에만 반영되고 backup site에는 반영되지 않는다.

 

(11) 슬롯 페이지 구조에서 페이지 내의 레코드 크기 변화로 인해 레코드의 위치가 이동이 될 수 있고,

이때 레코드 id 값은 변경되지 않는다.

-> 예시로는 logical logging과 같은 방식이 있을 수 있지 않을까..?!?! (연습문제 3.8을 참고하자.)