데이터베이스, 트랜잭션(Transaction) - 3(장애와 복구)

이 글에서는

트랜잭션 장애(failure)와 복구(recovery)에 대해서 알아보겠다.

 

---

살다보면 원치 않는 일을 마주하는 것처럼

DBMS도 정상적인 수행을 하다가도 장애가 발생할 수 있다. 

원인도 각양각색이다.

-소프트웨어 장애와 하드웨어 장애

하지만 우리는 하드웨어 장애라면 자신있다 -> 걍 새거로 교체하면 다 되는 것이다 ㅎㅎ

 

근데 소프트웨어적 에러는 우리가 참 처리하기 힘들다.

장애가 일어났을 경우 장애 이전의 상태로 복원하는 과정인 복구를 진행하기도 어렵다.

 

---

 

왜 위에 말이 나온건진 모르겠지만 그렇다면 우선 DB에서의 종류는 무엇이 있을까??  (3가지가 있다)

 

-트랙잭션 장애

트랜잭션 내의 논리적 오류나 잘못된 입력 데이터 또는 시스템 내의 자원 부족으로 인한 트랜잭션의 중단이다.

 

-시스템 장애

정전이나 하드웨어 결함으로 시스템 작동이 중단.

 

-미디어 장애

디스크와 같은 저장장치의 일부 또는 전체가 손상

 

**복구란 데이터베이스를 장애 발생 이전의 일관된 상태로 복원하는 것임

-> 복구의 기본원리는 데이터 중복(redundancy) -> backup or mirroring

다시 말해서 백업파일 또는 복제를 이용하는 것이다.

 

 

---

그래.. 장애가 일어나면 우리는 어떻게 복구시킬생각인데???

 

트랜잭션 장애 or 시스템 장애 

트랜잭션이 완료되지 못하고 장애 발생 시, 재가동 되었을 때 갱신된 내용이 복구되어야 한다.

그 복구를 어떻게 하느냐?

-데이터베이스에 어떠한 순서로 갱신이 이루어졌는가를 나타내는 정보가 기록되어있어야 한다.

-> 누가 로그는 남아있다 (log) 막 이러는데? (해석은 통나무임)

로그는 비휘발성 저장장치에 보관되기 때문에 남아있긴 하다. 

**간혹가다 로그도 없어질 수 있음

 

로그란 트랜잭션이나 시스템 장애에 대비한 데이터베이스 갱신 이력(history) 저장

-> 데이터베이스가 아닌 다른 영역에서도 히스토리와 같은 개념으로 쓰임

 

 

특히 미디어 장치가 고장났다면...? (미디어 장치는 저장장치라고 위에서 말했다)

 

 

---

 

어떻게 데이터베이스에 저장되길래? 오류가 생기는지 알아보도록하자

 

데이터베이스는 디스크에 저장되며 블록(block)이라는 단위로 분할되어서 관리된다고 했다. 

 

++데이터는 일반적으로 CPU, RAM, HDD or SDD 처럼, 또는 레지스터 - 캐시 - RAM - 보조기억장치처럼 

바로 불러낼 수 있는 것도 아니다.

 

즉, 우리는 데이터베이스를 이용할 때 항상 버퍼(buffer)를 관리하고 버퍼를 이용한다. 

-> 읽기 쓰기 모두 버퍼를 이용함.

 

 

---

 

아? 어떻게 저장되는지도 알겠다. 

그럼 만약 로그를 뭘남겨야 나중에 내가 복구를 할 수 있을까?? 생각해보자

 

데이터베이스의 변경이 언제 일어날까?

-> 버퍼에 저장되었던 내용이 디스크에 저장될 때!!!

 

**그렇다면 로그는 버퍼에 저장되어야 할까? -> 아니다 디스크에 저장되어야 보존된다. (버퍼는 날라가잖아)

 

 

다시 그럼 로그에는 무슨 기록이 남을까? 

