💼 트랜잭션(Transaction)이란?

트랜잭션은 데이터베이스의 상태를 변화시키기 위해 수행되는 작업 단위입니다. 데이터의 일관성과 무결성을 보장하기 위해, 여러 SQL 명령문을 하나의 작업 단위로 묶어서 처리하는 것이죠.

---

💡 트랜잭션의 핵심 개념

트랜잭션에서 "상태를 변화시킨다"는 것은 SQL 질의를 통해 DB에 접근하여 데이터의 상태를 변화시키는 것을 의미합니다. 트랜잭션에 사용되는 주요 SQL 명령어는 다음과 같습니다:

• SELECT: 데이터를 조회
• INSERT: 데이터를 삽입
• DELETE: 데이터를 삭제
• UPDATE: 데이터를 수정

---

🛠 트랜잭션의 작업 단위란?

여러 SQL 명령문을 논리적으로 묶어서 하나의 단위로 처리하는 것을 트랜잭션이라고 합니다. 예를 들어, 사용자가 돈을 송금하는 과정에서는 다음 두 가지 작업이 이루어집니다:

1. 사용자 A의 계좌에서 만원을 차감: UPDATE 명령어로 A의 잔고를 변경
2. 사용자 B의 계좌에 만원을 추가: UPDATE 명령어로 B의 잔고를 변경

이 두 작업은 하나의 트랜잭션으로 처리됩니다. 작업 중 하나라도 실패하면 Rollback(롤백)을 통해 원래 상태로 되돌리게 되고, 모든 작업이 성공하면 Commit(커밋)을 통해 데이터베이스에 최종 반영됩니다.

---

✨ 트랜잭션의 예시

예시: 송금 프로세스

• 사용자 A가 사용자 B에게 만원을 송금한다고 가정할 때, 트랜잭션은 다음 두 가지 작업을 포함합니다:

  1. 사용자 A의 잔고에서 1만 원 차감 (UPDATE)
  2. 사용자 B의 잔고에 1만 원 추가 (UPDATE)

• 이 두 작업이 성공하면 Commit을 통해 변경 사항을 데이터베이스에 반영합니다.

• 만약 중간에 작업이 실패한다면, Rollback을 통해 사용자 A의 잔고를 원래 상태로 복구합니다.

---

✅ 결론: 트랜잭션 설계의 중요성

트랜잭션 설계를 잘하면 데이터베이스의 무결성과 일관성을 유지할 수 있습니다. 반대로 트랜잭션을 잘못 설계하면 데이터에 심각한 문제가 생길 수 있기 때문에, 신중한 설계가 필요합니다.

---

트랜잭션 특징 (ACID)

트랜잭션이 올바르게 동작하려면 네 가지 주요 특성을 만족해야 합니다. 이 특성들을 흔히 ACID라고 부르며, 이는 다음과 같은 요소들로 구성됩니다.

---

1. 원자성(Atomicity) ⚛️

• 정의: 트랜잭션 내에서 수행되는 작업들은 모두 하나의 단위로 처리됩니다. 트랜잭션이 성공하면 그 안의 모든 작업이 DB에 반영되어야 하고, 트랜잭션이 실패하면 전혀 반영되지 않아야 합니다.
• 쉽게 말해서: 트랜잭션은 "전부 또는 전무"라는 원칙을 따릅니다. 중간에 일부 작업만 반영되는 상황은 발생하지 않습니다. 예를 들어, 계좌이체가 진행 중일 때, 돈이 A의 계좌에서 빠져나갔지만 B의 계좌에 입금되지 않은 상태로 남아있으면 안 되는 것이죠.

---

2. 일관성(Consistency) 🛠️

