집 >데이터 베이스 >MySQL 튜토리얼 >트랜잭션 및 동시성 제어: DBMS

트랜잭션 및 동시성 제어: DBMS

Linda Hamilton원래의: 2025-01-05 16:07:44654검색

Transactions and Concurrency Controls: DBMS

DB 관리 시스템(DBMS)에서의 트랜잭션

정의:

데이터베이스 관리 시스템(DBMS)에서 트랜잭션은 단일 논리적 작업 단위로 수행되는 일련의 작업입니다. 트랜잭션에는 데이터베이스의 데이터 읽기, 삽입, 업데이트 또는 삭제가 포함될 수 있습니다. 트랜잭션의 주요 특징은 원자성이라는 것입니다. 즉, 트랜잭션 내의 모든 작업이 성공적으로 완료되거나 그 중 어느 것도 데이터베이스에 전혀 적용되지 않는다는 의미입니다.

거래의 주요 속성: ACID 속성

데이터베이스 일관성과 신뢰성을 보장하려면 트랜잭션이 ACID 속성을 준수해야 합니다. 이러한 속성은 다음과 같습니다.

원자성:
- 원자성은 트랜잭션이 분할할 수 없는 단일 작업 단위로 처리되도록 보장합니다. 트랜잭션 내의 모든 작업이 실행되거나 아무것도 실행되지 않습니다. 트랜잭션의 일부가 실패하면 전체 트랜잭션이 롤백되어 데이터베이스가 일관된 상태로 유지됩니다.
- 예: 거래에 계좌 A에서 계좌 B로 돈이 이체되는 경우 원자성은 전체 이체가 완료되거나(A에서 돈이 차감되고 B에 추가됨) 아무것도 수행되지 않음(돈이 이체되지 않음)을 보장합니다. 실패한 경우).
일관성:
- 일관성은 트랜잭션이 데이터베이스를 하나의 유효한 상태에서 다른 유효한 상태로 이동하도록 보장합니다. 모든 트랜잭션은 데이터베이스의 무결성 제약 조건(예: 기본 키, 외래 키 등)을 위반해서는 안 됩니다. 트랜잭션이 커밋된 후 데이터베이스는 항상 일관된 상태를 유지해야 합니다.
- 예: 두 은행 계좌 간에 자금을 이체한 후 두 계좌의 잔액 합계가 일정하게 유지되어야 합니다. 데이터베이스 일관성 규칙을 위반하면 트랜잭션이 롤백됩니다.
격리:
- 격리를 통해 트랜잭션 작업이 실행되는 동안 다른 트랜잭션으로부터 숨겨집니다. 여러 트랜잭션이 동시에 발생하더라도 각 트랜잭션은 다른 트랜잭션을 인식하지 않아야 합니다. 이를 통해 더티 읽기, 반복 불가능한 읽기 및 팬텀 읽기를 방지할 수 있습니다.
- 예: 두 명의 사용자가 동일한 은행 계좌에서 동시에 자금을 이체하는 경우 격리를 통해 한 거래가 다른 거래를 방해하지 않고 이중 인출과 같은 오류를 방지할 수 있습니다.
내구성:
- 내구성은 일단 트랜잭션이 커밋되면 시스템 충돌이 발생하는 경우에도 해당 변경 사항이 영구적임을 보장합니다. 커밋이 성공적으로 완료되면 트랜잭션의 변경 사항이 데이터베이스에 저장되며 손실되지 않습니다.
- 예: 사용자가 성공적으로 주문한 경우 커밋 직후 갑자기 정전이 발생하더라도 데이터베이스의 변경 사항(예: 재고 업데이트 및 주문 배치)이 지속되어야 합니다.

거래 유형

간단한 거래:
- 여기에는 데이터 읽기 또는 쓰기와 같은 단일 작업이 포함됩니다. 예를 들어 간단한 읽기 쿼리나 업데이트 쿼리가 트랜잭션의 일부일 수 있습니다.
복잡한 거래:
- 여기에는 읽기, 업데이트, 삽입, 삭제를 포함한 여러 작업이 포함됩니다. 복잡한 거래는 한 계좌에서 다른 계좌로 돈을 이체하는 등의 비즈니스 프로세스를 완료하기 위해 설계된 일련의 작업일 수 있습니다. 여기에는 계좌 잔액 확인, 한 계좌에서 차감, 다른 계좌 추가가 포함됩니다.

