MVCC이전, DB에서의 Lock과 Blocking

다중 트랜잭션 환경에서 Lock과 직렬화

다중 트랜잭션 환경에서는 같은 자원에 액세스하는 트랜잭션들이 동시에 발생할 수 있다.

같은 자원에 액세스하는 트랜잭션들이 동시에 발생해도

순차적 보장을 위해 직렬화 작업이 필요하다.

이 직렬화 작업에 필요한 요소가 Lock이다.

Read session, Write session 등이

Lock을 획득하기 위해 Lock queue에 대기한다.

Share lock, Exclusive lock

share lock

share lock은 데이터를 읽을 때 사용된다.

- 다른 share lock과 호환 가능하다.

   -> 자신이 읽고있는 리소스를 다른 사용자가(타 세션) 동시에 읽을 수 있다.

- exclusive lock과 호환되지 않는다.

  ->자신이 읽고있는 리소스를 다른 사용자가(타 세션) 동시에 수정할 수 없다.

exclusive lock

exclusive lock은 데이터 변경 시 사용된다.

트랜잭션 완료 시까지 유지되며, 동시에 다른 Tx이 읽거나 쓸 수 없다.

Blocking

동시에 같은 데이터에 대해

2개의 읽기 요청이 수신된다면

share lock x share lock 상태이므로 blocking이 발생하지 않습니다.

반면,

동시에 같은 데이터에 대해

wirte - read 요청이 순차적으로 수신된다면

exclusive lock x share lock이 순차적으로 발생하므로

write 작업이 끝날 때 까지 read 작업이 blocking되어 읽을 수 없습니다.

write-write 요청도 마찬가지입니다.

Blocking 작업이 해소되려면

선행하는 write 작업이 commit이나 rollback 돼야합니다.

Lock으로 인한 성능 저하 최소화 방안

곧, Blocking 으로 인한 대기시간이 최소화가 되는 방안과 같은 말입니다.

일반적으로 Blocking이 적게 일어나면 대기 시간을 줄일 수 있습니다.

이를 위해서는

- Tx을 가능한 한 짧게 유지해야함.

- 같은 데이터를 갱신하는 Tx이 동시에 수행되지 않게 해야합니다.
   (ex : 트랜잭션이 활발한 주간에 대용량 갱신 작업)


Tx는 업무처리를 위한 논리적 작업 단위이고

논리적 작업의 결과가 빨리 나오는, 효율적인 SQL을 만드는 것이 가장 기본적인 튜닝 방법입니다.

◼ Tx != 단일 연산