[DataBase] DB를 지탱하는 트랜잭션
데이터 베이스는 우리가 흔히 사용하는 파일 시스템과는 달리 기본적으로 4가지 특징이 존재한다. 1) 실시간 접근성 2) 계속적인 변화 3) 동시 공유 4) 내용에 따른 참조 이외에도 디비의 장점이라고 볼 수 있는 부분으로는 데이터의 일관성과 지속성이라고 볼 수 있다.
하지만 보통 DBA나 데이터 베이스를 깊게 다루지 않는 이상. 개발을 하는 입장에서는 DBMS가 어떻게 데이터의 일관성과 지속성을 관리하는지에 잘 모르는 경우가 많다. (나도 자세히 알지는 못한다.) 그리고 아직까지 짧은 나의 개발 경험상 개발자 입장에서는 질의에 대한 성능 최적화 부분에만 튜닝을 잘해주면 됐다.
그러나, DBMS가 어떻게 동작하고, 데이터를 관리하는지에 대해 한층 깊은 이해도가 생긴다면, 추후 데이터베이스를 활용한 개발 측면에서 마주칠 문제들에 대해서 좀 더 빠르게 대처하고 방지할 수 있지 않을까 생각한다.
그래서 이번 포스팅은 데이터베이스가 항상 정확하고 일관된 상태를 유지할 수 있도록 다양한 기능을 제공하는 것들 중 가장 중요한 부분인 "트랜잭션"에 대해 정리해볼까 한다.
트랜잭션이란?
트랜잭션은 하나의 작업을 수행하기 위해 필요한 데이터베이스의 연산들을 모아놓은 것으로, 데이터베이스에서 논리적인 작업의 단위이며 장애가 발생했을 때 데이터를 복구하는 작업의 단위이다.
데이터베이스는 정확한 데이터를 유지 및 오류 할 발생 시 빠르게 복구하고, 데이터베이스가 항상 정확하고 일관된 상태를 유지할 수 있도록 다양한 기능을 제공하는데, 그 중심에서 가장 중요한 역할을 하는 것이 바로 트랜잭션이다.
- 트랜잭션이라는 것을 관리함으로써 데이터 베이스의 회복과 병행 제어가 가능.
데이터베이스 연산은 SQL문으로 표현되므로 트랜잭션을 작업 수행에 필요한 SQL 문들의 모임으로 이해해도 됨.
트랜잭션의 모든 명령문이 완벽하게 처리되거나 하나도 처리되지 않아야 데이터 베이스 모순이 없는 일관된 상태를 유지.
트랜잭션은 데이터베이스에 장애가 발생했을 때 복구작업을 수행하거나, 다수의 사용자가 동시에 사용할 수 있도록 제어 작업을 하는 데 중요한 단위로 사용.
트랜잭션의 특징 (ACID)
트랜잭션이 성공적으로 처리되어 데이터베이스의 무결성과 일관성을 보장하려면 4가지 특성을 만족해야 한다.
1. Atomicity (원자성)
2. Consistency (일관성)
3. Isolation (격리성)
4. Durability (지속성)
1. Atomicity (원자성)
트랜잭션을 구성하는 연산들이 모두 정상적으로 실행되거나 하나도 실행되지 않아야 한다는 all-or-nothing 방식을 의미.
트랜잭션을 수행하다가 장애가 발생하여 작업을 완료하지 못했다면, 지금까지 실행한 연산들 모두 취소하고 데이터베이스를 트랜잭션 작업 전의 상태로 되돌려 트랜잭션의 원자성을 보장.
이처럼 트랜잭션의 원자성을 보장하려면 장애가 발생했을 때 데이터베이스의 원래 상태로 복구하는 회복 기능이 필요.
2. Consistency (일관성)
트랜잭션이 성공적으로 수행된 후에도 데이터베이스가 일관성 있는 상태를 유지해야 함을 의미.
즉, 트랜잭션이 수행되기 전에 데이터베이스가 일관된 상태였다면 트랜잭션의 수행이 완료된 후 결과를 반영한 데이터베이스도 또 다른 일관된 상태를 되어야 한다.
예시 : 계좌 이체 진행 시 진행 전의 돈의 합과 진행 후의 돈의 합이 같아야 함.
3. Isolation (격리성)
현재 수행 중인 트랜잭션이 완료될 때까지 트랜잭션이 생성한 중간 연산 결과에 다른 트랜잭션들이 접근할 수 없을 의미.
시스템에서 여러 트랜잭션이 동시에 수행되지만 각 트랜잭션이 독립적으로 수행될 수 있도록 다른 트랜잭션의 중간 연산 결과에 서로 접근하지 못하게 한다.
이를 통해 사용자들은 트랜잭션들이 동시에 수행되는 거처럼 느끼면서도 순서대로 하니씩 수행되는 것처럼 정확하고 일관된 결과를 얻을 수 있게 된다.
예시: A가 B에게 500원을 보내고 있는데 다른 트랜잭션이 끼어들어 B에게 돈을 보낼 수 없음. A가 먼저 B에 대한 트랜잭션을 완료한 후에 시행이 됨.
4. Durability (지속성)
트랜잭션이 성공적으로 완료된 후 데이터베이스에 반영한 수행 결과는 어떠한 경우에도 손실되지 않고 영구적이어야 함을 의미.
시스템에 장애가 발생하더라도 트랜잭션 작업 결과는 없어지지 않고 데이터베이스에 그대로 남아있어야 한다.
트랜잭션의 지속성을 보장하려면 시스템에 장애가 발생했을 때 데이터베이스를 원래 상태로 복구하는 회복 기능이 필요.
트랜잭션의 연산
보통 디비를 사용할 때, 쿼리를 날리면 데이터 베이스에 반영이 된다고 생각하는데, 디비에 반영되는 시점은 트랜잭션 연산이 성공적으로 완료되는 시점에 실제 데이터 베이스에 반영이 된다. 그리고 트랜잭션 연산에는 크게 두 가지 과정이 있다.
commit 연산
https://www.ibm.com/support/knowledgecenter/en/SSEPEK_12.0.0/intro/src/tpc/db2z_commitandrollbackoft트랜잭션이 성공적으로 수행되었을 선언(작업 완료)
commit 연산이 실행된 후에야 트랜잭션의 수행 결과가 데이터베이스에 반영되어 데이터베이스가 일관된 상태를 지속적으로 유지.
commit 연산의 실행을 통해 트랜잭션의 수행이 성공적으로 완료되었음을 선언하고 결과를 최종 데이터베이스에 반영.
rollback 연산
https://www.ibm.com/support/knowledgecenter/en/SSEPEK_12.0.0/intro/src/tpc/db2z_commitandrollbackoft트랜잭션이 수행을 실패했음을 선언(작업 취소)
rollback 연산이 실행되면 트랜잭션이 지금까지 실행한 연산의 결과가 취소되고 트랜잭션이 수행되고 전의 상태로 다시 돌아간다.
트랜잭션 수행되는 도중 일부 연산이 처리되지 못한 상황에서는 rollback 연산을 실행하여 트랜잭션의 수행이 실패했음을 선언하고, 모순되지 않도록 데이터베이스를 트랜잭션 수행 전의 일관된 상태로 되돌려야 한다.
트랜잭션의 상태
그리고 위와 같은 트랜잭션의 연산을 수행할 때의 크게 5가지 상태가 존재하고 상태 처리 과정은 아래 그림과 같다.
https://beginnersbook.com/2018/12/dbms-transaction-states/활동 상태
트랜잭션이 수행을 시작하여 현재 수행 중인 상태.
부분 완료 상태
마지막 연산이 실행된 직후의 상태를 부분 완료 상태.
연산은 모두 처리한 상태이지만 수행한 최종 결과를 데이터베이스에 아직 반영하지 않은 상태.
완료 상태
트랜잭션이 성공적으로 완료되어 commit 연산을 실행한 완료 상태.
실패 상태
장애가 발생하여 트랜잭션의 수행이 중단된 상태.
철회 상태
수행이 실패하여 rollback 연산을 실행한 상태.
장애와 회복
데이터베이스는 모순이 없는 일관된 상태로 유지가 되어야 한다. 그래서 장애가 발생했을 시 회복 기능을 제공해 관리되어진다. 그리고 여기서 회복이라 함은 장애가 발생했을 때 데이터베이스를 장애가 발생하기 전의 일관된 상태로 복귀시키는 것을 의미한다.
데이터베이스에서의 장애
크게 3가지 유형이 존재
1. 트랜잭션 장애
2. 시스템 장애 - 하드웨어 결함으로 정상적으로 수행을 계속할 수 없는 경우
3. 미디어 장애 - 디스크 장치의 결함으로 디스크에 저장된 데이터베이스의 일부 혹은 전체가 손상된 상태
회복 기법.
데이터베이스의 회복 기법은 크게 4가지가 존재하고 데이터베이스 관리 시스템에 있는 회복 관리자가 담당하게 된다.(회복 관리자는 장애 발생을 탐지하고, 장애가 탐지되면 데이터 베이스로 복구하는 기능 제공)
Recovery ways
Immediate updates (즉시 갱신)
- 로그 기반 회복 기법
- 트랜잭션 수행 도중 변경하면 변경 정보를 로그 파일에 저장하고, 트랜잭션이 부분 완료되기 전이라도 모든 변경 내용을 즉시 데이터베이스의 반영하는 기법.
- 로그 파일을 참조하여 REDO & UNDO 연산 모두 실행
Deferred updates (지연 갱신)
- 로그 기반 회복 기법
- 트랜잭션이 부분 완료 상태에 이르기까지 발생한 모든 변경 내용을 로그 파일에만 저장하고 데이터베이스에는 커밋이 발생할 때까지 저장하는 기법. 회복 과정에서 UNDO가 필요 없음.
- 이를 통해 트랜잭션의 원자성 보장.
Checkpoint recovery
- 이전은 신경 쓰지 않고 Checkpoint 이후만 즉시 갱신 혹은 지연 갱신을 수행.
- 가장 최근 Checkpoint 지점을 찾아 그 시점 이후의 로그만을 회복 대상으로 함.
Media recovery
- 말 그대로 디스크와 같이 비휘발성 저장 장치의 내용이 손상되는 장애가 발생했을 시에 회복을 위한 기법이며 백업, 미러링 등을 이용해 복구.
How to recover?
Copy (duplicate)
• Dump: copy the ‘whole database’ to other place regularly
- 데이터베이스 전체를 다른 저장 장치에 주기적으로 복사하는 방법.
- 디스크와 같은 비휘발성 저장 장치에 데이터 베이스 복사본을 저장.
• Log: save ‘before/after states’ of operations to files
- 변경 연산이 실행될 때마다 데이터를 변경하기 이전 값과 변경된 이후의 값을 별도의 파일에 기록하는 방법.
redo, undo연산 실행
redo(재실행) : 가장 최근에 저장한 데이터베이스 복사본을 가져온 후 로그를 이용해 복사본이 만들어진 이후에 실행된 모든 변경 연산을 재실행하여 장애가 발생하기 직전의 상태로 복구
- 전반적으로 손상된 경우에 주로 사용
undo (취소): 로그를 이용해 지금까지 실행된 모든 변경 연산을 취소하여 데이터베이스를 원래의 상태로 복구
- 변경 중이었거나 이미 변경된 내용만 신뢰성을 읽은 경우에 주로 사용.
즉 회복 기법의 핵심은 데이터 중복과 로그를 통해 실행된다는 점을 기억하면 된다. 각각의 기법에 대해서도 깊게 알아보면 끝이 없기 때문에 관심 있는 분들은 참고 책 혹은 자료를 찾아보는 걸 추천한다.
마무리
본 포스팅에서는 트랜잭션을 통해 데이터 베이스가 일관성과 지속성을 유지하며 어떻게 관리되는지에 알아보았고, 장애가 발생했을 시 어떤 방법으로 회복하는지에 소개를 했다. 이외에도 데이터 베이스에 대한 변경 연산과 관련하여 기록을 관리하는 로그에 대한 내용과 병행 제어 등의 대한 내용이 위 내용과 이어지는데, 추후 좀 더 공부한 후에 포스팅을 진행할 예정이다.
참고