거래 수명주기

일반적인 거래는 다음 단계를 따릅니다.

거래 시작:
- 이것은 거래의 시작을 의미합니다. 새로운 거래가 곧 수행될 것임을 나타냅니다.
작업 수행:
- 트랜잭션은 레코드 선택, 삽입, 업데이트, 삭제 등 일련의 데이터베이스 작업을 수행합니다. 이러한 작업은 트랜잭션의 일부로 순차적으로 실행됩니다.
트랜잭션 커밋:
- 모든 작업이 완료된 후 트랜잭션이 커밋됩니다. 이는 트랜잭션으로 인한 모든 변경 사항이 데이터베이스에 영구적으로 저장됨을 의미합니다. 커밋된 후에는 트랜잭션을 롤백할 수 없습니다.
롤백 트랜잭션:
- 트랜잭션 실행 중에 오류나 실패(예: 제약 조건 위반)가 발생하면 트랜잭션이 롤백됩니다. 이는 트랜잭션으로 인한 모든 변경 사항이 취소되고 데이터베이스가 원래 상태로 돌아간다는 것을 의미합니다.
거래 종료:
- 커밋 또는 롤백 후에 트랜잭션이 종료됩니다. 이는 트랜잭션의 수명주기가 완료되었음을 의미합니다.

거래 상태

트랜잭션은 수명 주기 동안 다음 상태 중 하나여야 합니다.

활성:
- 거래의 초기 상태입니다. 트랜잭션은 작업을 실행하고 수행하는 동안 이 상태를 유지합니다.
부분적으로 약속:
- 이 상태는 트랜잭션의 마지막 문이 실행된 후에 발생합니다. 이 시점에서 트랜잭션은 모든 작업을 완료했지만 아직 데이터베이스에 커밋되지 않았습니다.
실패:
- 일반적으로 제약 조건 위반이나 시스템 오류 등의 문제로 인해 정상적인 실행을 더 이상 진행할 수 없는 것으로 확인되면 트랜잭션이 실패 상태가 됩니다.
중단됨:
- 트랜잭션이 롤백되고 데이터베이스가 트랜잭션 시작 이전 상태로 복원된 후에는 중단 상태가 됩니다.
약속됨:
- 모든 작업이 성공적으로 완료된 후 트랜잭션은 커밋됨 상태가 되고 해당 변경 사항이 데이터베이스에 영구적으로 적용됩니다.
해지됨:
- 트랜잭션이 커밋되거나 중단된 경우 종료된 것으로 간주됩니다. 트랜잭션이 커밋 또는 중단 상태에 도달하면 다시 시작할 수 없습니다.

DBMS의 일정

일정은 특정 순서로 실행되는 여러 트랜잭션의 일련의 작업입니다. 일정은 여러 트랜잭션에 대한 읽기 및 쓰기 작업의 실행 순서를 결정합니다. 주요 목표는 동시 트랜잭션이 상호 작용하는 방식을 결정하고 데이터베이스가 일관된 상태를 유지하는지 확인하는 것입니다.

일정은 연속 또는 비연속일 수 있습니다.

일정 유형

연재 일정:
- 직렬 스케줄은 인터리빙 없이 트랜잭션이 차례로 실행되는 스케줄입니다. 이는 다음 트랜잭션이 시작되기 전에 한 트랜잭션의 작업이 완전히 완료됨을 의미합니다.
- 직렬 스케줄에서는 동시성이 없으며 트랜잭션을 순차적으로 실행하는 것과 같습니다.

연재편성 예시:

트랜잭션 1: T1: 읽기(A); 쓰기(A); 저지르다
트랜잭션 2: T2: 읽기(B); 쓰기(B); 저지르다
트랜잭션은 차례로 실행되며, 작업이 중복되지 않습니다.