• 정의: 트랜잭션이 수행된 후에도 데이터베이스는 항상 일관성 있는 상태를 유지해야 합니다. 이는 모든 데이터가 DB의 제약 조건을 만족해야 함을 의미합니다.
• 쉽게 말해서: 트랜잭션이 완료된 후, 데이터는 반드시 논리적이고 일관성 있는 상태여야 합니다. 예를 들어, 은행 계좌에서 마이너스 잔고가 발생하지 않도록 설계되어 있다면, 트랜잭션이 끝났을 때 그 규칙이 여전히 지켜져야 합니다.

---

3. 독립성(Isolation) 🚧

• 정의: 두 개 이상의 트랜잭션이 동시에 실행될 때, 각 트랜잭션은 서로 간섭하지 않고 독립적으로 실행되어야 합니다. 즉, 다른 트랜잭션의 연산이 완료되기 전까지는 해당 연산의 결과를 볼 수 없습니다.
• 쉽게 말해서: 동시에 여러 트랜잭션이 진행될 때, 하나의 트랜잭션이 다른 트랜잭션의 영향을 받지 않아야 합니다. 예를 들어, 한 사용자가 A 계좌에서 돈을 인출하는 동안, 다른 사용자가 같은 계좌에 입금하는 작업을 진행해도 두 트랜잭션은 서로 간섭하지 않고 독립적으로 처리됩니다.

---

4. 지속성(Durability) 🗂️

• 정의: 트랜잭션이 성공적으로 완료되면, 그 결과는 영구적으로 데이터베이스에 저장되어야 합니다. 시스템 오류가 발생하더라도 트랜잭션의 결과는 사라지지 않아야 합니다.
• 쉽게 말해서: 한 번 커밋된 트랜잭션의 결과는 DB에 영구적으로 반영됩니다. 예를 들어, 송금이 완료되었다면 서버가 꺼지더라도 송금 결과는 그대로 유지되어야 합니다.

---

Commit과 Rollback

트랜잭션을 처리하는 과정에서 Commit과 Rollback이라는 중요한 개념이 등장합니다.

---

🏁 Commit(커밋)

• 정의: 트랜잭션이 성공적으로 완료되었을 때, 그 작업이 DB에 영구적으로 반영되도록 하는 명령입니다.
• 설명: 트랜잭션이 끝난 후, 모든 데이터 변경 사항을 확정짓고 다른 트랜잭션에서 그 결과를 확인할 수 있게 만드는 것입니다. 즉, DB의 상태가 정상적으로 변경된 것을 확인하는 단계라고 볼 수 있습니다.

---

🔄 Rollback(롤백)

• 정의: 트랜잭션이 처리되는 중간에 비정상적으로 종료되었을 때, 트랜잭션을 실행하기 전 상태로 되돌리는 명령입니다.
• 설명: 트랜잭션 내에서 오류가 발생하거나 작업 중 일부가 실패할 경우, 데이터의 일관성을 유지하기 위해 최초 상태(트랜잭션이 시작된 상태)로 되돌리는 작업입니다. 예를 들어, 송금 중 오류가 발생하면, 돈이 차감된 계좌에서 다시 돈을 원래 상태로 복구합니다.

---

❓ 상황별 DB 문제 해결 능력

트랜잭션이 이런 특성을 모두 만족해야 데이터베이스의 일관성과 안정성을 보장할 수 있습니다. 만약 이런 상황이 주어졌을 때, DB에서 어떻게 문제를 해결할지에 대해 생각해 보는 것도 좋습니다. 트랜잭션의 원리를 이해하면 복잡한 데이터 처리 상황에서도 적절한 해결책을 제시할 수 있게 될 것입니다.

---

🚀 Transaction 관리를 위한 DBMS의 전략

DBMS가 트랜잭션을 관리하는데 필요한 핵심 개념은 크게 두 가지입니다: DBMS의 구조와 Buffer 관리 정책. 이 두 가지를 이해하면 DBMS가 어떻게 데이터를 효율적으로 처리하고 복구하는지 알 수 있습니다.

---

1. DBMS의 구조 🏗️

DBMS는 크게 두 가지 시스템으로 나눌 수 있습니다:

• Query Processor (질의 처리기): 사용자의 SQL 질의를 해석하고 실행
• Storage System (저장 시스템): 데이터를 실제로 저장하는 시스템

📂 입출력 단위: 페이지(Page)

DBMS는 데이터를 읽고 쓸 때 고정된 크기의 페이지 단위로 처리합니다. 즉, 데이터를 처리할 때 항상 일정한 페이지 크기로 디스크에서 데이터를 읽고 쓰는 구조입니다.

💾 저장 공간

저장 공간은 두 가지로 나뉩니다:
1. 비휘발성 저장 장치(예: 디스크)에 저장
2. 메인 메모리(Main Memory)에 저장

이렇게 데이터를 디스크와 메인 메모리에 나누어 저장함으로써, DBMS는 빠른 데이터 처리와 안정적인 저장을 동시에 달성할 수 있습니다.

---

2. Page Buffer Manager (버퍼 관리자) 💡

Page Buffer Manager는 DBMS의 저장 시스템(Storage System)에서 중요한 역할을 합니다. 이는 메인 메모리에 있는 페이지를 관리하는 모듈로, 데이터 페이지를 어떻게 처리하고 캐시할지 결정합니다.

🔄 버퍼 관리 정책

버퍼 관리 정책에 따라 UNDO 및 REDO와 같은 복구 작업이 요구될 수 있습니다.

• UNDO: 트랜잭션이 실패했을 때 이전 상태로 되돌리는 작업
• REDO: 트랜잭션이 성공했을 때 변경된 내용을 다시 반영하는 작업

이 정책은 트랜잭션 관리에서 매우 중요한 결정 요소입니다. 트랜잭션 처리 중 발생할 수 있는 오류에 대비해 데이터를 어떻게 캐시하고, 언제 메모리에서 삭제할지를 결정합니다.

---

✨ 결론: 트랜잭션 관리의 중요성

DBMS는 질의 처리기와 저장 시스템이라는 두 축을 중심으로 데이터를 처리하며, 그 중 Page Buffer Manager는 트랜잭션 관리에서 핵심적인 역할을 합니다. 이 모듈이 데이터를 어떻게 처리하느냐에 따라 DB의 안정성과 성능이 결정됩니다. 트랜잭션 중 발생할 수 있는 오류에 대비한 복구 작업(UNDO/REDO)을 원활하게 진행하기 위해서는, 적절한 버퍼 관리 정책이 필요합니다.

---

🔄 UNDO: 트랜잭션 복구의 핵심

💡 UNDO의 기본 개념

UNDO는 트랜잭션이 정상적으로 완료되지 않았을 때, 이미 변경된 데이터를 원래 상태로 복구하는 작업입니다. 트랜잭션이 중간에 실패하거나 오류가 발생할 경우, 그동안 디스크에 기록된 변경 사항이 있을 수 있기 때문에 이를 복구해야 하는데, 이 과정을 UNDO라고 합니다.

---

🤔 왜 UNDO가 필요한가?

DBMS에서 데이터를 처리할 때, 버퍼는 트랜잭션과는 별개로 작동합니다. 즉, 트랜잭션이 아직 완료되지 않았더라도 버퍼에서 디스크로 데이터를 쓸 수 있습니다. 이것은 데이터의 처리 성능을 높이기 위한 방식입니다. 하지만 이로 인해 문제가 발생할 수 있습니다.

• 버퍼 교체는 트랜잭션의 완료 여부와는 관계없이 발생합니다. 버퍼 메모리 공간이 꽉 차면, 더 이상 데이터를 저장할 수 없기 때문에 현재 버퍼에 있는 데이터를 디스크에 기록하게 됩니다. 이 과정에서 트랜잭션이 아직 끝나지 않았음에도 불구하고 수정된 데이터가 디스크에 기록될 수 있습니다.
• 만약 트랜잭션이 중간에 실패하거나 취소되면, 디스크에 기록된 변경된 데이터는 원래 상태로 복구되어야 합니다. 그렇지 않으면 데이터 무결성이 깨질 수 있기 때문입니다. 이때, 이미 기록된 데이터를 원래대로 되돌리는 작업이 바로 UNDO입니다.

