DBMS 동시성 제어: 타임스탬프 및 잠금 기반 프로토콜

모든 사용자가 데이터를 읽기만 한다면 동시 액세스는 꽤 쉽습니다. 서로 간섭할 방법이 없습니다. 하지만 실제 데이터베이스의 경우 READ와 WRITE 작업이 혼합되어 있으므로 동시성이 문제가 됩니다.

DBMS 동시성 제어는 대부분 다중 사용자 시스템에서 발생하는 이러한 충돌을 해결하는 데 사용됩니다. 따라서 동시성 제어는 동일한 데이터에 대한 액세스가 필요한 두 개 이상의 데이터베이스 트랜잭션이 동시에 실행되는 데이터베이스 관리 시스템의 적절한 기능을 위한 가장 중요한 요소입니다.

동시성의 잠재적인 문제

다음은 DBMS 동시성 제어 방법을 사용하는 동안 직면하게 될 몇 가지 문제입니다.

• 손실된 업데이트 여러 트랜잭션이 동일한 행을 선택하고 선택한 값을 기반으로 행을 업데이트할 때 발생
• 커밋되지 않은 종속성 문제는 두 번째 트랜잭션이 다른 트랜잭션에 의해 업데이트되는 행을 선택할 때 발생합니다(더러운 읽기)
• 반복 불가능한 읽기 두 번째 트랜잭션이 동일한 행에 여러 번 액세스하려고 시도하고 매번 다른 데이터를 읽을 때 발생합니다.
• 잘못된 요약 문제 하나의 트랜잭션이 반복되는 데이터 항목의 모든 인스턴스 값에 대한 요약을 취하고 두 번째 트랜잭션이 해당 특정 데이터 항목의 몇 가지 인스턴스를 업데이트할 때 발생합니다. 이러한 상황에서는 결과 요약에 올바른 결과가 반영되지 않습니다.

동시성 방법을 사용하는 이유는 무엇입니까?

동시성 제어 방법을 사용하는 이유는 DBMS입니다.

• 충돌하는 거래 간 상호 배제를 통한 Isolation 적용
• 읽기-쓰기 및 쓰기-쓰기 충돌 문제를 해결하려면
• 실행 방해 요소를 지속적으로 보존하여 데이터베이스 일관성을 유지합니다.
• 시스템은 동시 트랜잭션 간의 상호 작용을 제어해야 합니다. 이 제어는 동시 제어 방식을 사용하여 달성됩니다.
• 동시성 제어는 직렬성을 보장하는 데 도움이 됩니다.

예시

두 사람이 동시에 전자 매표소에 가서 같은 영화, 같은 상영 시간의 영화 티켓을 구매한다고 가정해 보겠습니다.

그러나 해당 극장에는 영화 상영을 위한 좌석이 단 한 개만 남아 있습니다. DBMS의 동시성 제어가 없으면 두 관객 모두 결국 티켓을 구매하게 될 가능성이 있습니다. 그러나 동시성 제어 방법은 이를 허용하지 않습니다. 두 영화관객 모두 영화 좌석 데이터베이스에 기록된 정보에 계속 액세스할 수 있습니다. 하지만 동시성 제어는 거래 과정을 먼저 완료한 구매자에게만 티켓을 제공합니다.

동시성 제어 프로토콜

다양한 동시성 제어 프로토콜은 허용하는 동시성 양과 부과하는 오버헤드 양 사이에서 다양한 이점을 제공합니다. 다음은 DBMS의 동시성 제어 기술입니다.

• 잠금 기반 프로토콜
• XNUMX단계 잠금 프로토콜
• 타임스탬프 기반 프로토콜
• 검증 기반 프로토콜

잠금은 데이터 항목과 연관된 데이터 변수입니다. 이 잠금은 데이터 항목에서 수행할 수 있는 작업을 나타냅니다. DBMS의 잠금은 동시 트랜잭션을 통해 데이터베이스 항목에 대한 액세스를 동기화하는 데 도움이 됩니다.

모든 잠금 요청은 동시성 제어 관리자에게 이루어집니다. 잠금 요청이 승인된 후에만 트랜잭션이 진행됩니다.

바이너리 잠금: 데이터 항목에 대한 바이너리 잠금은 잠긴 상태이거나 잠금 해제된 상태일 수 있습니다.

공유/독점: 이러한 유형의 잠금 메커니즘은 DBMS의 잠금을 용도에 따라 분리합니다. 쓰기 작업을 수행하기 위해 데이터 항목에 잠금이 획득되면 이를 배타적 잠금이라고 합니다.