연속 외 일정:
- 비직렬 일정을 사용하면 여러 트랜잭션의 작업을 인터리브할 수 있습니다. 이러한 유형의 일정에서는 트랜잭션이 동시에 실행됩니다. 즉, 해당 작업이 함께 혼합됩니다.
- 비순차적 일정은 작업이 실행되는 순서에 따라 다른 결과로 이어질 수 있으며, 이는 ACID 속성을 유지하기 위한 세심한 관리가 필요합니다.

비연속 일정의 예:

T1: 읽기(A); 쓰기(A);
T2: 읽기(B); 쓰기(B);
T1: 커밋;
T2: 커밋;
트랜잭션 T1과 T2의 작업은 인터리브됩니다.

직렬화 가능성

직렬성은 여러 트랜잭션을 동시에 실행한 결과가 트랜잭션이 순차적으로 실행된 것과 동일하도록 보장하는 개념입니다. 데이터베이스에 미치는 영향 측면에서 일련의 일정과 동일한 일정을 직렬 가능이라고 합니다.

중요성:

직렬화 가능성의 목표는 동시 트랜잭션으로 인해 충돌이나 이상 현상(예: 더티 읽기, 업데이트 손실 등)이 발생하지 않도록 하고 데이터베이스가 일관된 상태를 유지하도록 하는 것입니다.

직렬화 가능성에는 두 가지 주요 유형이 있습니다.

직렬 충돌 가능성:
- 충돌하지 않는 작업을 교환하여 직렬 일정으로 변환할 수 있는 경우 일정은 충돌 직렬화 가능합니다. 두 작업이 서로 다른 트랜잭션에서 발생하고 동일한 데이터 항목에 액세스하며 그 중 하나 이상이 쓰기 작업인 경우 충돌하는 것으로 간주됩니다.
- 충돌 작전:
  - 한 트랜잭션이 다른 트랜잭션이 쓰는 데이터 항목을 읽을 때 읽기-쓰기 충돌이 발생합니다.
  - 두 트랜잭션이 모두 동일한 데이터 항목에 쓸 때 쓰기-쓰기 충돌이 발생합니다.

충돌 직렬화 가능성의 예:

일정:
- T1: 쓰기(A);
- T2: 쓰기(B);
- T1: 읽기(B);
- T2: 읽기(A);
이 일정은 직렬 일정으로 재배치될 수 있으며 충돌 직렬화가 가능합니다.

직렬 가능성 보기:
- 일정은 최종 결과 측면에서 직렬 일정과 동일한 경우, 즉 동일한 읽기 및 쓰기가 발생하고 트랜잭션이 올바르게 직렬화되는 경우 보기 직렬화 가능합니다. 그러나 직렬성 측면에서 충돌 직렬성처럼 작업을 반드시 교체할 필요는 없습니다.

충돌 등가, 충돌 직렬화 가능

충돌 상당:
- 두 개의 일정을 충돌 등가라고 합니다. 동일한 작업이 포함된 경우 작업 순서가 동일하며 충돌하는 작업의 순서가 유지됩니다. 즉, 두 일정 모두에서 트랜잭션을 인터리브하면 동일한 결과가 생성되어 충돌이 동등하다는 것을 보장합니다.
직렬화 가능한 충돌:
- 충돌 순서를 유지하면서 트랜잭션을 재배열하여 일련의 일정을 형성할 수 있는 경우 일정은 충돌 직렬화 가능입니다. 간단히 말해서, 데이터 일관성을 위반하지 않고 트랜잭션을 직렬화할 수 있는 경우(예: 충돌하는 작업의 순서를 유지하는 경우) 일정은 충돌 직렬화 가능입니다.

충돌 직렬화 가능성 및 충돌 등가 일정의 예

다음 거래와 운영을 고려해 보겠습니다.

트랜잭션 T1: 읽기(A); 쓰기(A); 저지르다
트랜잭션 T2: 읽기(A); 쓰기(A); 저지르다

일정 1:

T1: Read(A);
T2: Read(A);
T1: Write(A);
T2: Write(A);
T1: Commit;
T2: Commit;

