회복과 병행제어

👍 Warming Up - 트랜잭션이란?

 

👊 트랜잭션 : 데이터베이스에서 하나의 작업을 처리하기 위해 필요한 연산들의 집합

 

회복과 병행제어를 알기 위해서는 트랜잭션을 먼저 알아야 한다.

쉽게 얘기하면 트랜잭션은 데이터베이스의 활용을 절차적 관점에서 본 것이다.

트랜잭션은 최종적으로 COMMIT 되거나 ROLLBACK 되어야 한다.

하나의 트랜잭션 안에 마지막 연산까지 정상적으로 완료된 상태를 "부분완료"라고 하는데, 아무리 마지막 연산까지 끝냈다고 해서 전체 트랜잭션이 다 성공했다고 보장할 수 없기 때문이다.

정말 오류가 아예 없었다면 COMMIT으로 트랜잭션 결과를 데이터베이스에 반영한다.

하지만 "부분완료" 상태에서 오류가 발생하면 "실패" 단계로서 ROLLBACK을 실행하여 해당 트랜잭션이 실행되기 전 상태로 되돌린다.

---

👊 트랜잭션의 성질(4)

 

🙌 원자성(Atomicity)

트랜잭션은 오류없이 완벽하게 완료되거나, 아니면 조금의 오류가 있다면 아예 실행되기 전 단계로 복원되어야 한다. All or Nothing

예를 들어, A -> B -> C 순서로 실행되는 트랜잭션이 있는데 B에서 오류가 났다면, 해당 트랜잭션은 모두 ROLLBACK으로 전체실행취소되어야 한다.

 

🙌 일관성(Consistency)

같은 트랜잭션으로 연관되어 있다면, 실행 결과도 모두 일관되어야 한다.

예를 들어, A가 B에게 송금을 한다면 오고가는 돈의 합이 같아야 한다.

 

🙌 격리성(Isolation, 독립성)

하나의 트랜잭션이 완벽히 실행이 완료될 때까지, 다른 트랜잭션이 끼어들지 못한다.

 

🙌 영속성(Durability, 지속성)

트랜잭션의 결과는 무슨 일이 있더라도 손상되어서는 안된다.

은행 같이 중요한 곳은 영속성을 지키기 위해 다중 백업을 거친다.

---

👍 회복이란? - 트랜잭션을 실행하는 도중에 에러가 발생하여 DB가 손상되면, 손상되기 이전의 정상 상태로복구시키는 것

 

👊 에러의 종류

 

🙌 실행장애

응용프로그램 내 코드로 명시되어 있는 경우로, 사용자가 ROLLBACK 명령을 내려 계획적으로 종료시킨 상태

 

🙌 트랜잭션장애

연산 중 발생한 오류로, 계획되지 않은 비정상적인 종료 상태

 

• 잘못된 데이터의 입력
• 데이터의 부재
• 오버플로우
• 자원의 한계 초과요청
• 0으로 나누는 연산

 

🙌 시스템장애

DB에는 손상을 주지 않지만, CPU 고장, 메모리 또는 소프트웨어 오류로 트랜잭션의 실행을 방해하는 상태

 

🙌 미디어장애

하드디스크의 손상으로 DB에 손상을 주는 상태

 

 

이러한 에러들을 해결하는 것을 "회복"이라고 한다.

---

👍 회복에는 중복저장기법으로 덤프 & 로그가 있다

 

👊 덤프

 

덤프트럭마냥 데이터베이스 전체를 주기적으로 퍼다가 다른 저장장치에 복사해놓고, 오류가 발생하면 복사본을 원본으로 덮어씌우는 기법으로, 그림자 페이징을 이용한다.

 

🙌 그림자 페이징(Shadow Paging)

트랜잭션이 실행되는 동안 DB를 일정 크기의 페이지(DB저장단위)와 그 복사본인 "그림자 페이지"로 보관하는 방법이다.

DB에 변경사항이 생길 때는 원본 페이지를 쓰고, 회복이 필요할 때는 그림자 페이지를 쓴다.

---

👊 로그

 

데이터베이스에 변경값(접속하고 가한 모든 행동)을 로그파일에 기록해놓고, 오류가 나면 로그파일을 분석하여 이전 값을 찾아냄

 

예를 들어 다음과 같은 트랜잭션을 기록한 로그가 있다고 가정하자.

<Ti, Start> : 트랜잭션 Ti의 실행이 시작됨
<Ti, Xj, V1, V2> : Ti 중 Xj 연산이 실행됨으로써 V1가 V2로 변함
<Ti, Commit> : 트랜잭션 Ti가 정상완료되어 커밋함

만약 에러 또는 원치 않은 결과가 나왔다면, 사용자는 다음과 같이 로그파일을 분석하여 원래 DB상태로 "회복"할 수 있다.

 

🙌 Redo와 Undo

