Week 12 - Transaction and Recovery

Transaction

다양한 데이터 항목에 Access 하고 Update 할 수 있는 프로그램 실행 단위

2가지 주요 문제

1. Failure of various kinds, such as hardware failures and system crashes
2. concurrent execution of multiple transactions (다중 트랜잭션의 동시 실행)

Atomicity requirement

System 은 partially executed transaction 의 업데이트가 데이터베이스에 reflect 되지 않도록 보장
→ 트랜잭션의 모든 작업이 성공적으로 완료되거나 전혀 실행되지 않도록 보장하는 속성
→ 즉, 트랜잭션의 한 부분이 실패하면 전체 트랜잭션이 롤백되고 변경 사항이 취소

Durability Requirement

SW 또는 HW 오류가 발생해도 Transaction 에 의한 DB 업데이트는 지속 보장
→ 트랜잭션이 커밋되면 정전이나 시스템 충돌 중에도 변경 사항이 지속, 손실되지 않도록 보장하는 속성
→ 트랜잭션이 커밋되면 데이터베이스 관리 시스템(DBMS)은 변경 사항을 영구 저장소에 기록

Consistency Requirement

Transaction 실행에 따라 A와 B 의 합이 변하지 않음
일반적으로 Consistency Requirements 는 다음과 같음

• Transaction 은 Consistent Database 를 볼 수 있다
• Transaction 실행 중에 Database 가 Temporarily Inconsistent (일시적으로 일관) 할 수 있음
• Transaction 이 성공적으로 완료되면 데이터베이스가 Consistent 해야함
  → 트랜잭션이 정의된 모든 제약 조건과 규칙을 준수하면서 데이터베이스를 하나의 일관된 상태에서 다른 일관된 상태로 이동하도록 보장하는 속성
  (예를 들어, 재고 관리 시스템에서 제품의 재고 수준이 음수가 될 수 없다는 제약 조건이 있습니다. 트랜잭션에서 재고 수준을 0 이하로 낮추려고 시도하면 일관성은 트랜잭션을 중단하여 재고 데이터의 일관성을 보장)

Isolation Requirement

Isolation 은 Transaction 을 연속적으로 실행함으로써 간단하게 보장 가능

• 예시 : 3번 6번 사이에 T2 가 부분적으로 업데이트된 데이터베이스에 access 하도록 허용되면 일관성이 없는 데이터베이스를 보게된다 (A+B )
  → 각 트랜잭션이 다른 동시 트랜잭션과 격리되어 이를 인식하지 못하도록 하는 속성

ACID Properties

Transaction : 다양한 데이터 항목에 Access 하고 Update 할 수 있는 프로그램 실행 단위

Atomicity

: Transaction 의 모든 Operation 은 Database 에 모두 반영되거나 아무것도 반영되지 않음

Consistency

: Transaction 을 따로 Isolation 해서 실행하면 Database 의 Consistency 를 유지

Isolation

: 여러 Transaction 은 concurrently (동시에) 실행될 수 있으나 각 Transaction 은 동시에 실행되는 다른 Transaction 을 인식하지 못하고, 중간 Transaction 결과는 동시에 실행되는 다른 Transaction 으로부터 숨겨져야함
ex : 모든 트랜잭션 쌍 Ti와 Tj에 대해 Ti에게 Tj는 Ti가 시작하기 전에 실행을 완료했거나 Ti가 완료된 후에 실행을 시작한 것처럼 보입니다.

Durabillity

: Transaction 이 성공적으로 완료된 이후에는 시스템 장애가 발생하더라도 변경한 내용이 지속

Transaction State

Active

: Initial State. Transaction 이 Executing 중에는 Active 상태 유지

Partially Committed

: After the Final Statement 가 Execute 된 이후

Failed

: Normal Execution 이 더 이상 진행되지 않는 것을 발견한 이후

Aborted

: Transaction 이 Rollback
Database 가 Transaction 시작 이전으로 복원
중단 후 2가지 옵션

1. Restart the Transaction
2. Kill the Transaction

Committed

: 성공적인 Completion 이후

Failure Classification

Transaction failure
Logical Errors : Transaction cannot complete due to some internal error condition
System Errors : the database system must terminate an active transaction due to an error condition

System Crash : 정전 또는 기타 하드웨어 또는 소프트웨어 오류로 인해 시스템이 충돌하는 경우
Fail-Stop Assumption : 비휘발성 스토리지 콘텐츠는 시스템 충돌로 인해 손상되지 않는다고 가정
→ DB 시스템은 디스크데이터의 손상을 방지하기 위해 많은 Integrity Check 을 진행
Disk Failure : Head crash 등 유사한 디스크 장애로 인해 디스크 스토리지의 전체 또는 일부가 파괴

Recovery Algorithm

Transaction 가 계정 A 에서 B 로 전송
→ 1. Subtract 50 from A 2. Add 50 to B

2개의 파트 존재

1. Normal Transaction Proces 과정에서 실패에 대한 복구를 위한 충분한 정보를 보장하는 Action
   