일정 2:

T2: Read(A);
T1: Read(A);
T2: Write(A);
T1: Write(A);
T1: Commit;
T2: Commit;

직렬성 충돌 검사:

스케줄 1과 스케줄 2는 충돌하는 작업(A에 대한 읽기/쓰기)의 순서가 유지되므로 충돌 등가입니다. 두 일정 모두 연속 일정으로 변환될 수 있습니다.
- T1: 읽기(A); 쓰기(A); 커밋;
- T2: 읽기(A); 쓰기(A); 커밋;
따라서 두 일정 모두 충돌 직렬화가 가능합니다.

트랜잭션 격리 및 원자성

ACID 속성과 같은 트랜잭션의 기본 속성 외에도 트랜잭션 실패 관리는 데이터베이스의 일관성과 신뢰성을 유지하는 데 중요한 측면입니다. 트랜잭션이 동시에 실행되는 경우 데이터베이스는 트랜잭션 중 오류가 데이터베이스 상태를 손상시키지 않고 데이터베이스의 원자성과 일관성이 유지되도록 보장해야 합니다. 이 섹션에서는 오류 처리가 DBMS의 트랜잭션 격리 및 원자성에 어떤 영향을 미치는지 설명합니다.

원자성과 실패 처리

원자성은 트랜잭션이 분할할 수 없는 단일 작업 단위로 처리되도록 보장하는 트랜잭션의 속성입니다. 이는 트랜잭션이 완전히 완료되었거나 전혀 실행되지 않음을 의미합니다. 트랜잭션의 일부가 실패하면 부분 변경 사항이 데이터베이스에 적용되지 않도록 전체 트랜잭션을 롤백해야 합니다.

트랜잭션이 실패하면 데이터베이스에 미칠 수 있는 모든 영향을 취소해야 데이터베이스가 트랜잭션이 시작되기 전의 상태로 돌아갈 수 있습니다. 트랜잭션의 동시 실행을 허용하는 시스템에서 트랜잭션 T1이 실패하면 T1에 의존하는 모든 트랜잭션(즉, T1의 영향을 받은 데이터를 읽거나 쓴 모든 트랜잭션 T2)도 중단되어 데이터베이스의 원자성을 보존해야 합니다. 트랜잭션이 실패한 다른 트랜잭션에 종속된 경우 부분 변경이나 일관성 없는 데이터가 남아 있어서는 안 됩니다.

트랜잭션 실행 중 불일치를 방지하려면 특히 트랜잭션이 실패할 때 트랜잭션 작업 순서를 결정하는 스케줄을 관리하는 것이 중요합니다. 실패를 적절하게 관리하려면 특정 유형의 일정을 제한해야 합니다.

복구 가능한 일정

복구 가능한 일정은 자신이 의존하는 트랜잭션 T1이 커밋된 후에만 트랜잭션 T2가 커밋하는 일정입니다. 간단히 말해서, 트랜잭션 T2가 트랜잭션 T1이 작성한 데이터를 읽는 경우 T1은 T2보다 먼저 커밋해야 합니다. 이렇게 하면 T2가 커밋되지 않은 트랜잭션을 기반으로 변경 사항을 커밋하지 않으므로 T1을 롤백할 때 T2도 롤백해야 하는 시나리오가 방지됩니다.

이 규칙을 위반하는 스케줄을 복구 불가능한 스케줄이라고 합니다. 예를 들어, T2가 T1이 쓴 데이터를 읽은 후 커밋했는데 T1이 실패하여 롤백되는 경우 T2의 커밋은 T1의 커밋되지 않은 변경 사항에 의존하기 때문에 데이터베이스를 일관된 상태로 복구할 수 없습니다. 이런 상황에서는 T2 실행 취소가 불가능해지며 데이터 불일치가 발생합니다.

복구 불가능한 일정의 예:
복구 불가능한 일정에서는 다음과 같이 가정해 보겠습니다.

트랜잭션 T6은 항목 A에 데이터를 씁니다.
트랜잭션 T7은 T6이 작성한 A의 값을 읽고 즉시 커밋합니다.