---

🔄 UNDO 정책

UNDO는 데이터가 언제 디스크에 기록되는가에 따라 두 가지 정책으로 나눌 수 있습니다.

1. 💼 steal 정책

   • 이 정책에서는 수정된 페이지를 언제든지 디스크에 기록할 수 있습니다.
   • 즉, 트랜잭션이 완료되지 않았더라도 버퍼에서 자리가 부족하면 디스크에 바로 데이터를 기록하게 됩니다.
   • 대부분의 DBMS는 steal 정책을 사용합니다. 왜냐하면 버퍼 메모리 공간이 한정되어 있기 때문에 데이터를 빠르게 디스크에 옮겨야 하기 때문입니다.
   • 하지만, 트랜잭션이 실패할 경우 이미 디스크에 기록된 데이터를 원래 상태로 되돌리는 UNDO 작업이 필수적입니다. 이 작업을 위해 UNDO logging이 필요하며, 시스템은 복구를 위해 이 로그를 활용합니다.

2. 🔐 no-steal 정책

   • 이 정책에서는 수정된 페이지가 트랜잭션이 완료되기 전까지 디스크에 기록되지 않습니다.
   • 즉, 트랜잭션이 끝날 때까지 모든 데이터를 버퍼에 유지하고 있다가, 트랜잭션이 성공적으로 끝나면 그때서야 디스크에 데이터를 기록합니다.
   • 이 경우 트랜잭션이 실패해도 이미 디스크에 기록된 데이터가 없기 때문에 UNDO 작업이 필요하지 않습니다.
   • 그러나, 매우 큰 메모리 공간이 필요합니다. 왜냐하면 트랜잭션이 끝날 때까지 모든 데이터를 메모리에 유지해야 하기 때문입니다.

---

🔄 REDO: 트랜잭션 복구의 핵심

REDO는 이미 커밋된 트랜잭션의 수정 사항을 다시 반영하는 복구 작업입니다. 트랜잭션이 성공적으로 커밋되었지만, 데이터가 완전히 디스크에 기록되지 않았다면 시스템 오류나 장애가 발생했을 때 REDO 작업을 통해 수정된 데이터를 디스크에 반영합니다.

---

REDO: 왜 필요한가?

트랜잭션이 완료된 시점에도 데이터가 반드시 디스크에 기록되지는 않습니다. 버퍼 관리 정책에 따라 수정된 페이지가 디스크에 기록되는 시점이 달라지며, 이로 인해 REDO 작업이 필요한 상황이 발생할 수 있습니다.

---

REDO와 Buffer 관리 정책

DBMS는 트랜잭션이 종료될 때 해당 트랜잭션이 수정한 페이지를 디스크에 기록할지를 결정하는 Buffer 관리 정책을 가지고 있습니다. 이 정책에 따라 REDO 작업의 필요 여부가 결정됩니다.

---

1. FORCE 정책 🛠️

• FORCE 정책은 트랜잭션이 커밋되는 순간 수정된 모든 페이지를 디스크에 즉시 기록하는 방식입니다.
• 트랜잭션이 커밋되면 이미 모든 데이터가 디스크에 반영되어 있기 때문에 REDO 작업이 필요 없습니다.

2. no-FORCE 정책 🚫

• no-FORCE 정책은 트랜잭션이 커밋된 후에도 수정된 페이지가 디스크에 기록되지 않을 수 있는 방식입니다.
• 이 경우 시스템 장애가 발생하면 REDO 작업을 통해 커밋된 수정 사항을 다시 디스크에 반영해야 합니다.
• no-FORCE는 대부분의 DBMS가 사용하는 정책으로, 수정된 데이터를 즉시 디스크에 기록하지 않고 일정 시간이 지난 후 기록함으로써 I/O 성능을 최적화합니다.