1. 공유 잠금(S):

공유 잠금은 읽기 전용 잠금이라고도 합니다. 공유 잠금을 사용하면 트랜잭션 간에 데이터 항목을 공유할 수 있습니다. 이는 데이터 항목의 데이터를 업데이트할 수 있는 권한이 없기 때문입니다.

예를 들어, 두 트랜잭션이 개인의 계좌 잔액을 읽는 경우를 생각해 보십시오. 그만큼 데이터베이스 공유 잠금을 설정하여 읽을 수 있게 합니다. 그러나 다른 트랜잭션이 해당 계정의 잔액을 업데이트하려는 경우 공유 잠금은 읽기 프로세스가 끝날 때까지 이를 방지합니다.

2. 배타적 잠금(X):

Exclusive Lock을 사용하면 데이터 항목을 읽고 쓸 수 있습니다. 이는 배타적이며 동일한 데이터 항목에 동시에 보관할 수 없습니다. X-lock은 lock-x 명령어를 사용하여 요청됩니다. 트랜잭션은 '쓰기' 작업을 마친 후 데이터 항목을 잠금 해제할 수 있습니다.

예를 들어, 거래가 사람의 계좌 잔액을 업데이트해야 할 때. X 잠금을 걸어 이 거래를 허용할 수 있습니다. 따라서 두 번째 거래가 읽거나 쓰려고 할 때 배타적 잠금이 이 작업을 방지합니다.

3. 단순한 잠금 프로토콜

이러한 유형의 잠금 기반 프로토콜은 트랜잭션이 작업을 시작하기 전에 모든 객체에 대한 잠금을 획득할 수 있도록 합니다. 트랜잭션은 '쓰기' 작업을 마친 후 데이터 항목을 잠금 해제할 수 있습니다.

4. 사전 청구 잠금

사전 청구 잠금 프로토콜은 작업을 평가하고 실행 프로세스를 시작하는 데 필요한 필수 데이터 항목 목록을 만드는 데 도움이 됩니다. 모든 잠금이 부여된 상황에서 트랜잭션이 실행됩니다. 그 후 모든 작업이 끝나면 모든 잠금이 해제됩니다.

굶주림

기아 상태는 트랜잭션이 잠금을 획득하기 위해 무한정 기다려야 하는 상황입니다.

기아의 원인은 다음과 같습니다.

• 잠긴 항목에 대한 대기 방식이 제대로 관리되지 않는 경우
• 리소스 누출의 경우
• 동일한 거래가 반복적으로 피해자로 선정됨

이중 자물쇠

교착 상태란 두 개 이상의 프로세스가 서로 자원을 해제하기를 기다리거나, 두 개 이상의 프로세스가 순환 체인 형태로 자원을 기다리는 특정 상황을 말합니다.

이 잠금 프로토콜은 트랜잭션의 실행 단계를 세 가지 부분으로 나눕니다.

• 첫 번째 단계에서는 트랜잭션이 실행되기 시작하면 필요한 잠금에 대한 권한이 필요합니다.
• 두 번째 부분은 트랜잭션이 모든 잠금을 획득하는 부분입니다. 트랜잭션이 첫 번째 잠금을 해제하면 세 번째 단계가 시작됩니다.
• 이 세 번째 단계에서는 트랜잭션이 새로운 잠금을 요구할 수 없습니다. 대신 획득한 잠금만 해제합니다.

XNUMX단계 잠금 프로토콜을 사용하면 각 트랜잭션이 두 단계로 잠금 또는 잠금 해제 요청을 할 수 있습니다.

• 성장 단계: 이 단계에서 트랜잭션은 잠금을 얻을 수 있지만 잠금을 해제할 수는 없습니다.
• 수축 단계: 이 단계에서 트랜잭션은 잠금을 해제할 수 있지만 새로운 잠금을 얻을 수는 없습니다.

2PL 프로토콜이 직렬성을 제공하는 것은 사실입니다. 그러나 교착 상태가 발생하지 않는다는 것을 보장하지는 않습니다.

위에 주어진 다이어그램에서 로컬 및 글로벌 교착 상태 감지기가 교착 상태를 검색하고 트랜잭션을 초기 상태로 재개하여 교착 상태를 해결하는 것을 볼 수 있습니다.

엄격한 XNUMX단계 잠금 방식

Strict-Two Phase Locking 시스템은 2PL과 거의 유사합니다. 유일한 차이점은 Strict-2PL은 사용한 후에 잠금을 해제하지 않는다는 것입니다. 커밋 시점까지 모든 잠금을 유지하고 프로세스가 끝나면 한 번에 모든 잠금을 해제합니다.

