ACID

1. Transactions 👩‍💻

트랜잭션이란 쪼갤 수 없는 업무 처리의 최소 단위를 말한다. 예를 들어 ‘A의 계좌에서 B의 계좌로 만 원을 송금한다’에서 2개의 작업이 존재한다. ‘A의 계좌에서 만 원을 인출한다’, ‘B의 계좌에 만 원을 입금한다.’ 그리고 이 두 작업은 별개일 수 없다. A의 계좌에서 인출은 했으나 B의 계좌로 입금이 되지 않거나, A의 계좌에서 인출 없이 B의 계좌로 입금이 되는 일이 존재해서는 안 된다. 이 둘은 분리될 수 없으며 하나의 단일 거래 내역으로 처리되어야하는 쪼갤 수 없는 업무 처리의 최소 단위가 된다. 트랜잭션 처리가 정상적으로 완료될 경우 commit 을 하고, 오류가 발생할 경우 rollback 을 한다.

이것은 DBMS 에서 매우 중요한 개념으로 DB 서버에 여러 클라이언트가 동시에 접속해 데이터를 처리할 때(concurrent 프로그래밍) 발생할 수 있는 데이터 오류를 제어하기 위해 사용되며 트랜잭션은 ACID 를 만족해야한다.

---

2. ACID 👩‍💻

1. Atomicity (원자성)

Atomicity 는 트랜잭션이 더 이상 작게 쪼갤 수 없는 최소한의 업무 단위로 명령이 모두 반영되거나, 모두 반영되지 않아야 한다. 부분적으로 실행되거나 중단되지 않아야 함을 의미하며 작업 내역은 rollback 된다.

기본적으로 rollback 은 트랙잭션의 모든 작업 내역을 되돌리는데, 오류가 발생하기 이전 지점을 정확히 알고 있다면 이 지점을 save point 로 지정하면 이 지점까지 rollback 이 되고, 여기서부터 업무를 다시 진행할 수 있다. 물론, 오류 발생 지점을 다시 진행한다는 것이지 이 상태를 commit 한다는 의미는 아니다.

Atomicity 는 한 마디로 정의하면 All or Nothing 의 개념이다.

2. Consistency (일관성)

트랜잭션이 테이블에 변경 사항을 적용할 때 특정 조건을 두고, 그 조건을 만족하는 데이터만 변경을 허용해 데이터의 손상이나 오류를 방지한다. 예를 들어 모든 계좌는 잔고가 있어야 한다는 무결성 제약 조건이 있다면, 이를 위반하는 트랜잭션은 중단된다.

3. Isolation (독립성)

여러 사용자가 같은 테이블에서 모두 동시에 읽고 쓰기 작업을 할 때, 각각의 트랜잭션을 격리해 서로 방해하거나 영향을 미치지 않도록 한다. 각각의 요청이 실제로는 모두 동시에 발생하더라도, 마치 하나씩 발생하는 것처럼 발생할 수 있습니다. 즉, 트랜잭션의 실행내역은 연속적이어야함을 의미한다.

예를 들어 위 ‘A의 계좌에서 B의 계좌로 만 원을 송금한다’ 경우를 보면, ‘A의 계좌에서 만 원을 인출한다’, ‘B의 계좌에 만 원을 입금한다.’ 2개의 작업은 하나의 트랜잭션이므로, 이 트랜잭션이 종료되기 전 은행원이 이체 과정을 볼 수 없다. A의 계좌에서 B의 계좌로 만 원을 송금한다 와 은행원이 A의 인출을 확인한다는 서로 다른 트랜잭션으로 격리되어 있기 때문이다.

4. Durability (지속성)

성공적으로 수행된 트랜잭션은 영구적으로 반영되어야한다. 즉, 성공한 트랜잭션은 안정적으로 보존되어야한다. 시스템 문제, DB 일관성 체크 등을 하더라도 유지외어야 함을 의미한다. 전형적으로 모든 트랜잭션은 로그로 남고, 시스템 장애 발생 전 상태로 되돌릴 수 있다. 따라서 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있다.

---

3. Commit and Rollback 👩‍💻

• Commit: INSERT, UPDATE, DELETE 와 같은 DB의 데이터를 변경하는 작업이 모두 종료된 후 결과가 지속성을 갖도록 저장함을 의미한다. Commit 이 이루어지기 전 모든 작업은 임시적임을 의미한다.
• Rollback: ACID 위반 또는 사용자 임의로 트랜잭션의 작업 내역을 되돌림을 의미한다. 별도의 save point 가 없다면 트랜잭션이 시작 시점으로 되돌린다.

---

4. Recovery

데이터베이스는 데이터의 안정성과 신뢰성을 위해 ACID 원칙을 적용해 트랜잭션을 관리한다. 하지만 외부 요인에 의해 트랜잭션 결과가 잘못될 수도 있고, 잘못된 트랜잭션의 발생으로 강제로 되돌려야 할 수도 있다. 이 때 사용하는 것이 데이터베이스 회복 기법으로, 트랜잭션이 완료된 후(commit) 수행하는 것과 이전에 수행하는 것 모두 존재한다.

1. Database Failure Types

• Transaction Failure: 트랜잭션의 실행 시 논리적 에러로 발생할 수 있는 에러 상황.
• System Failure: 하드웨어 시스템 자체에서 발생할 수 있는 에러 상황.
• Media Failure: 디스크 자체의 손상으로 발생할 수 있는 에러 상황.

2. Database Recovery Performance

• Undo: 일반적으로 우리가 워드 등의 문서를 사용할 때 되돌리기 하는 것을 생각하면 된다. 트랜잭션 로그가 기록되므로 에러와 관련된 변경 내역을 되돌려 취소함으로써 에러를 복구한다. 트랜잭션의 작업 자체에 문제가 있을 경우 사용한다.
  트랜잭션 로그 파일을 이용한 복구시 일반적으로 트랜잭션의 로그 파일에 start 는 있고, commit 이 없는 경우 수행한다.
• Redo: 에러가 발생한 트랜잭션을 다시 실행한다. 트랜잭션의 작업 자체는 문제가 없고, 외부 요인에 의한 에러일 경우 이를 다시 수행함으로써 에러를 복구한다. 예를 들어 파일을 전송하는 데 인터넷이 끊겨 취소된 전송 내역을 다시 실행하는 것과 같다고 볼 수 있다. 트랜잭션 로그 파일을 이용한 복구시 일반적으로 트랜잭션의 로그 파일에 start 와 commit 이 모두 있는 경우 수행한다.

3. Database Recovery Techniques

• 로그 기반 회복 기법에는 지연갱신 회복 기법Deferred Update 와 즉시갱신 회복 기법Immediate Update가 있다.
• 검사점 회복 기법Checkpoint Recovery 은 검사점 전/후를 기준으로 해당 시점까지만 Redo 또는 Undo 를 수행한다.
• 그림자 페이징 회복 기법Shadow Paging Recovery 은 트랜잭션이 시작되는 시점에 실행되는 메모리 상의 Current Page Table 과 동일한 Shadow Page Table 를 물리 디스크에 생성한다. 만약 트랜잭션이 성공할 경우 Current Page Table 을 취하고, 실패할 경우 Shadow Page Table 을 취한다.

---

Reference

1. “ACID properties of transactions.” IBM. Jan. 10, 2023, ACID.
2. “트랜잭션.” 해시넷. Dec. 19, 2022, 트랜잭션.
3. “데이터베이스 회복.” IT위키. Oct. 22, 2020, 데이터베이스 회복.