T6이 커밋되기 전에 실패하면 T7은 T6의 커밋되지 않은 변경 사항에 종속됩니다. T7이 이미 커밋을 했기 때문에 T7을 롤백할 수 없어 T6의 장애 복구가 불가능한 상황이 발생한다. 이로 인해 복구 불가능한 일정이 발생합니다.

일정을 복구하려면 T7이 T6이 커밋될 때까지 커밋을 연기하여 T7이 T6의 커밋되지 않은 데이터에 의존하지 않도록 해야 합니다.

계단식 없는 일정

일정이 복구 가능하더라도 트랜잭션 실패 복구 중에 문제가 발생할 수 있으며, 특히 계단식 롤백이 발생할 경우 더욱 그렇습니다. 계단적 롤백은 하나의 트랜잭션이 실패하면 다른 종속 트랜잭션의 연쇄 롤백이 발생하는 상황을 의미합니다. 이러한 상황은 트랜잭션이 커밋되지 않은 다른 트랜잭션에 의해 작성된 데이터를 읽을 때 발생합니다.

예를 들어 다음과 같은 시나리오를 생각해 보세요.

트랜잭션 T8은 트랜잭션 T9가 읽은 데이터 항목 A에 값을 씁니다.
트랜잭션 T9는 A에 값을 쓴 후 트랜잭션 T10에서 읽습니다.
T8이 실패하면 T8에 의존하는 T9도 롤백해야 합니다. T9에 종속된 T10도 롤백해야 합니다. 이로 인해 계단식 롤백 효과가 발생하여 여러 트랜잭션 작업이 불필요하게 취소됩니다.

계단식 롤백은 단일 트랜잭션만 실패하더라도 상당한 양의 작업이 실행 취소되기 때문에 바람직하지 않습니다. 계단식 롤백을 방지하기 위해 계단식 없는 일정을 사용할 수 있습니다. 계단식 없는 일정은 아직 커밋되지 않은 트랜잭션에 의해 작성된 데이터를 트랜잭션이 읽지 않는 일정입니다.

공식적으로 계단식 없는 일정은 T1과 T2의 두 트랜잭션에 대해 T2가 T1이 작성한 데이터 항목을 읽는 경우 T2가 데이터 항목을 읽기 전에 T1이 커밋되어야 하는 일정입니다. 이렇게 하면 어떤 트랜잭션도 커밋되지 않은 데이터에 의존할 수 없으며 계단식 롤백이 발생하지 않습니다.

무단계 스케줄은 모두 복구 가능한 스케줄이기도 합니다. 즉, 계단식 없는 일정은 계단식 롤백을 방지할 뿐만 아니라 트랜잭션 실패 시 데이터베이스가 올바르게 복구될 수 있도록 보장합니다.

계단식 없는 일정의 예:
다음을 고려하십시오:

트랜잭션 T8은 A를 쓰고, T9는 A를 읽습니다.
계단식 없는 스케줄에서 T9는 T8이 커밋된 후에만 A를 읽을 수 있습니다.

이는 T8이 성공적으로 완료되지 않는 한 T9가 T8에서 데이터를 읽지 않도록 보장하여 T8이 실패할 경우 T9의 롤백이 필요하지 않도록 보장합니다.

거래 격리 수준

트랜잭션 격리는 동시 트랜잭션이 데이터베이스의 일관성을 위반하는 방식으로 서로 간섭하지 않도록 보장합니다. 트랜잭션의 격리 수준은 해당 트랜잭션이 다른 트랜잭션과 격리되는 정도를 정의합니다.

낮은 격리부터 높은 격리까지 다양한 격리 수준이 있습니다.