중앙 집중식 2PL

Centralized 2 PL에서는 단일 사이트가 잠금 관리 프로세스를 담당합니다. 전체 DBMS에 대해 하나의 잠금 관리자만 있습니다.

기본 사본 2PL

기본 복사본 2PL 메커니즘, 많은 잠금 관리자가 다른 사이트에 배포됩니다. 그 후에는 특정 잠금 관리자가 일련의 데이터 항목에 대한 잠금을 관리하는 역할을 담당합니다. 기본 복사본이 업데이트되면 변경 사항이 슬레이브에 전파됩니다.

분산형 2PL

이러한 종류의 2단계 잠금 메커니즘에서는 잠금 관리자가 모든 사이트에 배포됩니다. 이들은 해당 사이트의 데이터 잠금을 관리할 책임이 있습니다. 데이터가 복제되지 않으면 2차 복사본 2PL과 동일합니다. Distributed XNUMXPL의 통신 비용은 Primary Copy XNUMXPL보다 상당히 높습니다.

이 방법에서는 항상 오래된 트랜잭션에 우선순위가 부여됩니다. 시스템 시간을 사용하여 트랜잭션의 타임스탬프를 결정합니다. 이는 가장 일반적으로 사용되는 동시성 프로토콜입니다.

잠금 기반 프로토콜은 충돌하는 트랜잭션 간의 순서를 관리하는 데 도움이 됩니다. 타임스탬프 기반 프로토콜은 작업이 생성되는 즉시 충돌을 관리합니다.

예:

Suppose there are there transactions T1, T2, and T3. 
T1 has entered the system at time 0010 
T2 has entered the system at 0020
T3 has entered the system at 0030
Priority will be given to transaction T1, then transaction T2 and lastly Transaction T3.

장점:

• 일정은 2PL 프로토콜처럼 직렬화 가능합니다.
• 거래를 기다릴 필요가 없으므로 교착 상태의 가능성이 사라집니다!

단점 :

동일한 트랜잭션이 다시 시작되고 지속적으로 중단되면 기아 상태가 발생할 수 있습니다.

검증 기반 프로토콜은 다음의 세 단계로 수행됩니다.

1. 읽기 단계
2. 검증 단계
3. 쓰기 단계

읽기 단계

읽기 단계에서는 트랜잭션이 데이터베이스의 데이터 값을 읽을 수 있지만 쓰기 작업이나 업데이트는 실제 데이터베이스가 아닌 로컬 데이터 사본에만 적용됩니다.

검증 단계

유효성 검사 단계에서는 트랜잭션 업데이트를 데이터베이스에 적용하는 동안 직렬화 가능성을 위반하지 않는지 확인하기 위해 데이터를 검사합니다.

쓰기 단계

쓰기 단계에서는 유효성 검사가 성공하면 업데이트가 데이터베이스에 적용됩니다. 업데이트가 적용되지 않고 트랜잭션이 롤백됩니다.

좋은 동시성 프로토콜의 특징

이상적인 동시성 제어 DBMS 메커니즘은 다음과 같은 목표를 갖습니다.

• 사이트 및 통신 오류에 대한 복원력이 있어야 합니다.
• 최대 동시성을 달성하기 위해 트랜잭션의 병렬 실행을 허용합니다.
• 오버헤드를 최소화하려면 저장 메커니즘과 계산 방법이 적당해야 합니다.
• 거래의 원자적 동작 구조에 대한 몇 가지 제약 조건을 적용해야 합니다.

요약

• 동시성 제어는 다음의 절차입니다. DBMS 서로 충돌하지 않고 동시적인 작업을 관리하기 위해.
• 업데이트 손실, 더티 읽기, 반복 불가능한 읽기 및 잘못된 요약 문제는 동시성 제어 부족으로 인해 직면하는 문제입니다.
• 잠금 기반, XNUMX단계, 타임스탬프 기반, 유효성 검사 기반은 동시성 처리 프로토콜 유형입니다.
• 잠금은 공유(S) 또는 배타적(X)일 수 있습니다.
• 2PL 프로토콜이라고도 알려진 2단계 잠금 프로토콜은 트랜잭션이 잠금 중 하나를 해제한 후 잠금을 획득해야 합니다. 성장과 축소의 XNUMX단계가 있습니다.
• 타임스탬프 기반 알고리즘은 타임스탬프를 사용하여 동시 트랜잭션 실행을 직렬화합니다. 프로토콜은 시스템 시간 또는 논리적 카운트 타임스탬프.