트랜잭션들의 모든 갱신 활동을 기록한다. 때문에 트랜잭션 실행 중 장애가 발생하면 그 기록을 따라 

이전의 상태로 복구할 수 있는 것이다.

 

 

 

-> 와 정말 복구할 수 있겠는걸??? 우선 난 못알아들어도 DBMS가 알아들으니까!! 괜찮아

 

** 두 개 이상의 트랜잭션에선...?

 

DBMS화이팅! 잘알아듣도록.

 

 

---

 

하지만 그런 로그에게도 아무렇게나 작성하는 줄 알았지만 규약이 있었으니..

그것이 바로 로그 우선 기록 규약이다.

Write-ahead logging protocol

 

로그 레코드를 기록할 때 트랜잭션이 갱신한 데이터 항목을 기록하기 전에 로그 레코드를 먼저 기록해야한다.

-> 데이터베이스에 이미 기록된 변경내용을 취소하려면 로그 레코드에 그 기록이 남아있어야 하기 때문이다.

 

이미 완료된 트랜잭션에 대해서 데이터베이스의 갱신 내용을 디스크에 반영할 때도 유용하게 사용된다.

-> 완료된 트랜잭션의 변경이 주기억장치의 버퍼에만 기록되어 있다면!!! 

즉 재가동 후 로그를 이용하여 실제 데이터베이스에 갱신 기록을 반영할 수 있다는 말!

 

 

---

 

 

그래서 로그를 이용하면 어떤 식으로 복구하는데..? 그냥 반대로 돌아가는거야?? 라고 할 수 있다.

복구에도 쓰이는 기법,기능이 따로 있다.

 

-> 각 연산은 복구 기법이 어떠냐에 따라 필요가 결정된다.

 

복구에 사용되는 연산으로는 2가지

-UNDO : 갱신된 값을 이전 상태로 되돌림

-REDO : 갱신을 재실행함

 

복구에 사용되는 기법으로는 2가지

-지연 갱신(deferred database modification)을 기반으로 한 복구

위 기법은 디스크에 데이터베이스의 갱신 내용을 저장하는 시점에 따라 복구하는 방법이다.

 

-즉시 갱신(immediate database modification)을 기반으로 한 복구

위 기법은 말 그대로 즉시.. ㅎ

 

---

 

 

절대 복구 기법에 대해서 궁금해할 것 같진 않지만... 우리가 DBMS도 아니고 궁금하지는 않지만

궁금하다고 치고 한 번 알아보자

아이 궁금해~

 

지연 갱신

-트랜잭션의 수행이 성공적으로 끝난 후(완료 후) 갱신 내용을 디스크에 반영하는 것이다.

- 완료 전에는 주기억장치의 버퍼에만 기록을 저장.

 

** 우리는 트랜잭션의 완료 상태란 의미를 배웠지만

실제로 어떤 상태가 완료되었다는 건지 모른다. 

 

** 어떤 상태를 DBMS가 완료 상태로 받아들이냐? 하면

트랜잭션의 완료는 디스크에 저장된 로그에 <T commit>이 기록되었다는 것이다.

 

그런 로그가 남으면 장점이 뭐냐고?

- 이후의 시스템 장애에 대해서도 이 기록으로 트랜잭션 완료를 알 수 있음

-장애 후에 로그에 기록된 레코드를 이용 갱신 내용들을 복구 가능

- 이 레코드가 로그에 기록되지 않았다면 트랜잭션 T가 완료된 것인지 중단된 것인지 알 길이 없음.

 

 

**복구 과정에서 

"로그 파일의 처음부터" 라는 부분은 트랜잭션의 시작을 보자는 것이다.

 

예)

 

 

 

즉시 갱신

-버퍼에서 갱신된 데이터들을 트랜잭션 실행 도중(완료되기 전) 에 디스크에 저장 가능

 

++이미 많이 설명했으니 바로 본론으로