Part2 10 Transactions

devkwon·2024년 7월 25일
0

Oracle Database Concepts

목록 보기
5/7

트랜잭션(Transaction)

트랜잭션은 SQL문의 그룹으로 commit이 발생할 때, 전부 적용되거나 전부 roll back이 되도록 한다.
트랙잭션은 unique한 transaction id로 구분된다.

ACID

모든 트랜잭션은 acid 특성을 준수해야 한다.

  • Atomicity
    모든 task들은 전부 commit되어지거나 전부 roll back이 되어야 한다. (부분적 commit이란 존재하지 않는다.)

  • Consistency
    트랜잭션 처리 전과 처리 후가 일관적인 상태여야 한다.

  • Isolation
    한 트랙잭션이 다른 트랜잭션에 영향을 끼치면 안 된다.


즉 위와 같이 세션1에서 트랜잭션을 통해 쓰기를 하고 있다면 세션2에서는 해당 트랜잭션이 완료될 때까지 접근할 수 없다.

  • Durability
    트랜잭션으로 만들어진 변경은 영구적이여야 한다.

트랜잭션 과정

우선 트랜잭션이 시작되면, undo data 세그먼트에 트랜잭션을 할당하여 새로운 트랜잭션을 위한 undo 데이터들을 기록한다. 트랜잭션 id는 undo segment, table slot이 할당될 때까지 할당되지 않는다.
이후 트랜잭션 id가 할당되면, undo segment 넘버, slot, 시퀸스 넘버의 unique한 id가 된다.

undo segment란?

트랜잭션이 생성되면 종료될 때까지 명령어들을 실행하게 된다.
이때, 명령어로 인해 변경이 일어나나 임시적이다.

트랜잭션은 다음과 같은 상황에 의해 종료가 된다.

  • commit 또는 rollback 문을 사용하였을 때.

  • DDL문을 사용했을 때.
    DB는 DDL문 실행 전후에 모든 내용을 자동으로 commit해버린다. 그래서 DML문과 DDL문이 섞인 트랜잭션을 실행한다면, DDL문 전에 commit이 되지 않은 DML문이 없도록 조심해야 한다.

  • 사용자가 어플리케이션에서 disconnect될 때.
    사용자가 db 어플리케이션에서 disconnect되면, 자동으로 commit한다.

  • 클라이언트 프로세스가 abnormal하게 종료될 때.
    만약 클라이언트 프로세스가 불의의 사고로 종료된다면, 해당 내용을 roll back한다.

오라클DB는 statement-level atomicity를 지원한다.
즉, 하나의 SQL문을 atmoic문으로 생각해서 성공,실패 여부에 따라 commit,roll back 할 수 있다.
만약 syntax 오류가 있는 문장이 있다면, 애초에 실행되지 않는 것이므로 roll back이 되지 않는다.

atomic 문의 부작용으로는 트리거가 있다. SQL문을 실행할 때 발생되는 트리거들도 atmoic 문으로 간주해서 모두 성공하거나 실패하게 된다. (실패했을 때 로깅 불가능)

Transaction Commit

커밋으로 인해 트랜잭션이 종료되면, 해당 변경이 db에 영구적으로 반영이 된다.

커밋이 발생하면 다음과 같은 일이 발생한다.

  • commit에 대한 SCN을 만든다.

  • log writer process(LGWR)가 redo log buffer에 남아있는 redo log 데이터와 트랜잭션 SCN를 online redo log에 기록한다.

  • 해당 테이블이나 행에 대한 lock를 해제하여, enqueued 트랜잭션이 있다면 진행할 수 있게 된다.

  • savepoint를 제거한다.

  • commit cleanout을 진행한다.

    commit cleanout:
    만약 커밋된 트랜잭션으로 인해 수정된 블럭이 SGA에 있고 아무도 사용하지 않는다면, 블럭에 있는 ITL을 지운다.

위 과정이 모두 수행되면 DB에서 해당 트랜잭션이 성공했음을 mark한다.

System Change Numbers(SCNs)

SCN은 내부 타임스탬프이다. SCN이 낮다는건 해당 이벤트가 더 먼저 일어났다는 것이다. 모든 트랜잭션은 SCN을 가지고 있다.

SCN은 db에서 발생한 이벤트들을 정렬하는데 사용된다. DB는 SCN을 보고 recovery시 불필요한 redo를 막는다. 또한 redo가 존재하는지 살펴보고 없다면, recovery 중단하기 위해 사용되기도 한다.

