위키원
트랜잭션
트랜잭션(transaction)이란 "쪼갤 수 없는 업무 처리의 최소 단위"를 말한다. 거래내역이라고도 한다. '트렌젝션'이 아니라 '트랜잭션'이 올바른 표기법이다. 영어로 간략히 Tx라고 표기하기도 한다. 1초당 처리할 수 있는 트랜잭션의 개수를 TPS라고 한다.
개요
트랜잭션은 은행 ATM이나 데이터베이스 등의 시스템에서 사용되는 더 이상 쪼갤 수 없는 업무 처리의 최소 단위이다. 예를 들어, A라는 사람이 B라는 사람에게 1,000원을 지급하고 B가 그 돈을 받은 경우, 이 거래 기록은 더 이상 작게 쪼갤 수가 없는 하나의 트랜잭션을 구성한다. 만약 A는 돈을 지불했으나 B는 돈을 받지 못했다면 그 거래는 성립되지 않는다. 이처럼 A가 돈을 지불하는 행위와 B가 돈을 받는 행위는 별개로 분리될 수 없으며 하나의 거래내역으로 처리되어야 하는 단일 거래이다. 이런 거래의 최소 단위를 트랜잭션이라고 한다. 트랜잭션 처리가 정상적으로 완료된 경우 커밋(commit)을 하고, 오류가 발생할 경우 원래 상태대로 롤백(rollback)을 한다.
목적
트랜잭션은 데이터베이스 서버에 여러 개의 클라이언트가 동시에 액세스 하거나 응용프로그램이 갱신을 처리하는 과정에서 중단될 수 있는 경우 등 데이터 부정합을 방지하고자 할 때 사용한다. [1] 데이터베이스 기능 중, 트랜잭션을 조작하는 기능은 데이터베이스 완전성(integrity) 유지를 확신하게 한다. 단일 트랜잭션은 데이터베이스 내에 읽거나 쓰는 여러 개 쿼리를 요구한다. 이때 중요한 것은 데이터베이스가 수행된 일부 쿼리가 남지 않는 것이다. 예를 들어, 송금을 할 때 한 계좌에서 인출되면 다른 계좌에서 입금이 확인되는 것이 중요하다. 또한 트랜잭션은 서로 간섭하지 않아야 한다. 트랜색연의 특징에 대해서는 아래 자세히 설명되어 있다. 만약 쿼리 하나가 실패하면, 데이터베이스 시스템은 전체 트랜잭션 또는 실패한 쿼리를 롤백 한다. 이것은 DBMS가 어떻게 사용되고 셋업 되었느냐에 따라 다르다. 트랜잭션은 커밋전에 언제든지 수동으로 롤백 될 수 있다. 간단한 트랜잭션의 경우 아래 양식의 SQL 언어로 데이터베이스 내에서 실행된다. [2]
- Begin the transaction [3]
--Applies to SQL Server and Azure SQL Database
BEGIN { TRAN | TRANSACTION }
[ { transaction_name | @tran_name_variable }
[ WITH MARK [ 'description' ] ]
]
[ ; ]
--Applies to Azure SQL Data Warehouse and Parallel Data Warehouse
BEGIN { TRAN | TRANSACTION }
[ ; ]
- Execute several queries(DB내 갱신이 아직 적용되지 않는다.)
- Commit the transaction(트랜잭션이 성공적이며, 갱신이 실제 적용됨.)[4]
-- Applies to SQL Server (starting with 2008) and Azure SQL Database
COMMIT [ { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable ] ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ]
[ ; ]
-- Applies to Azure SQL Data Warehouse and Parallel Data Warehouse Database COMMIT [ TRAN | TRANSACTION ] [ ; ]
특징
트랜잭션은 데이터베이스 시스템에서 병행 제어 및 회복 잡업 시 처리되는 작업의 논리적인 단위로 사용자가 시스템에 대한 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업 단위이다. 하나의 트랜잭션은 Commit 되거나 Rollback이 된다. [5]
ACID
데이터베이스의 트랜잭션이 안전하게 수행되기 위해서는 ACID 조건을 충족해야 한다. ACID란 Atomicity, Consistency, Isolation, Durability의 약자로서, 데이터베이스의 트랜잭션이 안전하게 수행되기 위한 4가지 필수적인 성질인 원자성, 일관성, 고립성, 지속성을 말한다.
원자성(atomicity)
원자성은 하나의 트랜잭션이 더 이상 작게 쪼갤 수 없는 최소한의 업무 단위이다. 트랜잭션이 데이터베이스에 모두 반영되던지, 아니면 전혀 반영되지 않아야 하며 작업이 부분적으로 실행되거나 중단되지 않는 것을 보장하는 것으로 즉, All or Nothing의 개념으로서 작업 단위를 일부분만 실행하지 않는다는 것을 의미한다. 트랜잭션 실행 도중 문제가 발생했을 경우 중단된 상태가 아닌 모두 실패하거나, 모두 완성되거나 둘 중 하나의 상태가 되어야 한다. 즉, 100개 명령어로 구성된 트랜잭션 중 99개 완료 1개 실패가 된다면, 이는 무조건 실패로 간주하여 트랜잭션 시작 전 상태로 돌려야 한다. 또한 100개가 모두 성공했을 시 트랜잭션은 성공이기 때문에 중간 상태가 없다. 트랜잭션은 사람이 설계한 논리적인 작업 단위이기 때문에 일처리가 작업 단위 별로 이루어져야 사람이 다루는데 무리가 없다. 만약 트랜잭션 단위로 데이터가 처리되지 않는다면, 설계한 사람은 데이터 처리 시스템을 이해하기 힘들 뿐만 아니라, 오작동 했을 시 원인을 찾기가 매우 힘들어진다. 트랜잭션 내의 모든 명령은 반드시 완벽하게 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다. 트랜잭션이 원자성이라는 성질을 지니게 된 이유는 중간에 끊기게 되면 이후 해당 트랜잭션의 어디서부터 이어서 수행되어야 하는지 모르기 때문이다. [5][6][1][7][8]
- 원자성 보장
트랜잭션에서 원자성은 수행하고 있는 트랜잭션에 의해 변경된 내역을 유지하면서, 이전에 commit된 상태를 임시 역역에 따로 저장함으로써 보장한다. 즉, 현재 수행하고 있는 트랜잭션에서 오류가 발생하면 현재 내역을 날려버리고 임시 영역에 저장했던 상태로 rollback 한다. 이전 데이터들이 임시로 저장되는 영역을 롤백 세그 먼트(rollback segment)라고 하며, 현재 수행하고 있는 트랜잭션에 의해 새롭게 변경되는 내역을 데이터베이스 테이블이라고 한다. 다시 말해, 트랜잭션의 원자성은 롤백 세그먼트에 의해 보장된다고 할 수 있다. 그런데 오류가 발생하면 rollback 하는데, 트랜잭션의 길이가 길어지면 어떻게 될까? 이 경우 확실하게 오류가 발생하지 않는 부분도 다시 처음부터 작업을 수행해야 한다. 따라서 확실한 부분에 대해서는 rollback이 되지 않도록 중간 저장 지점인 save point를 지정할 수 있다. save point를 지정하게 되면 rollback 할 때 save point 이전은 확실하다 간주하고 그 이후부터 진행하게 된다.[1]
일관성(consistency)
일관성은 트랜잭션이 완료된 결괏값이 일관적인 DB 상태를 유지하는 것을 말한다. 시스템이 가지고 있는 고정요소는 수행 전과 후의 상태가 같아야 하며 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것으로 트랜잭션이 진행되는 동안 데이터베이스가 변경되더라도 업데이트된 데이터베이스로 트랜잭션이 진행되는 것이 아니라, 처음 트랜잭션을 진행하기 위해 참조한 데이터베이스로 진행된다. 이렇게 함으로써 각 사용자가 일관성 있는 데이터를 볼 수 있는 것이다. 트랜잭션 수행 전후의 데이터베이스 상태는 각각 일관성이 보장되는 서로 다른 상태가 된다. 트랜잭션 수행이 보존해야 할 일관성은 기본 키, 외래 키 제약과 같은 명시적인 무결성 제약 조건들뿐만 아니라, A에서 B로 돈을 이체할 때 A와 B 계좌의 돈의 총합이 같아야 한다는 사항과 같은 비명 시적인 일관성 조건들도 있다.[5][6][1][7][8][9]
- 일관성 보장
트랜잭션에서 일관성은 트랜잭션 수행 전/후에 데이터 모델의 모든 제약 조건(기본 키, 외래 키, 도메인, 도메인 제약조건 등)을 만족하는 것을 통해 보장한다. 예를 들어 Movie와 Video 테이블이 있을 때 Video 테이블의 primary key인 movie_id가 외래키로 존재한다고 가정한다. 만약 movie_id의 제약 조건이 Movie 테이블에서 변경되면, Video 테이블에서도 movie_id가 변경되어야 한다. 한 쪽의 테이블에서만 데이터 변경사항이 이루어져서는 안되는 것이다. 그렇다면 어떻게 트랜잭션은 일관성을 보장할까? 어떤 이벤트와 조건이 발생했을 때, 트리거(Trigger)를 통해 보장한다. 트리거는 '방아쇠'라는 뜻인데, 데이터베이스 시스템이 자동적으로 수행할 동작을 명시할 때 사용된다. 즉, 어떤 행위의 시작을 알리는 것이다.[1]
고립성(isolation)
고립성이란 하나의 트랜잭션 수행시 다른 트랜잭션의 작업이 끼어들지 못하도록 보장하는 것이다. 즉, 트랜잭션끼리는 서로를 간섭할 수 없다. 트랜잭션이 실행하는 도중에 변경한 데이터는 이 트랜잭션이 완료될 때까지 다른 트랜잭션이 참조하지 못하게 하는 특성이다. 데이터베이스는 클라이언트들이 같은 데이터를 공유하는 것이 목적이므로 여러 트랜잭션이 동시에 수행되어야 한다. 이때 트랜잭션은 상호 간의 존재를 모르고 독립적으로 수행되어야 한다. 고립성은 격리성이라고도 하는데 이를 유지하기 위해서는 여러 트랜잭션이 동시에 접근하는 데이터에 대한 제어가 필요하다. 여러 트랜잭션이 동시에 수행되더라도 각각의 트랜잭션은 다른 트랜잭션의 수행에 영향을 받지 않고 독립적으로 수행되어야 한다. 한 트랜잭션에서 데이터베이스를 변경한 내용은 트랜잭션이 커밋되기 전까지는 다른 어떤 질의나 트랜잭션과도 고립되어야만 한다. 즉, 각 트랜잭션은 시스템 내에서 동시에 수행되고 있는 다른 트랜잭션들을 알지 못하는 것이다. 한 트랜잭션의 중간 결과가 다른 트랜잭션에게는 숨겨져야 한다는 의미인데, 이러한 성질이 보장되지 않으면 트랜잭션이 원래 상태로 되돌아갈 수 없게 된다. DBMS의 병행 제어 모듈이 트랜잭션의 고립성을 보장하며 예를 들어 설명하자면 하나의 트랜잭션이 A라는 계좌에서 작업을 하고 있을 경우 다른 트랜잭션이 A계좌에 대해 참조하거나 관여할 수 없고 작업이 끝날 때까지 대기해야 하는것을 말한다. [1][7][8][9]
- 고립성 보장
병행처리 과정에서 트랜잭션의 고립성이 왜 보장되어야 하는지 알 수 있다. OS의 세마포어(semaphore)와 비슷한 개념으로 lock&excute unlock을 통해 고립성을 보장할 수 있었다. 즉, 데이터를 거나 쓸 때는 문을 잠궈서 다른 트랜잭션이 접근하지 못하도록 고립성을 보장하고, 수행을 마치면 unlock을 통해 데이터를 다른 트랜잭션이 접근할 수 있도록 허용하는 방식이다. 트랜잭션에서는 데이터를 읽을 때, 여러 트랜잭션이 읽을 수는 있도록 허용하는 shared_lock을 한다. 즉, shared_lock은 데이터 쓰기를 허용하지 않고 오직 읽기만 허용하는 것이다. 또한 데이터를 쓸 때는 다른 트랜잭션이 읽을 수도 쓸 수도 없도록 하는 exclusive_lock을 사용한다. 그리고 읽이, 쓰기 작업이 끝나면 unlock을 통해 다른 트랜잭션이 lock을 할 수 있도록 데이터에 대한 잠금을 풀어준다. 단, lock과 unlock을 잘못 사용하면 데드락(deadlock)상태에 빠질 수 있다. 즉, 모든 트랜잭션이 아무것도 수행할 수 없는 상태가 되는 것이다.[1]
지속성(durability)
트랜잭션이 정상적으로 종료된 다음에는 영구적으로 데이터베이스에 작업의 결과가 저장되어야 한다. 지속성은 트랜잭션의 성공 결과 값은 장애 발생 후에도 변함없이 보관되어야 한다는 것으로 트랜잭션이 정상적으로 완료된 경우에는 버퍼의 내용을 하드디스크(데이터베이스)에 확실히 기록해야 하며, 부분 완료(Partial Commit)된 경우에는 작업을 취소(Aborted)하여야 한다 즉, 정상적으로 완료 혹은 부분완료된 데이터는 DBMS가 책임지고 데이터베이스에 기록하는 성질이 지속성이며 영속성이라고 표현하기도 한다. [7][8][9]
종류
Serial schedule(직렬 스케줄)
순서대로, 하나씩 트랜잭션을 실행하는 것으로 트랜잭션 하나의 실행이 완료되면 다른 트랜잭션을 시작하는 방식으로 하나씩 차례대로 실행하는 스케줄로서 트랜잭션이 실행되는 동안 다른 트랜잭션의 영향을 받을 수 없으므로 모순이 발생하지 않는다.[10]
Serializable schedule(직렬화 스케줄)
병행 제어, 직렬 스케줄 장점을 가진 것으로 트랜잭션들이 동시에 자료 접근 연산들을 교차하며 실행시키면서도 결과가 직렬 스케줄과 동일한 스케줄이다. 즉, 병행 처리하지만 적절한 제어 조치를 취함으로써 일관성을 유지하는 스케줄로서 병행 제어에서 필요한 스케줄이다. 즉, 병행 제어 스케줄은 직렬성을 유지할 수 있다. 직렬성이란 트랜잭션들의 처리 결과가 직렬 처리와 동일한 효과를 가지는 스케줄 특성이다.[10]
필요성
트랜잭션은 거래의 안전성을 확보하는 방법인데 데이터베이스에선 테이블에서 데이터를 읽어 온 후 다른 테이블에 데이터를 입력하거나 갱신, 삭제하는데 처리 도중 오류가 발생하면 모든 작업을 원상태로 되돌린다. 데이터베이스에서는 처리 과정이 모두 성공했을 때만 최종적으로 데이터베이스에 반영한다. 아래 그림을 보자 1,2번까지 잘 실행되다가 3번 작업 시 소프트웨어가 중단되거나 하드웨어 고장이 발생해 작업에 오류가 생기게 된다면 2번까지의 모든 작업을 취소하고 트랜잭션 작업 전인 데이터베이스 초기 상태로 돌아가게 된다.[11]
연산
.png)
Commit
Commit 연산은 한 개의 논리적 단위(트랜잭션)에 대한 작업이 성공적으로 끝났고 데이터베이스가 다시 일관된 상태에 있을 때, 트랜잭션이 행한 갱신 연산이 완료된 것을 트랜잭션 관리자에게 알려주는 연산이다.[5]위 그림에서 첫 번째 Commit 후 그 뒤에 Update 문으로 데이터를 갱신하고 Delete 문으로 데이터를 삭제한 후 Insert 문을 사용해 데이터를 삽입한다. 만약 이 모든 과정이 오류 없이 수행되었다면 지금까지 실행한 모든 작업을 데이터베이스에 영구 저장하라는 명령으로 Commit을 수행한다.[11]
.png)
Rollback
Rollback 연산은 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨트렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되더라도 트랜잭션의 원자성을 구현하기 위해 이 트랜잭션이 행한 모든 연산을 취소하는 연산이다. Rollback 시에는 해당 트랜잭션을 재시작하거나 폐기한다.[5] 위 그림에서 Rollback 명령은 마지막으로 수행한 Commit 명령까지만 정상 처리된 상태로 유지한다. 그 이후에 수행했던 모든 DML 명령어 작업들을 취소시켜 이전 상태로 원상 복귀 시킨다. 트랜잭션은 이렇든 ALL-OR-Nothing(모든 것을 수행하던지 아무것도 하지 말던지) 방식으로 DML 명령어들을 처리한다.[11]
상태
- 활동(Active): 트랜잭션이 실행중인 상태이다.
- 실패(Failed): 트랜잭션 실행에 오류가 발생하여 중단된 상태이다.
- 철회(Aborted): 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태이다.
- 부분 완료(Partially Committed): 트랜잭션의 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태이다.
- 완료(Committed): 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태이다.[5]
병행처리
- 병행처리 제어 목적
데이터베이스 병행처리 제어의 목적으로는 총 3개가 있다. 첫째, 트랜잭션의 충돌을 방지하기 위해서 고립성을 강제하기 위함. 둘째, 데이터베이스의 일관성을 보존하기 위함. 셋째, read-write 또는 write-write 충돌을 막기 위함. 스케줄의 진정한 목적은 충돌 스케줄을 찾아서 직렬화 스케줄을 만드는 것이다.
- 병행제어가 필요한 이유
1. The Lost Update Problem: 두 개의 트랜잭션이 동일한 아이템에 접근하여 서로의 연산이 중첩될 때 결과적으로 올바르지 않은 값이 저장될 수 있다.
2. The Temporary Update(or Dirty Read) Problem: 한 트랜잭션이 값을 업데이트를 하다가 중간에 트랜잭션이 fail 하였다. 하지만 rollback 하기 이전에 다른 트랜잭션이 값을 읽게 되면 올바르지 않은 값을 읽는 것이다.
3. The Incorrect Summary Problem: 한 트랜잭션이 aggregate 함수(Sum, Max, Min등)를 실행하고 있는데, 다른 트랜잭션이 이 값들 중 하나를 업데이트 하고 있을 때 aggregate 트랜잭션의 값이 업데이트 되기 이전을 사용할 때이다.
- 병행처리의 문제점
종류 내역 문제점 병행처리의 문제점 갱신 유실 문제 두 트랜잭션이 동시에 동일한 자료를 update 첫째 갱신이 유실 오류 읽기 문제 갱신하는 도중에 다른 트랜잭션이 read 낡은 자료 읽기 잘못된 요약 두 자료를 갱신하는 도중에 read 요약 결과 오류 무결성 제약조건 두 자료의 제약조건을 검사하지 않고 update 일관성 위반
다수의 사용자가 데이터베이스에 요청을 보내게 되면 이러한 요청들을 처리할 방법이 필요하다. 만약 하나의 요청을 끝내고 다른 요청을 수행하는 방식이라면 처리시간이 매우 오래 걸리게 되는데 그렇기 때문에 '병행 처리' 방식으로 처리를 한다. 트랜잭션을 병행 처리하면 처리 효율이 높아지지만, 처리 과정에서 동일한 자료를 동시에 접근해서 오류가 생길 수 있다.[10]
록킹
트랜잭션이 자료를 배타적으로 접근할 수 있으면 그 트랜잭션이 완료된 후에 다른 트랜잭션이 실행되기 때문에 직렬성이 확보된다. 자료를 배타적으로 접근하는 방법이 바로 록 기법이다. 트랜잭션의 ACID 특성을 해치는 접근 연산은 주로 갱신이다. 읽기 연산은 자료 값을 바꾸지 않는다. 하지만 읽기 연산 도중에 갱신을 하게되면 일관성 유지가 어려울 수 있다. 트랜잭션에는 공유 록과 배타 록 2가지가 있다.
특정 자료 Q에 공유 록을 걸면 다른 트랜잭션이 이 자료를 갱신할 수 없다. 공유 록이 걸린 Q는 다른 트랜잭션에 의해서 읽혀질 수 있다.[10]
배타 록(Exclusive Lock)
트랜잭션이 자료를 기록할 때 배타 록 X를 걸어야 한다. 록 X를 가진 트랜잭션은 자료를 읽을 수도 있고, 갱신할 수도 있다. 배타 록 X가 걸린 자료는 공유 록 S를 가진 트랜잭션들에 의해서 읽혀질 수 없는데 Dirty Read를 방지하기 위해서이다.[10]
기능
무정지성
트랜잭션 기능의 대표적인 이점 중 하나는 무정 지성의 향상이다. 즉, OS 장애 등의 서버 장애가 발생하여 그로부터 데이터베이스를 재기 동한 때에 '장애 직전까지의 커밋 결과를 손실하지 않고 마치는 것'이 가능하다. 트랜잭션을 지원하지 않는 데이터베이스의 경우 OS 장애뿐만 아니라 데이터베이스 프로세스가 비정상적으로 종료하기만 해도 데이터베이스가 손상될 수 있다. 깨진 데이터베이스를 복구하려고 해도 일부 데이터가 없어지거나 완전히 복구되지 않는 등 완전한 회복이 불가능한 경우도 많다. Oracle과 InnoDB 같은 트랜잭션 대응의 데이터베이스에서는 이러한 문제가 발생하지 않는데, REDO 로그(데이터베이스에서 수행한 작업을 다시 실행하는 로그)를 이용한 아키텍처로 무정 지성을 보장하고 있기 때문이다.
- REDO 로그: 열 값과 인덱스를 갖는 데이터 파일에는 커밋을 할 때마다 기록을 하는 것이 아니라 캐시 영역에 보관해 두고 정기적으로 디스크에 기록하는 동작을 하는데 REDO 로그 파일이 최신 커밋 정보를 가지고 있는 반면, 본체의 데이터 파일은 오래된 데이터를 가지고 있게 된다. 그래도 캐시 영역에 최신 데이터가 있기 때문에 데이터 파일에 이전 데이터밖에 없더라도 애플리케이션에서 보면 최신 데이터를 읽고 쓸 수 있어 모순된 상태가 되지는 않는다. 서버 장애 등의 이유로 데이터베이스가 멈춰서 재기동을 하게 되는 경우 데이터 파일이 이전 데이터밖에 남지 않았을 때 REDO 로그의 내용을 데이터 파일에 적용시켜 나감으로써 데이터 파일과 REDO 로그의 LSN과 일치시키는 작업을 수행한다. 이 과정을 충돌 복구(Clash Recovery)라고 한다.
각주
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 〈트랜잭션 성질〉, 《Tistory - victolee》, 2018-02-09
- ↑ 〈트랜잭션 목적〉, 《위키백과》
- ↑ 〈트랜잭션 양식〉, 《Microsoft》, 2016-06-10
- ↑ 〈트랜잭션 양식〉, 《Microsoft》, 2016-09-09
- ↑ 5.0 5.1 5.2 5.3 5.4 5.5 〈트랜잭션 특징〉, 《Tistory - 코딩팩토리》, 2018-08-20
- ↑ 6.0 6.1 〈트랜잭션 성질〉, 《Tistory - 개발자 홀로 서기》, 2017-02-27
- ↑ 7.0 7.1 7.2 7.3 〈트랜잭션 성질〉, 《Tistory - Lim-Ky》, 2017-10-06
- ↑ 8.0 8.1 8.2 8.3 〈트랜잭션 성질〉, 《Tistory - 망나니 개발자》, 2017-12-12
- ↑ 9.0 9.1 9.2 〈트랜잭션 성질〉, 《Tistory - kmmguumnn》, 2019-03-03
- ↑ 10.0 10.1 10.2 10.3 10.4 〈트랜잭션 종류 및 병행제어〉, 《Tistory - jhkang-dev》, 2018-11-28
- ↑ 11.0 11.1 11.2 〈트랜잭션 필요성 및 연산〉, 《Tistory - 쩨리쩨리》, 2018-04-24
참고자료
- 데이터베이스 트랜잭션 <트랜잭션 목적〉, 《위키백과》
- Begin the transaction〈트랜잭션 양식〉, 《Microsoft》, 2016-06-10
- Commit the transaction〈트랜잭션 양식〉, 《Microsoft》, 2016-09-09
- 트랜잭션 <트랜잭션 특징〉, 《Tistory - 코딩팩토리》, 2018-08-20
- 트랜잭션(Transaction)이란? <트랜잭션 성질〉, 《Tistory - 개발자 홀로 서기》, 2017-02-27
- [DB이론] 트랜잭션(transaction)과 ACID 특성을 보장하는 방법 〈트랜잭션 성질〉, 《Tistory - victolee》, 2018-02-09
- [Database] 8. 트랜잭션, 동시성 제어, 회복 〈트랜잭션 성질〉, 《Tistory - 망나니 개발자》, 2017-12-12
- [DataBase] 트랜잭션이란? (Transaction) 〈트랜잭션 성질〉, 《Tistory - Lim-Ky》, 2017-10-06
- 트랜잭션(Transaction)이란? 〈트랜잭션 성질〉, 《Tistory - kmmguumnn》, 2019-03-03
- [SQL] Transaction(트랜잭션) <트랜잭션 필요성〉, 《Tistory - 쩨리쩨리》, 2018-04-24
- [데이터베이스] 트랜잭션 〈트랜잭션 종류 및 병행제어〉, 《Tistory - jhkang-dev》, 2018-11-28
같이 보기
