위키원
"트랜잭션"의 두 판 사이의 차이
| 35번째 줄: | 35번째 줄: | ||
<ref name="트랜잭션"> 〈[https://coding-factory.tistory.com/226 트랜잭션 특징]〉, 《Tistory - 코딩팩토리》, 2018-08-20</ref> | <ref name="트랜잭션"> 〈[https://coding-factory.tistory.com/226 트랜잭션 특징]〉, 《Tistory - 코딩팩토리》, 2018-08-20</ref> | ||
| − | === | + | === ACID === |
| − | [[데이터베이스]]의 트랜잭션이 안전하게 수행되기 위해서는 ACID 조건을 충족해야 한다. '''ACID'''란 Atomicity, Consistency, Isolation, Durability의 약자로서, 데이터베이스의 트랜잭션이 안전하게 수행되기 위한 4가지 필수적인 성질인 원자성, 일관성, 고립성, 지속성을 말한다. | + | [[데이터베이스]]의 트랜잭션이 안전하게 수행되기 위해서는 ACID 조건을 충족해야 한다. '''ACID'''란 Atomicity, Consistency, Isolation, Durability의 약자로서, 데이터베이스의 트랜잭션이 안전하게 수행되기 위한 4가지 필수적인 성질인 원자성, 일관성, 고립성, 지속성을 말한다. |
| − | + | ||
| − | + | ==== 원자성(atomicity) ==== | |
| + | 원자성은 하나의 트랜잭션이 더 이상 작게 쪼갤 수 없는 최소한의 업무 단위이다. 트랜잭션이 데이터베이스에 모두 반영되던지, 아니면 전혀 반영되지 않아야 하며 작업이 부분적으로 실행되거나 중단되지 않는 것을 보장하는 것으로 즉, All or Nothing의 개념으로서 작업 단위를 일부분만 실행하지 않는다는 것을 의미한다. 트랜잭션 실행 도중 문제가 발생했을 경우 중단된 상태가 아닌 모두 실패하거나, 모두 완성되거나 둘 중 하나의 상태가 되어야 한다. 즉, 100개 명령어로 구성된 트랜잭션 중 99개 완료 1개 실패가 된다면, 이는 무조건 실패로 간주하여 트랜잭션 시작 전 상태로 돌려야 한다. 또한 100개가 모두 성공했을 시 트랜잭션은 성공이기 때문에 중간 상태가 없다. 트랜잭션은 사람이 설계한 논리적인 작업 단위이기 때문에 일처리가 작업 단위 별로 이루어져야 사람이 다루는데 무리가 없다. 만약 트랜잭션 단위로 데이터가 처리되지 않는다면, 설계한 사람은 데이터 처리 시스템을 이해하기 힘들 뿐만 아니라, 오작동 했을 시 원인을 찾기가 매우 힘들어진다. 트랜잭션 내의 모든 명령은 반드시 완벽하게 수행되어야 한며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다. 트랜잭션이 원자성이라는 성질을 지니게 된 이유는 중간에 끊기게 되면 이후 해당 트랜잭션의 어디서부터 이어서 수행되어야 하는지 모르기 때문이다. <ref name="트랜잭션 성질">〈[https://mommoo.tistory.com/62 트랜잭션 성질]〉, 《Tistory - 개발자 홀로 서기》, 2017-02-27</ref><ref name="트랜잭션 성질2">〈[https://victorydntmd.tistory.com/129 트랜잭션 성질]〉, 《Tistory - victolee》, 2018-02-09</ref><ref name="트랜잭션 성질3">〈[https://limkydev.tistory.com/100 트랜잭션 성질]〉, 《Tistory - Lim-Ky》, 2017-10-06</ref><ref name="트랜잭션 성질4">〈[https://mangkyu.tistory.com/30 트랜잭션 성질]〉, 《Tistory - 망나니 개발자》, 2017-12-12</ref> | ||
| + | * 원자성 보장 | ||
| + | 트랜잭션에서 원자성은 수행하고 있는 트랜잭션에 의해 변경된 내역을 유지하면서, 이전에 commit된 상태를 임시 역역에 따로 저장함으로써 보장한다. 즉, 현재 수행하고 있는 트랜잭션에서 오류가 발생하면 현재 내역을 날려버리고 임시 영역에 저장했던 상태로 rollback한다. 이전 데이터들이 임시로 저장되는 영역을 롤백 세그번트(rollback segment)라고 하며, 현재 수행하고 있는 트랜잭션에 의해 새롭게 변경되는 내역을 데이터베이스 테이블이라고 한다. 다시 말해, 트랜잭션의 원자성은 롤백 세그먼트에 의해 보장된다고 할 수 있다. 그런데 오류가 발생하면 rollback하는데, 트랜잭션의 길이가 길어지면 어떻게 될까? 이 경우 확실하게 오류가 발생하지 않는 부분도 다시 처음부터 작업을 수행해야 한다. 따라서 확실한 부분에 대해서는 rollback이 되지 않도록 중간 저장 지점인 save point를 지정할 수 있다. save point를 지정하게 되면 rollback 할 때 save point 이전은 확실하다 간주하고 그 이후부터 진행하게 된다.<ref name="트랜잭션"/><ref name="트랜잭션 성질"/><ref name="트랜잭션 성질2"/><ref name="트랜잭션 성질4"/><ref name="트랜잭션 성질5">〈[https://starkying.tistory.com/entry/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98Transaction%EC%9D%B4%EB%9E%80 트랜잭션 성질]〉, 《Tistory - kmmguumnn》, 2019-03-03</ref> | ||
| + | |||
| + | ==== 일관성(consistency) ==== | ||
| + | 일관성은 트랜잭션이 완료된 결과값이 일관적인 DB 상태를 유지하는 것을 말한다. 시스템이 가지고 있는 고정요소는 수행 전과 후의 상태가 같아야 하며 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것으로 트랜잭션이 진행되는 동안 데이터베이스가 변경되더라도 업데이트된 데이터베이스로 트랜잭션이 진행되는 것이 아니라, 처음 트랜잭션을 진행하기 위해 참조한 데이터베이스로 진행된다. 이렇게 함으로써 각 사용자가 일관성 있는 데이터를 볼 수 있는 것이다. 트랜잭션 수행 전후의 데이터베이스 상태는 각각 일관성이 보장되는 서로 다른 상태가 된다. 트랜잭션 수행이 보존해야 할 일관성은 기본키, 외래 키 제약과 같은 명시적인 무결성 제약 조건들 뿐만 아니라, A에서 B로 돈을 이체할 때 A와 B계좌의 돈의 총합이 같아야 한다는 사항과 같은 비명시적인 일관성 조건들도 있다.<ref name="트랜잭션"/><ref name="트랜잭션 성질"/> | ||
| + | |||
| + | |||
* 고립성(isolation) : 트랜잭션을 수행하는 도중에 다른 연산 작업이 끼어들어서는 안 된다. 하나의 특정 트랜잭션이 완료될 때까지, 다른 트랜잭션의 결과를 참조할 수 없다.<ref name="트랜잭션 성질"/> | * 고립성(isolation) : 트랜잭션을 수행하는 도중에 다른 연산 작업이 끼어들어서는 안 된다. 하나의 특정 트랜잭션이 완료될 때까지, 다른 트랜잭션의 결과를 참조할 수 없다.<ref name="트랜잭션 성질"/> | ||
| + | |||
* 지속성(durability) : 성공적으로 수행된 트랜잭션은 영구적으로 반영되어야 한다. | * 지속성(durability) : 성공적으로 수행된 트랜잭션은 영구적으로 반영되어야 한다. | ||
| 61번째 줄: | 70번째 줄: | ||
* 부분 완료(Partially Committed): 트랜잭션의 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태이다. | * 부분 완료(Partially Committed): 트랜잭션의 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태이다. | ||
* 완료(Committed): 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태이다.<ref name="트랜잭션"/> | * 완료(Committed): 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태이다.<ref name="트랜잭션"/> | ||
| + | |||
| + | == 기능 == | ||
| + | === 무정지성 === | ||
| + | 트랜잭션 기능의 대표적인 이점 중 하나는 무정지성의 향상이다. 즉, OS 장애 등의 서버 장애가 발생하여 그로부터 데이터베이스를 재기동한 때에 '장애 직전까지의 커밋 결과를 손실하지 않고 마치는 것'이 가능하다. 트랜잭션을 지원하지 않는 데이터베이스의 경우 OS 장애뿐만 아니라 데이터베이스 프로세스가 비정상적으로 종료하기만 해도 데이터베이스가 손상될 수 있다. 깨진 데이터베이스를 복구하려고 해도 일부 데이터가 ㅇ벗어지거나 완전히 복구되지 않는 등 완전한 회복이 불가능한 경우도 많다. Oracle과 InnoDB 같은 트랜잭션 대응의 데이터베이스에서는 이러한 문제가 발생하지 않는데, REDO 로그(데이터베이스에서 수행한 작업을 다시 실행하는 로그)를 이용한 아키텍처로 무정지성을 보장하고 있기 때문이다. | ||
| + | * REDO 로그: 열 값과 인덱스를 갖는 데이터 파일에는 커밋을 할 때마다 기록을 하는 것이 아니라 캐시 영역에 보관해 두고 정기적으로 디스크에 기록하는 동작을 하는데 REDO 로그 파일이 최신 커밋 정보를 가지고 있는 반면, 본체의 데이터 파일은 오래된 데이터를 가지고 있게 된다. 그래도 캐시 여역에 최신 데이터가 있기 때문에 데이터 파일에 이전 데이터밖에 없더라도 애플리케이션에서 보면 최신 데이터를 읽고 쓸 수 있어 모순된 상태가 되지는 않는다. 서버 장애 등의 이유로 데이터베이스가 멈춰서 재기동을 하게 되는 경우 데이터 파일이 이전 데이터밖에 남지 않았을 때 REDO 로그의 내용을 데이터 파일에 적용시켜 나감으로써 데이터 파일과 REDO 로그의 LSN과 일치시키는 작업을 수행한다. 이 과정을 충돌 복구(Clash Recovery)라고 한다. | ||
{{각주}} | {{각주}} | ||
2020년 9월 4일 (금) 11:33 판
트랜잭션(transaction)이란 "쪼갤 수 없는 업무 처리의 최소 단위"를 말한다. 거래내역이라고도 한다. '트렌젝션'이 아니라 '트랜잭션'이 올바른 표기법이다. 영어로 간략히 Tx라고 표기하기도 한다. 1초당 처리할 수 있는 트랜잭션의 개수를 TPS라고 한다.
목차
개요
트랜잭션은 은행 ATM이나 데이터베이스 등의 시스템에서 사용되는 더 이상 쪼갤 수 없는 업무 처리의 최소 단위이다. 예를 들어, A라는 사람이 B라는 사람에게 1,000원을 지급하고 B가 그 돈을 받은 경우, 이 거래 기록은 더 이상 작게 쪼갤 수가 없는 하나의 트랜잭션을 구성한다. 만약 A는 돈을 지불했으나 B는 돈을 받지 못했다면 그 거래는 성립되지 않는다. 이처럼 A가 돈을 지불하는 행위와 B가 돈을 받는 행위는 별개로 분리될 수 없으며 하나의 거래내역으로 처리되어야 하는 단일 거래이다. 이런 거래의 최소 단위를 트랜잭션이라고 한다. 트랜잭션 처리가 정상적으로 완료된 경우 커밋(commit)을 하고, 오류가 발생할 경우 원래 상태대로 롤백(rollback)을 한다.
목적
데이터베이스 기능 중, 트랜잭션을 조작하는 기능은 데이터베이스 완전성(integrity) 유지를 확신하게 한다. 단일 트랜잭션은 데이터베이스 내에 읽거나 쓰는 여러 개 쿼리를 요구한다. 이때 중요한 것은 데이터베이스가 수행된 일부 쿼리가 남지 않는 것이다. 예를 들어, 송금을 할 때 한 계좌에서 인출되면 다른 계좌에서 입금이 확인되는 것이 중요하다. 또한 트랜잭션은 서로 간섭하지 않아야 한다. 트랜색연의 특징에 대해서는 아래 자세히 설명되어 있다. 만약 쿼리 하나가 실패하면, 데이터베이스 시스템은 전체 트랜잭션 또는 실패한 쿼리를 롤백 한다. 이것은 DBMS가 어떻게 사용되고 셋업 되었느냐에 따라 다르다. 트랜잭션은 커밋전에 언제든지 수동으로 롤백 될 수 있다. 간단한 트랜잭션의 경우 아래 양식의 SQL 언어로 데이터베이스 내에서 실행된다. [1]
- Begin the transaction [2]
--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(트랜잭션이 성공적이며, 갱신이 실제 적용됨.)[3]
-- 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이 된다. [4]
ACID
데이터베이스의 트랜잭션이 안전하게 수행되기 위해서는 ACID 조건을 충족해야 한다. ACID란 Atomicity, Consistency, Isolation, Durability의 약자로서, 데이터베이스의 트랜잭션이 안전하게 수행되기 위한 4가지 필수적인 성질인 원자성, 일관성, 고립성, 지속성을 말한다.
원자성(atomicity)
원자성은 하나의 트랜잭션이 더 이상 작게 쪼갤 수 없는 최소한의 업무 단위이다. 트랜잭션이 데이터베이스에 모두 반영되던지, 아니면 전혀 반영되지 않아야 하며 작업이 부분적으로 실행되거나 중단되지 않는 것을 보장하는 것으로 즉, All or Nothing의 개념으로서 작업 단위를 일부분만 실행하지 않는다는 것을 의미한다. 트랜잭션 실행 도중 문제가 발생했을 경우 중단된 상태가 아닌 모두 실패하거나, 모두 완성되거나 둘 중 하나의 상태가 되어야 한다. 즉, 100개 명령어로 구성된 트랜잭션 중 99개 완료 1개 실패가 된다면, 이는 무조건 실패로 간주하여 트랜잭션 시작 전 상태로 돌려야 한다. 또한 100개가 모두 성공했을 시 트랜잭션은 성공이기 때문에 중간 상태가 없다. 트랜잭션은 사람이 설계한 논리적인 작업 단위이기 때문에 일처리가 작업 단위 별로 이루어져야 사람이 다루는데 무리가 없다. 만약 트랜잭션 단위로 데이터가 처리되지 않는다면, 설계한 사람은 데이터 처리 시스템을 이해하기 힘들 뿐만 아니라, 오작동 했을 시 원인을 찾기가 매우 힘들어진다. 트랜잭션 내의 모든 명령은 반드시 완벽하게 수행되어야 한며, 모두가 완벽히 수행되지 않고 어느 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다. 트랜잭션이 원자성이라는 성질을 지니게 된 이유는 중간에 끊기게 되면 이후 해당 트랜잭션의 어디서부터 이어서 수행되어야 하는지 모르기 때문이다. [5][6][7][8]
- 원자성 보장
트랜잭션에서 원자성은 수행하고 있는 트랜잭션에 의해 변경된 내역을 유지하면서, 이전에 commit된 상태를 임시 역역에 따로 저장함으로써 보장한다. 즉, 현재 수행하고 있는 트랜잭션에서 오류가 발생하면 현재 내역을 날려버리고 임시 영역에 저장했던 상태로 rollback한다. 이전 데이터들이 임시로 저장되는 영역을 롤백 세그번트(rollback segment)라고 하며, 현재 수행하고 있는 트랜잭션에 의해 새롭게 변경되는 내역을 데이터베이스 테이블이라고 한다. 다시 말해, 트랜잭션의 원자성은 롤백 세그먼트에 의해 보장된다고 할 수 있다. 그런데 오류가 발생하면 rollback하는데, 트랜잭션의 길이가 길어지면 어떻게 될까? 이 경우 확실하게 오류가 발생하지 않는 부분도 다시 처음부터 작업을 수행해야 한다. 따라서 확실한 부분에 대해서는 rollback이 되지 않도록 중간 저장 지점인 save point를 지정할 수 있다. save point를 지정하게 되면 rollback 할 때 save point 이전은 확실하다 간주하고 그 이후부터 진행하게 된다.[4][5][6][8][9]
일관성(consistency)
일관성은 트랜잭션이 완료된 결과값이 일관적인 DB 상태를 유지하는 것을 말한다. 시스템이 가지고 있는 고정요소는 수행 전과 후의 상태가 같아야 하며 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 것으로 트랜잭션이 진행되는 동안 데이터베이스가 변경되더라도 업데이트된 데이터베이스로 트랜잭션이 진행되는 것이 아니라, 처음 트랜잭션을 진행하기 위해 참조한 데이터베이스로 진행된다. 이렇게 함으로써 각 사용자가 일관성 있는 데이터를 볼 수 있는 것이다. 트랜잭션 수행 전후의 데이터베이스 상태는 각각 일관성이 보장되는 서로 다른 상태가 된다. 트랜잭션 수행이 보존해야 할 일관성은 기본키, 외래 키 제약과 같은 명시적인 무결성 제약 조건들 뿐만 아니라, A에서 B로 돈을 이체할 때 A와 B계좌의 돈의 총합이 같아야 한다는 사항과 같은 비명시적인 일관성 조건들도 있다.[4][5]
- 고립성(isolation) : 트랜잭션을 수행하는 도중에 다른 연산 작업이 끼어들어서는 안 된다. 하나의 특정 트랜잭션이 완료될 때까지, 다른 트랜잭션의 결과를 참조할 수 없다.[5]
- 지속성(durability) : 성공적으로 수행된 트랜잭션은 영구적으로 반영되어야 한다.
필요성
트랜잭션은 거래의 안전성을 확보하는 방법인데 데이터베이스에선 테이블에서 데이터를 읽어 온 후 다른 테이블에 데이터를 입력하거나 갱신, 삭제하는데 처리 도중 오류가 발생하면 모든 작업을 원상태로 되돌린다. 데이터베이스에서는 처리 과정이 모두 성공했을 때만 최종적으로 데이터베이스에 반영한다.
위 그림을 보자 1,2번까지 잘 실행되다가 3번 작업 시 소프트웨어가 중단되거나 하드웨어 고장이 발생해 작업에 오류가 생기게 된다면 2번까지의 모든 작업을 취소하고 트랜잭션 작업 전인 데이터베이스 초기 상태로 돌아가게 된다. [10]
연산
.png)
- Commit: Commit 연산은 한 개의 논리적 단위(트랜잭션)에 대한 작업이 성공적으로 끝났고 데이터베이스가 다시 일관된 상태에 있을 때, 트랜잭션이 행한 갱신 연산이 완료된 것을 트랜잭션 관리자에게 알려주는 연산이다.[4]위 그림에서 첫 번째 Commit 후 그 뒤에 Update 문으로 데이터를 갱신하고 Delete 문으로 데이터를 삭제한 후 Insert 문을 사용해 데이터를 삽입한다. 만약 이 모든 과정이 오류 없이 수행되었다면 지금까지 실행한 모든 작업을 데이터베이스에 영구 저장하라는 명령으로 Commit을 수행한다.[10]
.png)
- Rollback: Rollback 연산은 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨트렸을 때, 이 트랜잭션의 일부가 정상적으로 처리되더라도 트랜잭션의 원자성을 구현하기 위해 이 트랜잭션이 행한 모든 연산을 취소하는 연산이다. Rollback 시에는 해당 트랜잭션을 재시작하거나 폐기한다.[4] 위 그림에서 Rollback 명령은 마지막으로 수행한 Commit 명령까지만 정상 처리된 상태로 유지한다. 그 이후에 수행했던 모든 DML 명령어 작업들을 취소시켜 이전 상태로 원상 복귀 시킨다. 트랜잭션은 이렇든 ALL-OR-Nothing(모든 것을 수행하던지 아무것도 하지 말던지) 방식으로 DML 명령어들을 처리한다.[10]
상태
- 활동(Active): 트랜잭션이 실행중인 상태이다.
- 실패(Failed): 트랜잭션 실행에 오류가 발생하여 중단된 상태이다.
- 철회(Aborted): 트랜잭션이 비정상적으로 종료되어 Rollback 연산을 수행한 상태이다.
- 부분 완료(Partially Committed): 트랜잭션의 마지막 연산까지 실행했지만, Commit 연산이 실행되기 직전의 상태이다.
- 완료(Committed): 트랜잭션이 성공적으로 종료되어 Commit 연산을 실행한 후의 상태이다.[4]
기능
무정지성
트랜잭션 기능의 대표적인 이점 중 하나는 무정지성의 향상이다. 즉, OS 장애 등의 서버 장애가 발생하여 그로부터 데이터베이스를 재기동한 때에 '장애 직전까지의 커밋 결과를 손실하지 않고 마치는 것'이 가능하다. 트랜잭션을 지원하지 않는 데이터베이스의 경우 OS 장애뿐만 아니라 데이터베이스 프로세스가 비정상적으로 종료하기만 해도 데이터베이스가 손상될 수 있다. 깨진 데이터베이스를 복구하려고 해도 일부 데이터가 ㅇ벗어지거나 완전히 복구되지 않는 등 완전한 회복이 불가능한 경우도 많다. Oracle과 InnoDB 같은 트랜잭션 대응의 데이터베이스에서는 이러한 문제가 발생하지 않는데, REDO 로그(데이터베이스에서 수행한 작업을 다시 실행하는 로그)를 이용한 아키텍처로 무정지성을 보장하고 있기 때문이다.
- REDO 로그: 열 값과 인덱스를 갖는 데이터 파일에는 커밋을 할 때마다 기록을 하는 것이 아니라 캐시 영역에 보관해 두고 정기적으로 디스크에 기록하는 동작을 하는데 REDO 로그 파일이 최신 커밋 정보를 가지고 있는 반면, 본체의 데이터 파일은 오래된 데이터를 가지고 있게 된다. 그래도 캐시 여역에 최신 데이터가 있기 때문에 데이터 파일에 이전 데이터밖에 없더라도 애플리케이션에서 보면 최신 데이터를 읽고 쓸 수 있어 모순된 상태가 되지는 않는다. 서버 장애 등의 이유로 데이터베이스가 멈춰서 재기동을 하게 되는 경우 데이터 파일이 이전 데이터밖에 남지 않았을 때 REDO 로그의 내용을 데이터 파일에 적용시켜 나감으로써 데이터 파일과 REDO 로그의 LSN과 일치시키는 작업을 수행한다. 이 과정을 충돌 복구(Clash Recovery)라고 한다.
각주
- ↑ 〈트랜잭션 목적〉, 《위키백과》
- ↑ 〈트랜잭션 양식〉, 《Microsoft》, 2016-06-10
- ↑ 〈트랜잭션 양식〉, 《Microsoft》, 2016-09-09
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 〈트랜잭션 특징〉, 《Tistory - 코딩팩토리》, 2018-08-20
- ↑ 5.0 5.1 5.2 5.3 〈트랜잭션 성질〉, 《Tistory - 개발자 홀로 서기》, 2017-02-27
- ↑ 6.0 6.1 〈트랜잭션 성질〉, 《Tistory - victolee》, 2018-02-09
- ↑ 〈트랜잭션 성질〉, 《Tistory - Lim-Ky》, 2017-10-06
- ↑ 8.0 8.1 〈트랜잭션 성질〉, 《Tistory - 망나니 개발자》, 2017-12-12
- ↑ 〈트랜잭션 성질〉, 《Tistory - kmmguumnn》, 2019-03-03
- ↑ 10.0 10.1 10.2 〈트랜잭션 필요성 및 연산〉, 《Tistory - 쩨리쩨리》, 2018-04-24
참고자료
- 트랜잭션 <트랜잭션 특징〉, 《Tistory - 코딩팩토리》, 2018-08-20
- 데이터베이스 트랜잭션 <트랜잭션 목적〉, 《위키백과》
- Begin the transaction〈트랜잭션 양식〉, 《Microsoft》, 2016-06-10
- Commit the transaction〈트랜잭션 양식〉, 《Microsoft》, 2016-09-09
- [SQL] Transaction(트랜잭션) <트랜잭션 필요성〉, 《Tistory - 쩨리쩨리》, 2018-04-24</ref>
- 트랜잭션(Transaction)이란? <트랜잭션 성질〉, 《Tistory - 개발자 홀로 서기》, 2017-02-27</ref>
같이 보기