2. Atomicity, Consistency, Durability 를 보장하는 상태로 복구하는 것이 실패한 상황에서의 Action
   

Recovery at Storage Level

Volatile Storage :

• Does not survive system crashes (시스템 충돌에서 살아남지 못함)
• Main Memory, Cache Memory

Nonvolatile Storage :

• Survises system crashes
• disk, tape, flash memory, non-volatile RAM
• 하지만 그래도 데이터를 잃을 수 있음

Stable Storage :

• 모든 장애에서 살아남는 신화적인 형태의 저장소
• 독립된 비휘발성 미디어에 여러 개의 사본을 유지해서 Approximate
• 안정적인 저장소를 구현하는 방법은 책을 참고

Stable-Storage Implementation

분리된 디스크에 각 블록에 대한 여러개의 사본을 유지

To recover from Failure

1. First find inconsistent blocks
   • Expensive : Compare the two copies of every disk block.
   • Better :
     1. Record in-progress disk writes on non-volatile storage (Flash, Non-volatile RAM)
     2. Use this information during recovery  to find blocks that may be inconsistent, and only compare copies of these.
     3. Used in hardware RAID systems
2. 일치하지 않는 블록의 복사본 중 하나에 오류 (bad checksum) 가 있는 것으로 감지
   → 다른 복사본으로 Overwrite
   → 서로 다르지만 Error 가 없을 경우 : Second 를 First 로 통합

데이터 전송 중 실패로 사본이 서로 다를 수 있음

• 블록 전송 은

1. Successful Completion
2. Partial Failure : destination block has incorrect information
3. Total Failure : destination block was never updated

데이터 전송 중 실패로부터 Storage media 보호
출력 작업을 실행 : (각 블록에 두 개의 복사본이 있다고 가정)

1. Write the information onto the first physical block.(첫 번째 물리 블록에 정보 쓰기)
2. 첫 번째 쓰기가 성공적으로 완료되면 동일한 정보를 두 번째 물리 블록에 작성
3. 성공적으로 두번째 쓰기를 작성해야 결과를 출력
   

Recovery and Atomicity

데이터 전송 중 저장 매체 장애로부터 보호
HW : Add Supercapacitor in SSD

SW :

1. Write the information onto the first physical block.(첫 번째 물리 블록에 정보 쓰기)
2. 첫 번째 쓰기가 성공적으로 완료되면 동일한 정보를 두 번째 물리 블록에 작성
3. 성공적으로 두번째 쓰기를 작성해야 결과를 출력

Database Solution

장애 발생 시에도 원자성을 보장하기 위해 데이터베이스 자체를 수정하지 않고 안정적인 저장소에 수정사항을 설명하는 정보를 먼저 출력

Log-based recovery mechanism 을 자세히 봄
실제 복구 알고리즘 제시
잘 사용하지 않는 대안 : Shadow copy & Shadow paging = Double Write

Log-Based Recovery

Log : log record 에 대한 sequence
Record 는 데이터베이스의 Update activity 에 대한 정보를 가지고 있음
Log : keep on stable storage

Undo Redo Operation

Undo() : 마지막 로그 레코드에서 거꾸로 돌아가면서 업데이트된 모든 데이터 항목의 값을 이전 값으로 복원
각 항목 X 가 이전 값 V 로 복원될 때마다 특수 로그 레코드 가 쓰여짐
Log Record 가 작성됨

Redo() : T i 에 대한 첫 로그 레코드에서 앞으로 돌아가면서 T i 가 업데이트한 모든 데이터 항목의 값을 새로운 값으로 설정
→ 이 때는 logging이 되지 않음

When Recovering after failure

트랜잭션 에 레코드가 포함되어 있어도, 이나 가 포함되지 않으면 실행 취소를 해야한다

트랜잭션 에 레코드가 포함되어 있고, 이나 가 포함되어 있으면 다시 실행해야한다.

Checkpoints

로그에 기록된 모든 Transaction 을 다시 실행하거나 실행 취소하는 것은 매우 느릴 수 있음

• 시스템이 오랫동안 실행된 경우 로그 전체를 처리하는 데 시간이 많이 걸림
• 이미 데이터베이스에 업데이트를 출력한 Transaction 을 불필요하게 다시 실행할 수 있음

주기적인 Checkpointing Performing 을 통해 Streamline Recovery Procedure (복구 절차 간소화)

1. 현재 메인 메모리에 있는 모든 로그레코드를 안정적인 저장장치에 출력
2. 수정된 모든 버퍼 블록을 디스크에 출력
3. 체크포인트 시점에 모든 Transaction 의 목록인 로그 레코드를 안정적인 저장 장치에 작성
4. 체크포인팅을 수행하는 동안 모든 업데이트 중지

시점에서는 는 저장되어있었기 때문에 두개는 redone, 는 Undone (수행 X)

---

“이 글은 Obsidian 에서 작성되어 업로드 되었습니다”