lock 기반 규약

lock규약을 지키도록 제한하여 원하는 유형의 트랜잭션 스케줄만을 생성한다.

lock모드:x,s

lock기반 규약

• 트랜잭션은 연산을 수행하기 전에 lock을 보유하고 있어야 한다.
• lock을 부여받지 못한 트랜잭션은 대기한다.
• 읽기 lock은 동시에 다수의 트랜잭션에게 부여가능하나,쓰기 lock은 동시에 한 개의 트랜잭션에만 부여한다.

2단계 locking규약(2PL)

증가-감소 단계

• 트랜잭션이 일단 록을 풀기 시작하면(감소) 새로운 록을 잡을 수 없다.

2단계 룰의 변형

• strict: 트랜잭션 종료까지 쓰기 록을 보유한다.
• rigorous: 쓰기 록,읽기 록 모두 트랜잭션 종료까지 보유한다.

록변환

강한록으로의 변환은 증가단계, 약한 록으로의 변환은 감소단계에서만 가능.

2pl정확성의 증명

자동 lock 획득

사용자가 직접적으로 록을 요구/해제하지 않는다.
dbms에서 통제한다.

lock의 구현

록을 담당하는 프로세스 독립적으로 구성가능.
록매니저가 록테이블을 관리하며 록 처리 수행.

starvation(기아)

특정 트랜잭션이 계속 록을 획득하지 못해 오래 기다리는 현상.

그래프 기반 규약

• lcok을 걸 데이터에 대한 조건이 필요함
  -> 데이터에 대한 부분 순서가 존재해야함.
  ex) 색인을 구성하는 데이터

장점

교착상태(deadlock)가 발생하지 않는다.
데이터간의 순서를 정한 후 한쪽 방향으로만 흐르기에 서로 기다리는 상태가 발생하지 않는다.

단점

회복 불가능한 스케줄/연속 철회 스케줄을 생성하기도 함.
때문에 commit연산과의 관계를 고려해야 한다.

트리 기반 규약

록을 해제하고도 또 다시 록을 요구할 수 있다. 하지만 록을 걸었다 해제한 데이터 항목에 대해서는 안된다.

다중단위크기locking(MGL)

locking의 대상이 되는 데이터 항목에 관한 설명이다.
locking이 적용되는 데이터 크기는 다양할 수 잇다.(MGL)
데이터를 크기에 따라 계층적으로 표현 가능하며, 상위노드에 대한 명시적 lock은 하위노드에 대해 묵시적으로 lock을 잡는 효과가 있다.

의도록모드(IS,IX,SIX)

• 하위 노드에 대한 미래의 록 모드를 현재 노드에 표시한다.
• 터플레벨 locking을 지원해 다른 터플이라면 waiting없이 동시적으로 수행가능하다.

deadlock(교착)

교착상태 처리 방식

타임아웃

일정시간 지나면 록을 기다리지 않게 하는 방식.

교착상태 방지

wait-die

새롭게 록을 요구하는 트랜잭션이 기존 트랜잭션보다
old하면 wait하고(기존 트랜잭션의 철회), young하면 철회한다.

wound wait

교착상태 감지 및 해결

감지

대기그래프

입력/삭제 연산

팬텀 현상

2.5 sql트랜잭션 고립

트랜잭션 in sql

• sql트랜잭션은 dml문장이 나오면 암시적으로 실행되며 commit or rollback으로 끝난다.
• 트랜잭션에 대한 sql언어 명령
  set transaction
  commit
  rollback
  savepoint
  rollback to savepoint

완화된 일치성

• dbms는 성능상의 이유로 not serializable한 스케줄을 허용하기도 한다.-> 완화된 일치성

• 완화된 일치성을 제공하는 형식 중 하나가 2단계 일치성이다.
  s-lock이 아무떄나 해제되고 lock을 아무때나 걸 수 있다.-> 직렬가능이 보장되지 않음.

그중 커서 안정방식: 커서가 위치하는 동안 읽기록을 잡고 있는다.->커서가 위치한 데이터는 타 트랜잭션에 의해 변경되지 않는다.

sql 트랜잭션 고립

사용자의 요구에 따라 트랜재션의 고립완화정도를 정할 수 있다.

• serializable

• repeatable read:읽은 값이 트랜잭션 끝까지 유지된다. 먼저 읽은 사람이 쓰기의 우선권이 있다. 하지만 트랜잭션 동안에 갱신되는 데이터들을 새로 읽어가며 수행할 수 없다.

• read committed: 록은 집고 읽은 후 즉시 록을 풀기에 자신이 데이터 쓰기전 다른 트랜잭션이 먼저 쓸 수도 있다.(티켓팅 이선좌)

• read uncommitted: 읽기 연산에서 록을 잡지 않아 읽기 전/후 데이터가 변할 수 있다.

많은 dbms에서 고립도의 기본값은 read committed이다.

스냅샷 고립

다중버전 기법

다중버전 타임스탬프

트랜잭션에 타임스탬프가 붙고, 젊은 트랜잭션이 아직 읽지 않았을 경우에 데이터에 대한 쓰기가 가능하다. 이미 읽었다면 늙은 트랜젹션 t는 록백된다. 읽기 연산에 대한 대기가 없다.

다중버전 two phase

스냅샷 고립

트랜잭션에 대해 데이터베이스의 스냅샷을 제공, 거기에 읽기/쓰기를 한다.
각 트랜잭션은 자신이 한 쓰기 연산에 대한 변화만 인지 할 수 있다. 트랜잭션은 후에 충돌검사를 하고 먼저 commit한 쪽은 유지되며 나중의 commit트랜잭션은 롤백된다.

스냅샷 고립의 비직렬가능 수행

스냅샷 고립 변형

질문

• 보통 dbms는 테이블 자체가 아니라 터플에 lock을 건다.
• 팬텀현상 방지 위해 보통 색인에 lock

2.15

-1 read commited or read uncommited
이유는 read uncommited는 락을 안 잡기에 t2반영
read commited는 락을 잡고 읽고 락을 풀기에 데이터를 읽고 나서 풀기에 그 사이에 t2가 값을 고칠 수있다.

-2 같은 value이려면
serializable 또는 repeatable read(새로운 터플이 삽입/삭제 되는 경우가 아니기에 팬텀현상은 안 일어남.)

savepoint

2pl을 비롯한 여러 규약에서는 savepoint를 막 생성할 수 없다.
록을 거는데 제한이 있는 한 savepoint를 생성할 수 없는 경우도 있다.

2.12

1. t1 no-> 락이 unlock뒤에 와서
2. t2 no -> b를 락하지 않고 c를 락할 수 없어서

2.13

no(t2가 younger해서 자신이 die하기에)
yes(t2가 wound해서 younger한 t3가 rollback되므로)
no(restart하는 트랜잭션은 항상 원래 timestamp를 가지고 실행행 한다-livelock방지)