커밋되지 않은 읽기:
- 이 격리 수준을 사용하면 트랜잭션이 커밋되지 않은 다른 트랜잭션에서 쓴 데이터를 읽을 수 있습니다. 이 수준에서는 트랜잭션이 나중에 롤백될 수 있는 데이터를 읽어 일관되지 않은 결과를 초래하는 더티 읽기와 같은 문제가 발생할 수 있습니다.
읽기 완료:
- 이 수준의 트랜잭션은 다른 트랜잭션에서 커밋된 데이터만 읽을 수 있습니다. 이렇게 하면 더티 읽기를 방지할 수 있지만 여전히 반복 불가능한 읽기가 발생할 수 있습니다. 이 경우 트랜잭션은 동일한 데이터를 두 번 읽고 그 동안 다른 트랜잭션이 데이터를 수정했기 때문에 다른 결과를 얻습니다.
반복 읽기:
- 이 수준은 더티 읽기와 반복 불가능한 읽기를 모두 방지합니다. 그러나 다른 트랜잭션이 레코드를 삽입하거나 삭제하는 경우 트랜잭션에서 다른 행 집합이 발생할 수 있는 팬텀 읽기는 여전히 허용됩니다.
직렬화 가능:
- 가장 높은 격리 수준입니다. 이는 동시 트랜잭션의 결과가 트랜잭션이 차례로 순차적으로 실행된 것과 동일함을 보장합니다. 이는 더티 읽기, 반복 불가능한 읽기 및 팬텀 읽기를 방지하지만 엄격한 특성으로 인해 성능에 영향을 미칠 수 있습니다.

데이터베이스 또는 트랜잭션에 대해 선택한 격리 수준은 데이터 일관성과 성능 간의 균형에 영향을 미치며, 일반적으로 격리 수준이 높을수록 동시성에 대한 제한이 커져 성능이 저하됩니다.

DBMS의 동시성 제어

동시성 제어는 여러 트랜잭션이 동시에 실행되도록 허용하면서 올바른 트랜잭션 실행을 보장하는 데이터베이스 관리 시스템(DBMS)의 중요한 측면입니다. 동시성 제어의 목표는 트랜잭션 인터리빙 및 오류 시나리오에 직면하여 데이터베이스 일관성과 무결성을 유지하는 것입니다. 이 섹션에서는 다양한 잠금 모드, 2단계 잠금 프로토콜, 교착 상태 처리 메커니즘 및 타임스탬프 기반 프로토콜을 포함한 잠금 기반 프로토콜을 다룹니다. .

잠금 기반 프로토콜

잠금은 동시에 실행되는 트랜잭션 간의 충돌을 방지하기 위해 DBMS에서 사용되는 기본 메커니즘입니다. 액세스를 제어하기 위해 데이터 항목에 잠금이 적용되어 여러 트랜잭션이 데이터베이스의 무결성을 위반하지 않도록 합니다. 잠금 기반 동시성 제어에서 트랜잭션은 데이터 항목에 대한 작업을 수행하기 전에 해당 항목에 대한 잠금을 획득하고 작업이 완료되면 잠금을 해제합니다.

잠금 유형

데이터 항목을 잠글 수 있는 다양한 모드가 있습니다. 이 섹션에서는 두 가지 기본 모드만 살펴보겠습니다.

공유 잠금(S):
- 트랜잭션은 항목을 읽기만 하면 되는 경우 데이터 항목에 대한 공유 잠금을 유지합니다.
- 여러 트랜잭션이 동일한 데이터 항목에 대해 공유 잠금을 동시에 보유할 수 있습니다. 이를 통해 다양한 트랜잭션에서 데이터 항목을 동시에 읽을 수 있습니다.
- 공유 잠금은 트랜잭션이 데이터 항목을 수정하는 것을 허용하지 않습니다.

예:

트랜잭션 T1은 항목 A에 대해 공유 잠금을 유지하고 A를 읽습니다.
트랜잭션 T2는 항목 A에 대해 공유 잠금을 유지하고 A를 읽습니다.
둘 다 데이터를 읽을 수 있지만 A에 쓸 수는 없습니다.

독점 잠금(X):
- 트랜잭션은 항목을 읽고 써야 할 때 데이터 항목에 대한 배타적 잠금을 유지합니다.
- 언제든지 하나의 트랜잭션만 특정 데이터 항목에 대한 배타적 잠금을 보유할 수 있습니다. 트랜잭션에 배타적 잠금이 있는 경우 다른 트랜잭션은 동일한 데이터 항목에 대해 공유 또는 배타적 잠금을 획득할 수 없습니다.

