Transaction: 프로그램의 처리 단위(e.g., 계좌 이체, 수강 신청 ..)

유저가 많아지면 데이터베이스에 동시에 접근하는 상황이 발생할 수 있다.
이 경우, 데이터베이스에 대한 Concurrency control(동시성 제어)가 필요하다.

동시성 제어

• 트랜잭션의 동시 실행과 순차적 실행에 대해 같은 결과값을 보장한다.
• 멀티 유저 환경에서 트랜잭션의 serializability를 보장한다.

📌 Transaction 개요

직원의 월급을 6% 인상해주는 쿼리가 있다고 하자. 해당 회사 직원은 500명인데 1~320번 직원까지 업데이트하고 DBMS가 갑자기 죽었다. 그러면 DBMS는 어떻게 해야할까? 만약 DBMS가 Log를 기록하지 않았다면 어떡할까?

이번에는 계좌 이체 트랜잭션의 예시다. 아마도 M.Jung이 M.Ahn에게 10만원을 보내는 것이겠다.

두 가지의 update 쿼리가 있는데 먼저 보내는 사람의 계좌에서 10만원을 빼고, 그 후 받는 사람의 계좌에 10만원을 넣는다.

만약 1번째 쿼리를 수행하고 완료 후 2번째 쿼리 시작 전 DBMS가 죽으면 어떻게 할까?

즉, DBMS는 쿼리 단위가 아닌 Transaction의 단위로 수행을 완료해야 한다. 수행 중 문제가 생겼다면 아무것도 실행하지 않은 상태로 둬야 일관성을 보장할 수 있다.

📙 Transaction 특징(ACID)

Atomicity

• 트랜잭션은 수행이 되거나 수행이 안 된다면 수행 전의 상태를 유지해야 한다.
• all or nothing

Consistency

• 트랜잭션이 완료가 되었을 때는 일관성이 유지되어야 한다.
• 트랜잭션 수행 중에는 일관성이 잠시 깨질 수 있다.(계좌 이체는 쿼리가 2개)
  

Isolation

• 한 트랜잭션이 끝날 때까지 다른 트랜잭션은 접근할 수 없다.
• Isolation level은 schema, table, tuple 등 다양하다.

Durability

• 트랜잭션이 DB 변경을 완료하면 변경 사항은 지속되어야 한다.

📙 commit vs rollback

커밋은 트랜잭션이 성공적으로 완료된 것이다.

롤백은 중간에 문제가 생긴 것, 이전 상태로 다시 되돌려야 한다.

트랜잭션의 실패 원인은 다양하다. 메인 메모리 문제 같은 system failure, 비행기 예약 트랜잭션에서 솔드 아웃된 상황에서 abort된 transacion failure, 하드웨어 이슈 같은 media failure, 커뮤니케이션 문제, 자연 재해 등등,,

데이터베이스도 결국 하나의 파일로 저장된다.
만약 트랜잭션에 성공해 메모리에 반영이 되었지만 파일, 하드디스크에 반영이 되기 전에 DBMS가 죽는 경우의 수가 있다. 또한, OS 정책에 따라 메모리 내용이 하드웨어에 반영된 경우라면 반영 이후 트랜잭션이 실패했다면 골이 아파진다.