[Database] 트랜잭션 (Transaction)

트랜잭션 (Transaction)

• 데이터베이스의 상태를 변화시키기 위해 수행하는 작업 단위
• 데이터의 무결성과 일관성을 보장하기 위해 사용
• 상태 변화: DML을 통해 DB에 접근하는 것(SELECT, INSERT, DELTE, UPDATE)

트랜잭션의 상태

 

• 활동(Active): 트랜잭션이 실행 중인 상태
• 실패(Failed): 트랜잭션의 실행 중에 오류가 발생하여 작업이 중단된 상태. 이 단계에서는 트랜잭션이 이전 상태로 롤백되어야 한다.
• 부분 완료(Partially Committed): 트랜잭션의 모든 작업이 성공적으로 실행되었지만, 아직 커밋되지 않은 상태. 이 단계에서는 트랜잭션의 결과를 데이터베이스에 영구적으로 반영하기 전에 커밋 여부를 결정해야 한다.
• 완료(Committed): 트랜잭션이 성공적으로 종료되고 커밋되어 영구적으로 데이터베이스에 적용된 상태
• 철회(Aborted): 트랜잭션에 실패하거나 롤백되어 이전 상태로 복구된 상태. 이 단계에서는 트랜잭션의 작업 결과가 데이터베이스에 영향을 미치지 않는다.

트랜잭션의 주요 명령어

1. Commit

• 트랜잭션의 작업을 성공적으로 완료하고, 해당 작업을 데이터베이스에 영구적으로 반영하는 명령어
• 하나의 트랜잭션이 성공적으로 끝났고, DB가 일관성있는 상태일 때 이를 알려주기 위해 사용하는 연산

2. Rollback

• 트랜잭션의 작업을 실패하거나 중단되었을 때, 이전 상태로 트랜잭션을 되돌리는 명령어
• 롤백이 실행되면 트랜잭션이 실패 상태로 전환되며, 이전에 수행한 작업은 취소되어 데이터베이스가 이전 상태로 복원된다.
• 트랜잭션이 로그에 저장된다.

3. Redo

• 데이터베이스 시스템의 장애나 비정상 종료 후에 복구를 위해 사용되는 명령어
• 로그 파일을 통해 트랜잭션의 커밋된 작업을 다시 실행하여 데이터베이스를 이전 상태로 복구하는데 사용

4. Undo

• 트랜잭션의 작업을 취소하고 이전 상태로 복원하는 명령어(롤백 작업에 사용)
• 사용자가 했던 작업을 반대로 진행한다.

트랜잭션 특징(ACID)

원자성(Atomicity)

트랜잭션은 All or Noting의 원칙을 따른다. 즉, 모든 작업이 성공적으로 완료되면 데이터베이스에 모든 변경 사항이 반영(Commit)되며, 한 작업이라도 실패하면 트랜잭션 전체가 취소(Rollback)된다.

일관성(Consistency)

트랜잭션이 수행되기 전과 후의 데이터베이스 상태가 일관된 상태를 유지해야 한다.

독립성(Isolation)

여러 트랜잭션이 동시에 수행될 때 각각의 트랜잭션은 독립적으로 수행되는 것처럼 보여야 한다. 한 트랜잭션이 다른 트랜잭션의 작업을 간섭하지 않고, 중간 결과를 다른 트랜잭션에 노출시키지 않아야 한다.

지속성(Durability)

트랜잭션이 성공적으로 완료되면 그 결과는 영구적으로 데이터베이스에 반영되어야 한다. 시스템의 장애나 오류가 발생하더라도 트랜잭션의 결과는 지속되어야 한다.

트랜잭션 관리를 위한 DBMS의 전략

💡DBMS의 구조

데이터베이스 시스템은 보통 비휘발성 저장 장치인 디스크에 데이터를 저장하며 전체 데이터베이스의 일부분을 메인 메모리에 유지한다. DBMS는 데이터를 고정 길이의 페이지로 저장하며, 디스크에서 읽거나 쓸 때에 페이지 단위로 입출력이 이루어진다. 이때 페이지 버퍼 모듈이 사용하여 메인 메모리에 유지하는 페이지를 관리한다.

이 페이지 버퍼의 관리 정책에 따라서 트랜잭션의 UNDO 복구와 REDO 복구가 요구되거나 그렇지 않게 된다.

UNDO

• 필요한 이유
  • 아직 완료되지 않은 트랜잭션이 수정한 페이지들이 디스크에 반영될 수 있다. 이 상황에서 만약 해당 트랜잭션이 정상적으로 종료될 수 없게 되면 트랜잭션이 변경한 페이지들은 원상 복구되어야 하기 때문이다.
    
    
• 만약 트랜잭션 종료 전에는 절대 수정된 페이지들을 디스크에 반영하지 않는다면?
  • 트랜잭션이 진행되는 동안 메모리에 모든 수정된 페이지가 저장되어야 하기 때문에 매우 큰 크기의 메모리 버퍼가 필요하다.

수정된 페이지가 디스크에 반영되는 시점을 기준으로 나눈 정책

1. STEAL : 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책
2. ¬STEAL : 수정된 페이지를 트랜잭션 종료 시점까지는 버퍼에 유지하는 정책

REDO

• 필요한 이유
  • 이미 커밋된 트랜잭션이 수정한 페이지들은 디스크에 반영되어야 한다. 만약, 디스크에 수정된 페이지들이 반영되지 않은 상태에서 장애가 발생하였다면 복구를 위해 REDO 작업이 필요하다.
  • 또한, 버퍼 관리 정책에 따라 커밋된 트랜잭션의 변경 내용이 디스크에 즉시 반영되지 않는 경우, 변경 내용을 재반영해야 할 때 필요하다.
    
    

트랜잭션이 종료되는 시점에 해당 트랜잭션이 수정한 페이지들을 디스크에 반영할 것인가 여부로 나눈 정책

1. FORCE : 수정했던 모든 페이지를 트랜잭션 커밋 시점에 디스크에 반영하는 정책
2. ¬FORCE : 수정했던 페이지를 트랜잭션 커밋 시점에 디스크에 반영하지 않는 정책 (로그는 기록을 한다)

DBMS는 버퍼 관리 정책으로 STEAL과 ¬FORCE 정책을 채택하고 있어, 이로 인해서 UNDO 복구와 REDO 복구가 모두 필요하게 된다.

트랜잭션 관리 기법

로그(Log)

트랜잭션의 작업을 로그 파일에 기록하여 장애 발생 시에도 데이터베이스를 이전 상태로 복구하는 방법.

격리 수준(Isolation Level)

벼행성 제어를 위해 트랜잭션들 간의 격리 수준을 지정하는 방법

락(Lock)

병행 실행되는 여러 트랜잭션들 간의 충돌을 방지하기 위해 락(lock)을 사용하여 데이터 접근을 제어하는 방법

트랜잭션은 데이터를 읽거나 수정하기 전에 해당 데이터에 락을 획득하고, 작업을 완료한 후에 락을 해제한다.

 

[참고] https://d2.naver.com/helloworld/407507