SCN은 SGA(System Global Area)에 존재하며, 만약 트랜잭션이 변경되면, 새로운 SCN을 해당 트랜잭션의 undo data 세그먼트에 작성한다. 그 후에 로그 작성 프로세스가 트랜잭션 커밋 기록들을 온라인 redo log에 기록한다.

online log file: 오라클 db의 data file과 control file의 모든 변경을 저장하는 로그파일.

tibero에서는 TSN라고 불린다.

트랜잭션이 커밋이 되면 그때 SCN이 기록된다.

Transaction Guard

트랜잭션 가드는 트랜잭션 멱등성(idempotence)을 보장하는 API다. 여기서 멱등성이란, 트랜잭션 커밋 성공/실패 여부를 항상 정확하게 db에게 알려줄 것을 보장한다는 것이다.

만약 시스템이나 네트워크의 문제로 클라이언트와의 연결이 끊기면, 이때 실행 중이던 트랜잭션을 In-flight 트랜잭션이라고 하는데, 기존에 실행하던 트랜잭션을 다시 실행할지, 아니면 결과를 보여줄지는 In-flight 트랜잭션의 결과를 보고 결정한다.

12c 이전 버전에서는 가드가 없어서 비정상적인 종료가 발생할 때, 어떤 명령어까지 커밋이 되었는지 확인할 수 있는 방법이 없어서 트랜잭션을 재실행할 때, 중복 트랜잭션 문제나 논리적 손상이 발생했었는데 트랜잭션 가드를 통해 이러한 문제점을 해결할 수 있다.

Logical Transaction ID

트랜잭션 가드는 통신 실패를 대비하기 위해 logical transaction id라는 global적인 unique identifier를 가지고 있다.

id는 처음 세션이 맺어졌을 때 부터 logical number로 할당 받아서 각 커밋이나 롤백마다 이를 업데이트한다. 그래서 어플리케이션단에서 이를 보고 어디까지 커밋이 성공했는지 확인할 수 있다.
따라서 이를 통해 중복 없이 실패한 지점부터 다시 트랜잭션을 replay 할 수 있다.

Application Continuity

Application Continuity는 의도적인 종료나 의도치 않은 장애가 발생할 경우 복구(replay)를 도와주는 기능이다.

트랜잭션을 보내는 과정에서 만약 예기치 못한 장애나 의도적인 종료를 한 경우에 만약 replay가 성공하면 서비스가 중단 되지 않는다. 그러나 이미 바뀐 데이터를 다시 바꾸려는 행동이 감지가 되거나, timeout이 발생하면 replay를 하지 않는다. disableReplay 메소드를 통해 명시적으로 disable할 수도 있다.

마이그레이션이나 드레인(drain)을 할 때도 사용된다.

drain: 유지보수 작업을 할 때, 현재 실행 중인 트랜잭션이나 세션들을 점짐적으로 종료하거나 요청을 받지 않도록 해서 데이터 일관성을 보장하는 것

Autonomous Transaction

Autonomous Transaction은 메인 트랜잭션으로부터 호출될 수 있는 독립적인 트랜잭션이다. Autonomous Transaction을 사용하면 호출 트랜잭션을 일시 중단하고, SQL 작업을 수행한 후 이를 커밋하거나 취소한 후 호출 트랜잭션을 다시 실행한다.

Distributed Transaction

분산 db(distributed database) node에서 데이터를 업데이트하는 트랜잭션으로, database link라는 오브젝트를 사용한다.

분산 db 환경에서는 모든 노드에서 commit이 발생하거나 roll back이 되야하는 것을 보장해야하므로, 단일 환경보다 관리하기가 더 어렵다.

Two-Phase Commit

distributed transaction의 영향을 받는 모든 노드들이 commit 되거나 roll back될 것을 보장한다.

가장 먼저 transaction을 수행한 노드가 global coordinator가 되고, coordinator는 다른 노드들에게 준비가 되었는지 메시지를 전파한다. 만약 하나라도 no 메시지를 받았다면, 전부 roll back되고, 전부 찬성이라면, commit 메시지를 전파한다.

In-Doubt Transaction

in-doubt distributed transaction은 two-phase commit이 여러가지 장애로 인해 인터럽트(interrupt)되었을 때 발생한다.

장애가 복구되고 연결이 다시 establish되면, RECO프로세스가 자동으로 in-doubt distributed transaction들을 commit 또는 roll back을 한다.

0개의 댓글