스케줄

- 동시 수행한 스케줄의 결과가 트랜잭션을 하나씩 순차적으로 수행하는 스케줄의 실행 결과와 동일하도록 함으로써 데이터베이스의 일관성을 보장할 수 있다.

** 동시 수행 스케줄이 순차 스케줄과 동

등해야 한다   -> 직렬 스케줄

- 순차 스케줄은 반드시 직렬성을 갖는다.

 

# Serializability 직렬성    

- 충돌 직렬성

- 뷰 직렬성

- 동시에 수행해도 일관성을 유지할 수 있다는 것을 보장

 

# 충돌 발생하는 상황

- 만약 트랜잭션이 서로 다른 데이터 항목을 액세스 하는 경우에 다른 명령어들에 순서 주지 않고 두 명령어의 순서를 바꿀 수 있다.

- 하지만 같은 데이터 항목을 액세스한다면 두 명령어의 순서는 중요한 문제가 될 수 있다.

- 트랜잭션 순서에 따라 내용이 변하므로 충돌이 발생한다.

 

- 충돌 발생 (충돌 직렬성)

스케줄 3,6은 같다

# 충돌 동등

- 스케줄 S가 충돌이 일어나지 않는 명령어들의 순서를 바꿔서 스케줄 S'로 변경된다면 S와 S'가 충돌 동등하다고 말할 수 있다.

 

# 충돌 직렬성

- 스케줄 S가 한 순차 스케줄에 충돌 동등하면 그 스케줄 S가 충돌 직렬적이라고 말한다.

 

# 뷰 직렬성

- 뷰 동등적 조건 :

    1. S가 스케줄 전에 만들어진 데이터를 읽어온다면, S'도 스케줄 전에 만들어진 데이터를 읽어와야 한다.

    2. S, S'는 둘다 같은 트랜잭션이 만들어진 값을 읽어와야 한다.

    3. S와 S'의 최종적인 값은 항상 같이 write

    ∴ S, S'는 직렬적이다 (serializable)

 

- 뷰 직렬적

- 모든 충돌 직렬적인 스케줄은 뷰 직렬적이다.

- 계산 복잡도가 높기때문에 사용 x

 

# 우선순위 그래프

- 충돌 직렬성을 검사하는 간단한 방법

- 사이클이 있을 경우 충돌 직렬적인 스케줄이 아니다

- 사이클이 없을 경우 충돌 직렬적인 스케줄이다.

 

# 순환 없는 그래프 = topological sorting 위상정렬

- 일관성 있는 일렬의 데이터를 만든다

 

# 복구 가능한 스케줄

* 모든 스케줄은 복구 가능한 스케줄이어야 한다.

 

ex) 복구 불가능한 스케줄의 예시

만약 T8 read(B)하고 abort로 취소하려고 했는데, A값은 이미 변경되어버렸고 commit까지 해서 작업을 마쳤기 때문에 복구가 불가능하다

쉬운예시) A계좌의 내용이 바뀌었다. T9가 A계좌를 읽었고 변경내용을 commit했다. T8로 돌아가서 취소하려고 하면 늦었다.

문제 : T8의 내용이 올바른지 확인 못하고 너무빨리 끝내버렸다.

복구 불가능한 스케줄 (부분 스케줄)

 

# 연쇄적 롤백 (복구 가능한 스케줄) Cascading RollBacks

∵ commit되지 않은 결과들을 read,write했기 때문에 연쇄적 롤백이 발생한다.

- 바람직하지 않은 현상. 연쇄적 롤백으로 인해 많은 양의 작업이 취소되기 때문

 

# 비연쇄적 롤백 Cacadeless RollBacks

- 스케줄마다 작업하고 commit하므로 연쇄적 롤백 발생 x

- commit된 값만을 가지고 진행된다

- 시간지연 발생

# 트랜잭션 고립성 수준

- 직렬적 default

- 반복 읽기 : 하나의 트랜잭션 안에서 같은 레코드를 읽는 작업이 반복

- 읽기 완료 : 완료된 것(커밋된 레코드)만 읽지만 반복 읽기는 요구되지 않는다

- 읽기 미완료 : 미완료된 것도 읽기

**  dirty write(커밋되지 않은 데이터 변경하는 행위)는 허용하지 않음

 

- 하나의 함수안에 한 개 이상의 트랜잭션이 존재 가능

- 트랜잭션 구분 기준은 Commit / Rollback (트랜잭션 끝)

- auto commit : sql 한문장 단위로 commit진행 (default로 설정됨)

- ** 트랜잭션 시작할때 setAutoCommit을 false상태로 바꿔줘야함 (그래야 문장단위로 전송 기능이 멈춤)