• Redo(재수행) : 이미 COMMIT을 한 후에 DB의 손상이 일어난 경우, V1이 Xj를 거쳐 V2로 바뀌는 것이 정상적인 것인지, 그리고 이후에 일어난 DB 손상의 영향을 받았는지 해당 트랜잭션을 다시 수행해보는 것
• Undo(취소) : COMMIT까지 못가고 도중에 DB의 손상이 일어난 경우, 해당 트랜잭션이 실행되기 전의 상태로 되돌리는 것

 

🙌 즉시갱신 : 트랜잭션 안에 있는 각 연산이 끝날 때마다 로그파일에 기록과 함께 DB에 적용

트랜잭션이 COMMIT 되기 전에 에러가 발생하면, 이미 중간중간 DB가 갱신되어있기 때문에 해당 트랜잭션을 Undo하고

트랜잭션이 COMMIT 된 후에 에러가 발생하면, 해당 트랜잭션을 Redo한다.

 

🙌 지연갱신 : 트랜잭션 안에 있는 각 연산이 끝나면 로그파일에 기록만 하고, 해당 트랜잭션 전체가 COMMIT되면 DB에 적용

트랜잭션이 COMMIT 되기 전에 에러가 발생하면, 아직 DB 갱신이 이루어지지 않았으므로 로그기록을 삭제하고

트랜잭션이 COMMIT 된 후에 에러가 발생하면, 해당 트랜잭션을 Redo한다.

지연갱신은 트랜잭션이 COMMIT되어야 트랜잭션 내 모든 연산의 로그기록을 반영하기 때문에, 중간에 에러가 발생하면 Undo할 필요없이 로그기록만 삭제하면 된다.

그래서 지연갱신기법을 "No-Undo"기법이라고도 한다.

 

🙌 검사시점회복 : 즉시갱신이든 지연갱신이든, 에러가 발생하면 에러발생 이전에 COMMIT이 이미 끝난 트랜잭션들은 모두 Redo의 대상이 된다.

하지만 Redo의 대상이 수백개라면 굉장히 비효율적일 것이다.

그래서 일정 주기마다 검사시점(Check Point)을 만들고, 이상이 없었던 검사시점은 Redo 대상에서 제외하는 것이 "검사시점회복" 기법이다.

---

👍 병행제어란? - 여러 명이 같은 DB를 사용하게 되면 발생하게 될 문제를 방지하는 것

 

👊 어떤 문제가 발생하길래?

 

🙌 갱신분실(Lost Update)

두 개 이상의 트랜잭션이 같은 자료를 동시에 공유하여 업데이트 할 때 갱신결과의 일부가 분실되는 현상

예를 들어 한 사람은 A에 100을 더하고 다른 사람은 A에 50을 더한다면, 나중에 입력된 값만 적용되는 현상이다.

 

갱신분실은 하나의 트랜잭션이 완전히 끝나고 그 다음 트랜잭션을 실행하는 "직렬 스케쥴"로 해결할 수 있다.

 

🙌 비완료 의존성(Uncommitted Dependency)

하나의 트랜잭션 수행이 실패(또는 ROLLBACK)했는데 그 트랜잭션이 회복되기 전에 다른 트랜잭션이 실패(또는 취소)결과를 참조하는 현상

 

🙌 모순성(Inconsistency)

서로 다른 트랜잭션이 같은 데이터를 참조할 때, 변경되기 전의 값이 필요하지만 다른 트랜잭션의 결과 때문에 영향을 받는 현상

 

🙌 연쇄복귀(Cascading Rollback)

병행 수행되던 트랜잭션들 중 하나에 문제가 생겨 ROLLBACK을 걸었는데, 다른 트랜잭션도 같이 ROLLBACK되는 현상

 

여러 사용자가 동시에 DB에 접근하면 많은 트랜잭션이 발생하는데, 동시에 실행되는 트랜잭션들을 일관성 있게 처리하고 위 문제들에 대처하기 위해서는 트랜잭션 간 상호작용을 제어해야 한다.

따라서 병행제어가 필요하다.

---

👍 병행제어에는 어떤 것이 있는가?

 

👊 스케쥴

🙌 직렬 스케쥴

트랜잭션의 연산을 모두 순차적으로 실행하는 것

🙌 비직렬 스케쥴

트랜잭션 병렬 수행하는 스케쥴, 인터리빙방식

---

👊 로킹(Locking, 자물쇠)

공중화장실처럼 하나의 트랜잭션이 데이터를 사용중이면 다른 트랜잭션은 문이 잠겨있어 들어오지 못함.

하지만 사용중인 트랜잭션이 해제되지 않으면 교착상태(Dead-Lock)에 빠져 무한정 기다려야 함.

• 성장(확장)단계(Growing Phase) : 잠그기
• 축소단계(Shrinking Phase) : 잠금해제
• 전용로크 : 읽기 + 쓰기 허용
• 공용로크 : 읽기만 허용

---

👊 타임스탬프(Time-Stamp, 번호표)

은행처럼 트랜잭션들에게 번호표를 부여하여 순서에 맞게 실행함.

트랜잭션이 시스템에 들어온 시간순서로 부여하거나 또는 그 시간의 CPU 클럭주파수로 부여함.