| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 3. 향상된 특징 | Fast Forward | Next |
트랜잭션(transactions)은 모든 데이터베이스 시스템의 기초 개념입니다. 트랜잭션의 필수 요점은 트랜잭션이 단일의 혹은 전부 실행하거나 전혀 실행하지 않는 복합적인 단계를 나타낸다는 것입니다. 단계의 진행 상태는 동시에 움직이는 다른 트랜잭션에게 보이지 않습니다. 또한, 에러가 발생할 경우 트랜잭션은 완료되지 않으며 데이터베이스에 아무런 영향을 주지 않습니다.
예를 들어, 은행의 데이터베이스가 다수의 고객의 계좌 잔고와 지점의 총예금잔고를 기록하는 것을 생각해봅시다. Alice의 계좌로부터 $100.00를 Bob의 계좌로 송금한 것을 기록하고자 한다면, 극히 간략화 할 경우 SQL 구문은 다음과 같이 됩니다.
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
UPDATE branches SET balance = balance - 100.00
WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Alice');
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Bob';
UPDATE branches SET balance = balance + 100.00
WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');
여기서는 이러한 SQL 구문의 세부사항은 중요치 않습니다. 중요한 점은 이 단순한 연산을 완수하기 위해 개별적으로 독립된 업데이트가 연계된다는 것입니다. 은행 직원은 발생한 모든 업데이트 또는 아무런 업데이트도 발생하지 않았다는 것을 확신하고자합니다. 시스템의 실패로 인해 Alice로부터 인출되지 않아 Bob이 $100. 00을 받을 수 없는 상황이 일어나거나 Bob을 판명하는 단계 없이 Alice의 돈이 인출된다면 Alice는 은행의 고객으로 남지 않을 것입니다. 시스템의 실행 도중 일부 부적당한 상황이 발생할 경우, 결과에 영향을 줄 수 있는 어떠한 단계도 실행되지 않는다는 확증이 필요합니다. 이는 업데이트 되는 부분을 트랜잭션(transaction)에 그룹화하여 얻을 수 있습니다. 이는 트랜젝션이 다른 트랜젝션과 완전히 발생하였는가 전혀 발생하지 않았는가 하는 관점으로 원자성으로 불립니다.
한번 트랜잭션이 데이터시스템에 의해 승인되거나 완결되면, 영구적으로 기록되고 직후에 크래쉬가 발생하여도 손실되지 않습니다. 예를 들면, Bob이 자신의 계좌로부터 현금을 인출했을 때 은행 문을 나서자마자 시스템의 크래쉬로 인출 기록이 사라지는 것을 원하지 않습니다. 트랜젝션을 지원하는 데이터베이스에서는 트랜젝션의 완료를 보고하기 전에 영속적 기록 장치(즉 디스크상)에 모든 업데이트 부분이 트랜젝션이 로그되어지도록 만들어 보증하고 있습니다.
트랜젝션을 지원하는 데이터베이스의 또다른 중요한 특징은 원자적 갱신의 개념과 깊은 관계가 있습니다. 다수의 트랜젝션이 동시에 발생할 경우, 각각의 트랜젝션은 다른 트랜젝션으로 인한 미완료된 변경을 불 수 없도록 되어 있습니다. 예를 들면, 하나의 트랜잭션이 모든 지점의 잔고를 집계하는 작업으로 바빠 Alice의 계좌가 있는 지점이 Alice의 계좌 인출을 기록하지 않거나, Bob의 계좌가 있는 지점에서 이체를 기록하지 않는 경우가 일어나서는 안 될 것입니다. (반대의 경우도 포함) 즉, 트랜젝션이 데이터베이스에 영구적인 영향을 주는 경우 뿐만 아니라 트랜젝션의 발생하는 시점의 가시성을 염두하여 트랜젝션이 연산 전체가 처리되거나 전체가 처리되지 않도록 해야합니다. 작업중의 트랜젝션에 의한 갱신은 실행이 완료될 때까지 다른 트랜젝션에게 보여지지 않으며, 트랜잭션이 완료된 후에 모든 갱신 사항이 보여지게 됩니다.
PostgreSQL에서는 트랜잭션을 구성하는 SQL 구문을 BEGIN과 COMMIT의 트랜젝션으로 둘러싸 설정합니다. 은행 거래의 트랜잭션 다음과 같습니다.
BEGIN;
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
-- etc etc
COMMIT;
만약, 트랜젝션 처리 도중에 실행 처리를 원치 않는 경우가 생긴다면, (Alice 계좌의 잔고 부족과 같은 경우) COMMIT 을 대신하여 ROLLBACK 명령을 사용할 수 있습니다. 그리고 모든 갱신 사항은 취소되어 질 것입니다.
PostgreSQL는 실제 모든 SQL 명령문을 트랜잭션 내에서 실행하도록 되어 있습니다. 만약 BEGIN구문을 실행하지 않면, 각각의 명령문은 암묵적으로 BEGIN과 (성공적일 경우)COMMIT를 이용해 BEGIN을 감쌉니다. BEGIN 과 COMMIT에 의해 둘러싸인 명령문의 그룹은 트랜젝션 블록으로 일컬어지기도 합니다.
Note: 몇몇의 클라이언트 라이브러리는 자동적으로 BEGIN과 COMMIT 구문 실행하여, 질문 없이 트랜잭션 블록을 유효하게 합니다. 현재 사용하고 있는 인터페이스의 문서를 확인해주십시요.
세이브 포인트를 사용하여 트랜잭션(transaction)의 명령문을 보다 세밀하게 제어할 수 있습니다. 세이브 포인트는 트랜잭션(transaction)의 부분을 선택적으로 파기하도록 하며, 나머지 부분은 처리되도록 합니다. SAVEPOINT로 세이브 포인트를 정의한 후에 필요할 경우 ROLLBACK TO를 통해 세이브 포인트까지 롤백(rollback) 할 수 있습니다. 정의된 세이브 포인트와 롤백(rollback) 포인트 사이의 모든 트랜잭션 데이터베이스 변경은 파기되지만, 세이브 포인트 이전의 변경은 유지됩니다.
세이브 포인트까지 롤백(rollback)한 후에도 세이브 포인트는 계속적으로 정의되어진다. 그러므로 롤백(rollback)의 포인트 정의는 몇 회에 걸쳐 가능합니다. 반대로 특정한 세이브포인트를 재차 롤백(rollback)할 필요가 없다고 확신할 경우, 이는 해제되어 시스템의 몇가지 system 자원을 자유롭게 할 수 있습니다. 세이브 포인트를 해제하거나 세이브 포인트에 롤백(rollback) 하는 것은 자동적으로 그 후에 정의된 모든 세이브 포인트를 해제하는 것임을 명심하십시요.
이 모두는 트랜젝션 블록 내에서 발생하므로, 다른 데이터베이스 세션에 의해 노출되지 않습니다. 만약 트랜젝션 블록이 실행될 경우, 처리된 행동은 다른 세션에 의해 하나의 단위로 보여지게 됩니다. 그러나 롤백(rollback)에 의한 행동은 결코 가시화되지 않습니다.
은행 데이터베이스의 예를 떠올려 봅시다. Alice의 계좌로 부터 $100. 00을 인출하여 Bob의 계좌로 송금을 한다고 합니다. 그러나 시간이 지나 Bob이 아닌 Wally이 계좌로 송금되야 한단 것을 깨달았습니다. 이 경우 세이브포인트는 다음과 같이 사용될 수 있습니다.
BEGIN;
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
SAVEPOINT my_savepoint;
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Bob';
ROLLBACK TO my_savepoint;
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Wally';
COMMIT;
물론 이 예는 극단적으로 단순화되었지만, 세이브포인트의 사용을 통해 트랜잭션 블록의 많은 제어를 실시할 수 있다는 것을 알려줍니다. 게다가 에러로 인해 시스템이 트랜잭션 블록을 중단할 상황에 처할 경우, ROLLBACK TO은 롤백(rollback)를 완결시키지 않고 재개시 시키기 위해 제어를 되찾을 수 있는 유일한 수단입니다.