1. 소개
사용자 입장에서 트랜잭션은 발생하거나 발생하지 않는 단일 변경 이벤트라고 생각할 수 있습니다. 구현자의 입장에서 트랜잭션은 분산 컴퓨팅에 참여할 수 있는 모듈을 작성할 수 있게 해주는 프로그래밍 스타일이라고 생각할 수 있습니다. 예를 들어, 한 은행 계좌에서 다른 계좌로 송금하는 경우를 생각해 봅니다.
이 때 구현자와 사용자가 원하는 것은 두 계좌가 모두 변경되거나 모두 변경되지 않는 것입니다.
분산 시스템에서는 컴퓨터가 실패하거나 메시지가 손실될 수 있기 때문에 이러한 목적을 이루기가 어렵습니다.
트랜잭션은 작업 세트를 원자적 실행 단위로 묶을 수 있는 방법을 제공합니다.
원자적인 "전부 아니면 전혀" 속성은 낯선 개념이 아니며 일상의 많은 분야에 나타납니다.
예를 들어, 결혼식에서 주례는 "이 사람을 배우자로 맞겠습니까?"라고 신랑과 신부에게 묻습니다. 신랑과 신부 모두가 "예"라고 대답하면 주례가 성혼을 선언합니다.
신랑, 신부 둘중 한명이라도 "싫어요" 하면 결혼은 파토가 난거죠. Rollbak이 일어 나는거죠. 결혼을 위해 노력했던 모든 것이 원점으로 돌아가는거죠. 슬픈 일이지만 … 어쩔수 없죠..
이러한 예는 트랜잭션의 기본 원칙, 즉 독립적인 여러 엔티티가 동의해야 함을 보여줍니다. 어느 한 쪽이라도 동의하지 않으면 거래는 성사되지 않습니다.
모두가 동의하고 나면 거래(트랜잭션)가 이루어질 수 있습니다.
응용 프로그램은 트랜잭션 관리자의 BeginTransaction 메서드를 호출하여 트랜잭션을 시작합니다.
그러면 트랜잭션을 표현하는 트랜잭션 개체가 만들어집니다.
그런 다음 응용 프로그램은 리소스 관리자를 호출하여 트랜잭션 작업을 수행합니다.
응용 프로그램이 각 리소스 관리자를 처음 호출할 때 응용 프로그램의 현재 트랜잭션이 확인됩니다.
예를 들어, 응용 프로그램이 관계형 데이터베이스를 사용하는 경우 응용 프로그램은 트랜잭션 개체를 ODBC 연결과 조합하는 ODBC 인터페이스를 호출합니다.
이후부터 그 연결을 통해 이루어지는 모든 데이터베이스 호출은 트랜잭션이 끝날 때까지 트랜잭션을 위해 수행됩니다.
리소스 관리자는 트랜잭션을 위해 처음 작업을 수행할 때 트랜잭션 관리자를 호출하여 트랜잭션에 참여합니다.
트랜잭션이 진행될 때 트랜잭션 관리자는 트랜잭션에 참여한 각 리소스 관리자를 추적합니다.
대개 응용 프로그램은 Commit 트랜잭션 메서드를 사용하여 트랜잭션을 완료합니다.
응용 프로그램은 트랜잭션을 완료할 수 없는 경우 Abort 트랜잭션 메서드를 호출하여 트랜잭션의 작업을 취소합니다.
응용 프로그램이 실패하면 MS DTC가 트랜잭션을 중단합니다.
응용 프로그램은 트랜잭션의 작업을 성공적으로 완료하면 트랜잭션을 커밋하기 위해 MS DTC를 호출합니다.
그러면 MS DTC는 2단계 커밋 프로토콜을 차례로 수행하여 커밋을 위해 참여한 모든 리소스 관리자를 얻습니다.
2단계 커밋 프로토콜은 리소스 관리자 모두가 트랜잭션을 커밋하거나 모두 트랜잭션을 중단하도록 보장합니다.
첫째 단계에서 MS DTC는 각 리소스 관리자에게 커밋할 준비가 되었는지 묻습니다.
모든 참여자가 "예"라고 답하면 둘째 단계에서 MS DTC는 커밋 메시지를 모두에게 브로드캐스트합니다.
트랜잭션의 어느 부분에서든 실패하거나, 리소스 관리자가 준비 요청에 응답하지 못하거나 또는 리소스 관리자가 "아니오"라고 응답하면
MS DTC는 모든 리소스 관리자에게 트랜잭션이 중단되었음을 알립니다.
2. ACID 속성
트랜잭션은 ACID 속성을 제공합니다.
1) 원자성(Atomicity) : 한 트랜잭션이 커밋되거나 중단됩니다. 한 트랜잭션이 커밋되면 모든 효과가 유지됩니다. 한 트랜잭션이 중단되면 모든 효과가 취소됩니다.
예를 들어, 개체 이름을 바꾸는 경우 새 이름이 만들어지고 이전 이름이 삭제되거나(커밋) 또는 아무 변화도 발생하지 않습니다(중단).
2) 일관성(Consistency) : 트랜잭션은 시스템 상태의 올바른 변환입니다. 트랜잭션은 상태를 일관되게 보존합니다. 예를 들어, 이중 연결된 목록에 요소를 추가하면 정방향 및 역방향 포인터 네 개가 모두 업데이트됩니다.
3) 격리(Isolation) : 동시적 트랜잭션은 완료되지 않은 다른 트랜잭션의 업데이트로부터 격리됩니다. 이러한 업데이트는 일관된 상태를 만들지 않습니다. 이 속성을 연속성이라고도 합니다.
예를 들어, 일관성 예제에서 언급한 이중 연결된 목록을 지나는 두 번째 트랜잭션은 삽입 전 또는 후에 목록을 보지만 완전한 변경 내용만을 봅니다.
4) 영속성(Durability) : 트랜잭션이 일단 커밋되면 시스템에 오류가 발생하더라도 그 효과는 지속됩니다. 예를 들어, 원자성 예제에서 커밋이 완료된 직후 시스템에 오류가 발생하여 시스템을
다시 시작하더라도 개체는 새 이름을 갖게 됩니다. 일관성을 결정하고 이들 일관된 변환의 경계를 정하기 위해 BeginTransaction 및 Commit 트랜잭션 메서드를 사용하여 컴퓨팅 범위를 정하는 것은 응용 프로그램의 몫입니다.
트랜잭션 리소스 관리자는 관리하는 개체에 대해 일관성, 격리 및 영속성을 갖는 변환을 제공합니다. MS DTC는 여러 컴퓨터에 분산되어 있을 수도 있는 여러 리소스 관리자와 관련된 트랜잭션을 관리합니다.
MS DTC는 트랜잭션 개체를 만들고, 리소스 관리자 사이에서 트랜잭션의 마이그레이션을 추적하고, 2단계 커밋 프로토콜을 구현하여 이러한 트랜잭션이 원자성과 영속성을 갖게 합니다.
3. 실행 시나리오
1) 응용 프로그램 프로그래머 입장에서의 트랜잭션
응용 프로그램 프로그래머의 트랜잭션 모델은 매우 단순합니다.
즉, 응용 프로그램은 성공하거나 아니면 실패합니다.
응용 프로그램은 트랜잭션 개체를 얻는 일로부터 트랜잭션을 시작합니다.
이후의 모든 작업은 그 트랜잭션 개체와 연결됩니다.
프로그램은 일관된 상태에 도달하면 Commit 트랜잭션 메서드를 호출합니다.
커밋에 성공하면 트랜잭션은 영속적으로 커밋됩니다.
커밋에 실패하면 트랜잭션은 중단됩니다.
트랜잭션을 완료할 수 없는 경우 프로그램은 Abort 트랜잭션 메서드를 호출하여 트랜잭션의 효과를 취소할 수도 있습니다.
이렇게 하면 복잡한 오류가 발생할 경우를 간단한 방법으로 처리할 수 있습니다.
트랜잭션을 커밋하기 전에 응용 프로그램이 실패하면 트랜잭션 관리자는 트랜잭션을 중단하고
참여한 각 리소스 관리자에게 트랜잭션의 효과를 취소하도록 알립니다.
컴퓨터 또는 리소스 관리자가 실패하는 경우에도 역시 트랜잭션은 중단됩니다.
트랜잭션이 일단 커밋에 성공하면 리소스 관리자와 트랜잭션 관리자는 이후에 오류가 발생하더라도 트랜잭션의 효과가 영속되도록 보장합니다.
2) 리소스 관리자 측면에서의 트랜잭션
리소스 관리자가 등장하여 가장 먼저 하는 일은 자신의 로컬 트랜잭션 관리자에 연결하여 리소스 관리자가 있음을 선언하는 것입니다.
그런 다음 리소스 관리자는 응용 프로그램으로부터 실행 요청이 있을 때까지 기다립니다.
새로운 트랜잭션 개체와 더불어 요청이 도착하면 리소스 관리자가 트랜잭션에 참여합니다.
참여를 통해 리소스 관리자는 트랜잭션이 커밋되거나 중단될 때 트랜잭션 관리자로부터 콜백을 얻도록 보장합니다.
그런 다음 리소스 관리자는 트랜잭션의 요청을 수행합니다.
예를 들어, 트랜잭션은 관계형 데이터베이스에 레코드를 삽입, 삭제 또는 업데이트할 수 있습니다.
리소스 관리자는 그러한 리소스에서 트랜잭션의 작업을 취소하거나 다시 실행할 수 있도록 충분한 정보를 유지합니다. 정보를 유지하는 방법은 많지만 일반적인 두 가지 기술은 데이터를 여러 버전으로 유지하는 것과 변경 내용에 대한 기록(업무 일지)을 유지하는 것입니다.
응용 프로그램이 트랜잭션을 커밋할 때 트랜잭션 관리자는 2단계 커밋 프로토콜을 시작합니다.
먼저 트랜잭션 관리자는 트랜잭션을 커밋할 준비가 되었는지를 참여한 각 리소스 관리자에게 묻습니다.
리소스 관리자는 커밋을 준비해야 합니다. 즉, 트랜잭션을 커밋하거나 중단할 수 있도록 자신을 준비해야 합니다.
대개 리소스 관리자는 이전 데이터와 새 데이터를 안정된 저장소에 기록하므로 시스템에 오류가 발생해도 리소스 관리자가 복원될 수 있습니다.
리소스 관리자는 성공적으로 준비할 수 없는 경우 트랜잭션 관리자에게 준비할 수 없음을 알리고 그러면 트랜잭션 관리자가 트랜잭션을 중단합니다. 커밋 준비를 할 수 있는 경우, 리소스 관리자는 트랜잭션 관리자에게 이를 알린 다음 트랜잭션을 커밋할지 중단할지에 대해 트랜잭션 관리자의 결정을 기다립니다.
일단 준비가 되면 리소스 관리자는 트랜잭션 관리자로부터 커밋 또는 중단 콜백을 얻을 때까지 기다려야 합니다. 일부 중단되는 트랜잭션도 있지만 대부분의 트랜잭션은 커밋됩니다.
대개 전체 준비 및 커밋 프로토콜이 두 번째 부분에서 완료됩니다.
시스템 또는 통신 오류가 발생하면 몇 분 또는 몇 시간 동안 커밋 알림이나 중단 알림이 도착하지 않을 수 있습니다.
그러는 동안 리소스 관리자는 트랜잭션의 결과에 대해 미확정 상태에 있습니다. 트랜잭션 관리자는 트랜잭션이 커밋되었는지 또는 중단되었는지 알지 못합니다. 리소스 관리자는 트랜잭션에 대해 확실하지 않은 동안 트랜잭션을 잠그고 그럼으로써 이 변경 내용을 다른 트랜잭션으로부터 격리하여 수정된 데이터를 보존합니다.
지금까지는 내결함성이 있는 환경에서 분산 트랜잭션이 어떻게 원자성을 갖게 되는지를 설명했습니다.
이제 MS DTC가 어떻게 리소스 관리자를 도와 리소스 관리자가 실패할 때에도 트랜잭션의 원자성과 영속성을 유지하는지 살펴봅니다.
리소스 관리자가 실패한 다음 다시 시작하는 경우 리소스 관리자는 관리하는 리소스의 커밋된 상태를 다시 구성해야 합니다.
재구성된 상태는 커밋된 트랜잭션의 효과는 모두 반영하지만 중단된 트랜잭션의 효과는 전혀 반영하지 않아야 합니다.
리소스 관리자가 실패하면 실패 이전에 준비되거나 커밋된 트랜잭션을 제외하고 참여한 모든 트랜잭션이 중단됩니다.
다시 시작될 때 리소스 관리자는 자신이 참여해 있는 미확정 트랜잭션의 결과를 트랜잭션 관리자에게 묻습니다.
트랜잭션 관리자는 각 미확정 트랜잭션의 결과를 리소스 관리자에게 알려주며 그에 따라 리소스 관리자는 이들 트랜잭션을 커밋하거나 중단합니다.
요약하면, 2단계 커밋 프로토콜과 리소스 관리자가 협력하여 트랜잭션의 원자성과 영속성을 유지합니다.
3) 트랜잭션 관리자 측면에서의 트랜잭션
트랜잭션 관리자는 트랜잭션 개체의 관리자입니다. 이 관리자는 트랜잭션 개체를 만들고 그것의 원자성과 영속성을 관리합니다. 응용 프로그램은 트랜잭션 관리자의 BeginTransaction 메서드를 호출하여 트랜잭션 개체를 만들도록 트랜잭션 관리자에 요청합니다.
리소스 관리자는 트랜잭션에 처음 참여할 때 트랜잭션 관리자를 호출하여 트랜잭션에 참여를 등록합니다.
트랜잭션 관리자는 트랜잭션에 참여하는 리소스 관리자를 추적합니다.
나중에 응용 프로그램은 트랜잭션을 커밋하거나 중단하며, 리소스 관리자나 오류에 의해서도 트랜잭션이 중단됩니다.
Commit과 Abort는 트랜잭션 가능한 개체에 적용되는 추가적인 트랜잭션 메서드입니다. 트랜잭션을 커밋하도록 요청받으면 트랜잭션 관리자가 2단계 커밋 프로토콜을 시작합니다. 1단계에서 트랜잭션 관리자는 참여한 모든 리소스 관리자에게 준비되었는지를 묻습니다.
2단계에서 트랜잭션 관리자는 트랜잭션이 커밋되었는지 또는 중단되었는지를 리소스 관리자에게 알립니다. 2단계 커밋 프로토콜은 읽기 전용 최적화와 커밋의 전송 최적화를 비롯하여 많은 최적화 기능을 가지고 있습니다. MS DTC는 이들 최적화 중 일부를 구현하지만 원자성과 영속성이라는 두 기능은 동일합니다.
트랜잭션 관리자는 디스크의 안전한 저장소에 로그를 유지합니다. 로그는 트랜잭션 이벤트를 기록하는 순차적 파일입니다.
트랜잭션 관리자는 트랜잭션 시작, 참여 및 커밋 결정을 로그에 기록합니다. 정상적인 처리 상황에서 트랜잭션 관리자는 로그에 쓰기만 합니다.
트랜잭션 관리자는 오류가 발생할 경우 로그를 읽어 트랜잭션의 최신 상태를 다시 구성합니다. 그러므로 트랜잭션 관리자는 로그를 이용하여 그 상태를 영속적으로 만듭니다.
트랜잭션 관리자는 트랜잭션 관리를 위한 작업 인터페이스도 제공합니다.
이 관리자는 시스템 성능 모니터를 사용하여 표시할 수 있는 성능 카운터를 유지합니다.
이 관리자는 중요한 작업 이벤트를 시스템 로그에 기록합니다. 시스템 이벤트 뷰어를 사용하여 이 이벤트를 표시할 수 있습니다.
이 관리자에는 SQL 엔터프라이즈 관리자와 통합되는 그래픽 관리 인터페이스가 있습니다. 운영자는 그래픽 관리 인터페이스를 통해 시스템을 구성하고, 트랜잭션을 보고, 미확정 트랜잭션을 중단하거나 커밋할 수 있습니다.
4. 분산 트랜잭션
지금까지의 설명에서는 모든 참여자와 리소스 관리자가 단일 컴퓨터에 있는 것을 전제로 했습니다. 그러나, MS DTC는 둘 이상의 Windows 시스템에 분산된 트랜잭션도 지원합니다. 각 시스템에는 로컬 트랜잭션 관리자가 있습니다. 모든 응용 프로그램과 리소스 관리자는 자신의 로컬 트랜잭션 관리자와 통신합니다. 트랜잭션 관리자들은 여러 시스템에 분산된 트랜잭션을 관리하기 위해 협동합니다.
트랜잭션이 새 시스템에 처음 도착하면(즉, 트랜잭션과 더불어 첫 번째 요청이 그 시스템에 도달하면) 요청과 연관된 두 시스템 간에 관계가 설정됩니다. 요청을 보내는 시스템은 트랜잭션이 두 번째 시스템의 트랜잭션 관리자와 송신 관계에 있음을 자신의 로컬 트랜잭션 관리자에게 알립니다. 마찬가지로, 요청을 받는 시스템은 트랜잭션이 첫 번째 시스템의 트랜잭션 관리자와 수신 관계에 있음을 자신의 로컬 트랜잭션 관리자에게 알립니다.
이러한 송수신 관계는 트랜잭션의 커밋 트리라고 하는 트랜잭션 관리자 관계의 트리를 형성합니다. 참여하는 리소스 관리자들은 자신의 로컬 트랜잭션 관리자와 송수신 관계에 있으므로 이들도 역시 이 커밋 트리의 구성원이 됩니다.
분산된 트랜잭션이 커밋되거나 중단될 때는 준비, 커밋 및 중단 메시지가 커밋 트리에서 전달됩니다. 트리의 모든 노드는 1단계에서 보내지는 준비 요청에 동의하기 전 어느 때든지 트랜잭션을 중단할 수 있습니다. 노드는 일단 준비되면 커밋 코디네이터가 트랜잭션의 커밋 또는 중단을 지시할 때까지 준비된 상태 및 미확정 상태로 있습니다. 커밋 트리의 루트 트랜잭션 관리자는 전역 커밋 코디네이터입니다. 이 관리자는 트랜잭션의 커밋 또는 중단을 결정하며 결코 미확정 상태가 되지 않습니다.
컴퓨터에 오류가 발생한 다음 다시 시작되면 그 컴퓨터의 트랜잭션 관리자가 모든 미확정 트랜잭션의 결과를 결정합니다. 트랜잭션 관리자는 로그 파일을 읽고 자신이 커밋 코디네이터의 역할은 맡은 트랜잭션의 결과를 결정합니다. 다른 시스템에서 받는 트랜잭션의 경우 트랜잭션 관리자는 로그 파일을 읽고 이전에 트랜잭션의 결과를 통보받았는지 확인합니다. 미확정 상태로 남아 있는 수신 트랜잭션의 경우, 트랜잭션 관리자는 트랜잭션의 결과를 알기 위해 수신 트랜잭션 관리자에 쿼리합니다. 트랜잭션 관리자는 또한 다른 트랜잭션 관리자로 보낸 미확정 송신 트랜잭션에 관하여 다른 트랜잭션 관리자의 쿼리에 응답합니다. 이것은 트랜잭션 관리자와 리소스 관리자가 다시 시작할 때 적용되는 프로토콜과 비슷합니다. 트랜잭션 관리자는 각 미확정 트랜잭션의 결과를 결정하고 질문을 받으면 리소스 관리자에게 트랜잭션의 결과를 알려줍니다.
미확정 트랜잭션은 특히 분산 트랜잭션에 어려운 문제를 초래합니다. 시스템 오류나 통신 오류가 발생하면 트랜잭션이 오랫동안 미확정 상태로 남을 수 있습니다. 트랜잭션이 미확정 상태인 동안 트랜잭션에 의해 수정된 리소스는 잠궈진 상태로 있으며 다른 트랜잭션에서 사용할 수 없습니다. MS DTC는 시스템 운영자가 너무 오랫동안 미확정 상태에 있는 트랜잭션을 해결할 수 있도록 방법을 제공합니다. 운영자는 커밋 코디네이터 시스템에서 그래픽 관리 인터페이스를 사용하여 트랜잭션의 결과를 확인할 수 있습니다. 운영자는 미확정 시스템에서 그래픽 관리 인터페이스를 사용하여 미확정 트랜잭션을 강제로 커밋하거나 중단할 수도 있습니다. 시스템이 다시 연결될 때 MS DTC는 운영자의 그러한 작업을 감지하고 일관성이 없는 작업을 표시합니다.
5. 개념 요약
트랜잭션은 실행의 ACID(원자성, 일관성, 격리, 영속성을 갖는) 모듈입니다. 트랜잭션은 COM의 프로그램 모듈 구조를 보완합니다. Microsoft Distributed Transaction Coordinator(MS DTC)는 각 컴퓨터에서 트랜잭션을 관리하는 트랜잭션 관리자를 개별 컴퓨터에 제공합니다.
응용 프로그램은 트랜잭션 관리자를 호출하여 트랜잭션을 시작합니다. BeginTransaction은 트랜잭션 개체를 반환합니다. 응용 프로그램은 리소스 관리자로 보내는 요청과 함께 트랜잭션 개체를 포함합니다. 리소스 관리자는 트랜잭션에 대해 처음 작업을 시작할 때 트랜잭션에 참여합니다. 응용 프로그램은 상태의 일관성 있는 변환을 수행할 때 Commit 트랜잭션 메서드를 사용하여 트랜잭션 관리자에게 트랜잭션을 커밋하도록 요청합니다.
응용 프로그램은 트랜잭션을 완료할 수 없는 경우 Abort 트랜잭션 메서드를 호출하여 트랜잭션을 취소합니다. 응용 프로그램이 실패하거나 참여하는 리소스 관리자가 실패하면 MS DTC가 트랜잭션을 중단합니다.
MS DTC는 2단계 커밋 알고리즘을 사용합니다. 이 알고리즘에서 (1)트랜잭션 관리자는 참여한 각 리소스 관리자에게 커밋을 준비하도록 요청하고, (2)모든 리소스 관리자가 준비에 성공하면 트랜잭션 관리자가 커밋 결정을 모두에게 브로드캐스트합니다.
준비할 수 없는 리소스 관리자가 하나라도 있으면 트랜잭션 관리자는 트랜잭션에 관련된 모두에게 중단 결정을 브로드캐스트합니다. 리소스 관리자는 준비하는 동안 트랜잭션이 커밋되었는지 또는 중단되었는지 확실하게 알지 못합니다.
트랜잭션 관리자는 커밋 또는 중단 결정이 지속성을 가질 수 있도록 순차적인 로그를 유지합니다. 실패한 리소스 관리자나 트랜잭션 관리자는 다시 연결될 때 미확정 트랜잭션을 조정합니다.
분산 트랜잭션의 경우 각 컴퓨터에는 로컬 트랜잭션 관리자가 있습니다.
트랜잭션이 여러 컴퓨터에서 수행될 때는 트랜잭션 관리자가 수신 및 송신 트랜잭션을 추적합니다. 각 트랜잭션 관리자는 해당 컴퓨터의 로컬 리소스 관리자를 위해 모든 참여, 준비, 커밋 및 중단 호출을 수행합니다.
여러 컴퓨터에 걸쳐 분산된 트랜잭션을 커밋할 때 트랜잭션 관리자는 자신의 모든 전송 트랜잭션 관리자에게 준비, 커밋 및 중단 메시지를 보냅니다.
트랜잭션 관리자는 분산 트랜잭션이 확실하지 않으면 수신 트랜잭션 관리자에 쿼리합니다.
루트 트랜잭션 관리자는 절대 미확정 상태가 되지 않습니다. 미확정 트랜잭션이 너무 오래 지속되면 시스템 운영자가 트랜잭션을 강제로 커밋하거나 중단할 수 있습니다
'SQL > ORACLE' 카테고리의 다른 글
SQL TRIGGER (0) | 2014.06.11 |
---|---|
[본문스크랩] Oracle9i 용어집 (0) | 2014.06.11 |
오라클임시테이블 생성 GLOBAL TEMPORARY TABLE (0) | 2014.06.11 |
[오라클 시퀀스] 시퀀스 생성 및 사용하기 [CREATE SEQUENCE] (0) | 2014.06.11 |
오라클 INDEX(인덱스) 작성시 주의사항 (0) | 2014.06.11 |
[오라클함수] 오라클 함수 정리 (0) | 2014.06.11 |
오라클 - 데이터 가져오기편 3 (0) | 2014.06.11 |
오라클 - 데이터 가져오기편 2 (0) | 2014.06.11 |