예:

트랜잭션 T1은 항목 A에 대해 독점 잠금을 유지하고 해당 항목에 씁니다.
T1이 A에 대한 독점 잠금을 보유하고 있는 동안 다른 트랜잭션은 A를 읽거나 쓸 수 없습니다.

잠금 부여

잠금은 시스템이 따르는 프로토콜을 기반으로 부여되며, 다양한 잠금 기반 프로토콜이 트랜잭션 실행 중에 잠금이 요청되고 부여되는 방식을 제어할 수 있습니다. 이러한 프로토콜은 업데이트 손실, 일시적인 불일치, 다른 트랜잭션에서 액세스되는 커밋되지 않은 데이터 등의 충돌을 방지하는 데 도움이 됩니다.

2단계 잠금 프로토콜(2PL)

2단계 잠금 프로토콜은 직렬성을 보장하기 위해 널리 사용되는 프로토콜입니다. 이 프로토콜은 트랜잭션의 결과가 한 번에 실행되는 것과 동일하도록 트랜잭션 실행을 보장하는 속성입니다. 또 다른 (연속적으로). 2단계 잠금은 트랜잭션 실행 중에 두 단계를 적용하여 직렬성을 보장합니다.

성장 단계:
- 이 단계에서 트랜잭션은 잠금을 획득할 수 있지만 잠금을 해제할 수는 없습니다.
- 트랜잭션은 잠금을 원하는 만큼 요청할 수 있지만 일단 잠금을 해제하면 새로운 잠금을 획득할 수 없습니다. 이 단계는 첫 번째 잠금 해제 작업이 수행되면 종료됩니다.
축소 단계:
- 이 단계에서 트랜잭션은 잠금을 해제할 수 있지만 새로운 잠금을 획득할 수는 없습니다.
- 트랜잭션이 잠금 해제를 시작하면 추가 데이터 항목을 잠글 수 없습니다. 이 단계는 트랜잭션이 커밋되거나 중단되면 종료됩니다.

2단계 잠금 프로토콜은 잠금 그래프의 주기를 방지하여 실행 순서가 직렬화 가능한 엄격한 순서를 따르도록 보장하므로 직렬화를 보장합니다.

예:

트랜잭션 T1과 T2는 데이터 항목 A와 B를 업데이트해야 합니다. 2PL을 사용하면 두 트랜잭션 모두 성장 단계에서 필요한 잠금을 획득하고 작업이 완료된 후에(축소 단계) 잠금을 해제합니다.

교착상태 처리

교착상태는 두 개 이상의 트랜잭션이 서로 잠금 해제를 기다리고 있어 어느 하나도 진행할 수 없는 상황이 발생하는 경우에 발생합니다. 이로 인해 하나 이상의 트랜잭션이 롤백되지 않으면 해결할 수 없는 트랜잭션 대기 주기가 생성됩니다.

교착상태 예방

교착상태 방지 기술은 트랜잭션 동작에 제한을 가하여 교착상태 발생을 방지하도록 설계되었습니다. 교착 상태를 방지하기 위한 일반적인 전략 중 하나는 타임스탬프를 사용하여 트랜잭션 우선 순위를 지정하는 것입니다.

타임스탬프 기반 교착 상태 방지 체계

타임스탬프를 사용하는 두 가지 주요 교착 상태 방지 체계가 있습니다.

기다림 계획:
- 이것은 비선점형 교착상태 방지 기법입니다.
- 트랜잭션 Ti가 Tj가 보유한 데이터 항목을 요청하는 경우 Ti는 해당 타임스탬프가 Tj의 타임스탬프보다 작은 경우에만(즉, Ti가 Tj보다 오래된 경우) 기다릴 수 있습니다.
- Ti의 타임스탬프가 Tj의 타임스탬프보다 크면 Ti가 롤백됩니다(즉, Ti가 "죽음").

예:

트랜잭션 T14, T15, T16에 각각 타임스탬프 5, 10, 15가 있는 경우:
- T14가 T15가 보유한 데이터 항목을 요청하면 T14는 더 오래되었기 때문에 T14는 기다릴 것입니다.
- T16이 T15가 보유한 데이터 항목을 요청하면 T16이 T15보다 젊기 때문에 T16이 롤백됩니다.

상처 대기 계획:
- 이것은 선제 교착상태 방지 기법입니다.
- 트랜잭션 Ti가 Tj가 보유한 데이터 항목을 요청하는 경우 Ti는 해당 타임스탬프가 Tj의 타임스탬프보다 큰 경우(즉, Ti가 Tj보다 어린 경우)에만 기다릴 수 있습니다.
- Ti의 타임스탬프가 Tj의 타임스탬프보다 작은 경우 Ti는 Tj를 선점하고 Tj는 롤백됩니다(즉, Tj는 Ti에 의해 "상처"를 입습니다).

예:

트랜잭션 T14, T15, T16에 각각 타임스탬프 5, 10, 15가 있는 경우:
- T14가 T15가 보유한 데이터 항목을 요청하면 T14가 T15를 선점하여 T15가 롤백됩니다.
- T16이 T15가 보유한 데이터 항목을 요청하면 T16은 T15보다 어리기 때문에 기다리게 됩니다.

타임스탬프 기반 프로토콜

잠금 기반 프로토콜 외에도 타임스탬프 기반 프로토콜도 데이터베이스의 동시성을 관리합니다. 이러한 프로토콜은 타임스탬프를 사용하여 트랜잭션을 정렬하고 충돌을 해결함으로써 시스템이 트랜잭션이 순차적으로 실행되는 것처럼 작동하도록 보장합니다.

타임스탬프와 그 역할

타임스탬프는 트랜잭션이 생성될 때 트랜잭션에 할당되는 숫자 값입니다. 거래의 타임스탬프에 따라 우선순위가 결정됩니다. 타임스탬프 값이 낮을수록 오래된 거래를 나타내고, 값이 높을수록 새로운 거래를 나타냅니다.

W-타임스탬프(Q):
- 이는 데이터 항목 Q에 대한 쓰기 작업을 성공적으로 실행한 트랜잭션 중 가장 큰 타임스탬프를 나타냅니다.
- 데이터 항목을 수정한 마지막 거래를 식별하는 데 도움이 됩니다.
R-타임스탬프(Q):
- 이는 데이터 항목 Q에 대해 읽기 작업을 성공적으로 실행한 트랜잭션의 가장 큰 타임스탬프를 나타냅니다.
- 데이터 항목을 읽은 마지막 트랜잭션을 식별하는 데 도움이 됩니다.

타임스탬프 순서 지정 프로토콜

타임스탬프 순서 지정 프로토콜은 타임스탬프를 기준으로 트랜잭션에 전체 주문을 적용하여 직렬성을 보장합니다. 프로토콜에서는 다음을 요구합니다.

트랜잭션 Ti가 데이터 항목 Q를 쓰고 다른 트랜잭션 Tj가 Q를 읽거나 쓰는 경우 Ti의 타임스탬프는 Tj보다 작아야 합니다.
마찬가지로 Ti가 데이터 항목 Q를 읽고 Tj가 Q를 쓴다면 Ti의 타임스탬프는 Tj보다 작아야 합니다.

이 프로토콜은 잠금이 아닌 트랜잭션의 타임스탬프를 기반으로 충돌을 해결합니다.

예:

타임스탬프 10이 있는 트랜잭션 T1은 데이터 항목 A를 씁니다.
타임스탬프 12가 있는 트랜잭션 T2는 데이터 항목 A를 읽습니다.
타임스탬프 순서 지정 프로토콜은 T1의 쓰기 작업이 T2의 읽기 작업보다 먼저 발생하도록 보장하여 올바른 트랜잭션 순서를 유지합니다.

위 내용은 트랜잭션 및 동시성 제어: DBMS의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

if for while timestamp require die Error double restrict using Property Event delete number this database Access Other

성명：

이전 기사：SQL의 함수, 프로시저, 커서 및 트리거다음 기사：SQL의 함수, 프로시저, 커서 및 트리거