S)DB_03_트랜잭션2

Concurrency control 동시성 제어

복수의 처리 단위(트랜잭션)가 db 내용을 동시에 갱신해도 데이터 처음과 끝이 일관성 잃지 않도록 제어 

---

 

Serializability 직렬화 성질

많은 사용자 동시에 한 데이터 접근할 때 마치 혼자 접근하는 것과 동일한 결과 얻는

{병렬 동시 처리 + 순차 수행} 효과

 

 

 

Schedule  > (serial, schedule, non-serial schedule)

多 트랜잭션 동시 실행 시, 트랜잭션 속한 작업들의 실행 순서 의미함

내부 operation 겹쳐 실행되면 어떻게 실행했느냐 따라 실행결과 다르게 나타남 

(interleave 실행기법 통해; 서로 다른 memor bank에 번갈아 가용성 높이는 메모리 기법)

 

 

 

Serial schedule

transaction들이 겹치지 않고 한 번에 하나씩 실행되는 schedule

장점: 순서 보장, 정확성

 

단점: 한 번에 하나의 트랜잭션만 실행되기 때문에 좋은 성능 낼 수 없고

(다른 트랜잭션 끝날 때까지 대기)

 

현실적으로 사용할 수 없는 방식

 

Nonserial schedule

트랜잭션들이 겹쳐서 실행, 동시성 높아 같은 시간 동안 더많은 트랜잭션 처리 가능

장점 : 동시성 증가 (병렬처리; 다른 트랜잭션 소요 작업 동안 다른 작업 수행 가능)

 

트랜잭션들이 어떤 형태로 겹쳐서 실행되는지에 따라 

이상한 결과 나올 수 있음

(갱신손실, 모순성, 연쇄복귀 등 문제 발생 가능)

 

 

BUT

---

 

 

 

 

성능 때문에 여러 트랜잭션 겹처서 실행 원하지만(nonserial schedule)

결과는 엉망진창.

 

 

nonserial schedule로 실행해도 이상 결과 나오지 않는 방법은 없을까?

 

 

SO

---

 

 

성능 개선 nonserial + 동일결과보장 serial

=> conflict serializable

 

 

3조건 만족하면 conflict ! 

-  operation가 서로 다른 트랜잭션 속함
-  operation이 서로 같은 데이터 작업 수행
-  둘 중 하나 operation 쓰기 작업 중

 

 

Conflict equivalent (=serializability schedule)

1. 같은 트랜잭션 operation들로 구성된 schedule

2. 양 트랜잭션 내 conflicting operation 실행순서 동일

 

 

 

성능 때문에 여러 트랜잭션 겹쳐(nonserial schedule) 실행할 수 있으면 좋겠다~ 

하지만 이상한 결과 나오는 건 싫다..

=>

conflict serializable한 nonserial schedule을 허용하자!! (=충돌하고 비직렬인 스케줄 허용하자!!)

 

 

conflict serializable는 뭐냐? (=충돌 직렬 가능 스케줄)

동일한 데이터에 대해 두 트랜잭션이 있다고 가정했을 때, 적어도 하나의 연산이 write인 경우 충돌이라 할 수 있다.

=> 여러 트랜잭션들이 동시에 실행되는 상황에서 각 트랜잭션 간의 연산 순서를 조정하여 서로 간섭 없이 순차적으로 실행될 수 있는 것

=> 각 트랜잭션 간에 발생하는 데이터 접근 충돌을 해결하여 전체적으로 실행 순서가 일관성 있게 유지되는 것

 

How to 구현?

schedule이 conflict serializable하도록 보장하는 프로토콜 적용해서 

 

 

 

 

어떤 임의 스케줄 == 임의 serial 스케줄 (equivalent) 

=> serializability 하다~

 

어떤 임의 스케줄 == 임의 serial 스케줄 conflict equivalent하다 

=> conflict serializable하다~

 

어떤 스케줄도 serializable하게 만드는게 동시성 제어

이것과 밀접관련 트랜잭션 속성이 고립성

 

---

Recoverability 복구가능성

트랜잭션 일관성, 내관성 보장 위해 필요.

트랜잭션 실행중 발생하는 비정상 상황으로부터 회복하는 능력

 

unrecoverable schedule

변경 내용이 읽히고 커밋되기 전에 rollback

“rollback해도 이전 상태로 회복 불가능”

이런 스케줄 dbms가 허용하면 안됨

 

그렇다면.. 

어떤 스케줄이 recoverable? (=복구 가능)

 

 

recoverable schedule (복구 가능한 스케줄)

스케줄 내에서 그 어떤 트랜잭션도

자신이 읽은 데이터를 

write한 트랜잭션이 먼저 commit/rollback하기 전까지 

commit 하지 않는 경우에만!

 온전한 rollback 가능  (dbms는 이런 스케줄만 허용해야됨)

(recoverable: 여러 트랜잭션 중 하나 실패시 회복 가능한 것) 

 

 

하나의 rollback, 그에 의존성 있는 다른 트랜잭션도 rollback.

=> cascadeding rollback

 연쇄적 롤백, 처리 비용 높음 

 

그렇다면 어떻게 처리? 

 

 

Cascadeless schedule

스케줄 내 어떤 트랜잭션도

commit되지 않은 트랜잭션이 쓴 데이터는 읽지 않음

 

 

strict schedule

 스케줄 내 어떤 트랜잭션도 commit 되지 않은 트랜잭션이 쓴 데이터는 읽지도 쓰지도 않음

=> rollback시 recovery 쉬움. 트랜잭션 이전 상태로 되돌리기만 하면 됨

 

 

rollback 발생하면 회복 불가.. 그래서 dbms 허용하면 안됨 => recoverable schedule

 

롤백시 회복 가능 中, cascade rollback 발생하면 안됨 => cascadeless schedule

 

것보다 더 엄격하게, 

commit 되지 않은 트랜잭션이 write한 데이터 쓰지도 읽지도 않음 => strict schedule

 

 

---

 

 

어떤 스케줄 있는데.. 

트랜잭션1이 write한 데이터를 또 다른 트랜잭션2가 read했다면

트랜잭션1이 commit하기 전까지 트랜잭션2도 commit 안했어요

=>  너는 recoverable schedule || recoverability 속성 가졌다~ 

(=모두 커밋롤백되기 전까지 커밋 안하고, 복구가능한 속성 가졌다~)

 

> 동시성 제어는 serializability & recoverability 제공 <

 

 

 

어떤 스케줄도 serializable하게 동작하도록 만드는 역할 (=순차적으로 접근하는 것처럼 보이게)

-> 동시성 제어

너무 엄격하게 하면 성능 감소 (제약사항 발생, 동시성 감소)

==> 완화, 유연한 선택 필요 

 

 

How? isolation level 통해서.. <트랜잭션3>으로...