태태개발일지(트랜잭션)

트랜잭션

- 단일한 논리적인 작업단위

- 논리적인 이유(목적) 으로 여러 SQL문들을 단일 작업으로 묶어서 나눠질 수 없게 만든것이 transaction이다.

* transaction의 sql문들중에 일부만 성공한다고 DB에 반영이 일어나지 않는다.

 

START TRANSACTION; --> 트랜잭션 시작을 알림 AutoCommit은 OFF가 된다.
UPDATE --> 
UPDATE -->

COMMIT; -> 지금까지 작업한 내용을 DB에 영구적으로 저장한다.
*transaction 종료

 

RollBack 

-지금까지 작업들을 모두 취소하고 transaction 이전 상태로 돌린다.

 

AutoCommit

- 각각의 sql문으 자동으로 transaction 처리해주는 개념

-sql문이 문제가 있었다면 알아서 rollback을 한다.

 

Set autocommit = 1; --> AutoCommit 상태이다.

Set autocommit = 0; --> AutoCommit 상태가 아니다.

Rollback을 수행한다면 이전 상태로 돌아갈 수 있다.

 

일반적인 Transaction 사용 패턴

1. transaction을 시작.

2. 데이터를 읽거나 쓰는 등의 SQL문들을 포함해서 로직을 수행한다.

3. 일련의 과정들이 문제없이 동작했다면 transaction commit한다

4. 중간에 문제가 생겼다면 transaction을 rollback한다.

 

ACID

-Atomicity (All or Nothing) 논리적으로 쪼개질 수 없는 단위

-Consistency(일관성) A->B에게 돈을 주었을때 제약상황에 걸린다면 실행하면 안된다. 

transactioin이 DB에 정의된 rule을 위반했는지 DBMS가 commit 전에 확인하고 알려준다.

-Isolation(격리) J가 H에게 20만원을 이체할때 만약 동시에 이체한다면? 동시에 실행하는 것을 막기위해서 혼자 실행되는 것처럼 동작하게 만든다.

 

Read Uncommited           -----> 동시성 증가 부정합 문제 발생

commit되지 않은 트랜잭션에 다른 트랜잭션이 개입할 수 있다. 

정합성에 크게 문제 사용X

Read Commited

commit된 데이터에 다른 트렌잭션이 들어올 수 있다.

Undo 영역 -> 데이터에 변경이 일어났을경우 데이터를 저장한다. 이것을 읽는다.

Repeatable Read

트랜젝션 내에서 동일한 쿼리를 날렸을 때 동일한 값을 가져와야한다.

트랜잭션마다 트랜잭션 번호를 가지는데 자신의 트랜잭션 번호보다 낮은 트랜잭션만  읽을 수 있다.

Serialzable                        -----> 동시성 감소 데이터 정합성 증가

가장 엄격

모든 부정합 문제 해결

동시 처리 불가능 권장X

 

부정합 문제:

    Dirty Read

  커밋이전에 변경된 데이터를 보고있을 때 데이터가 롤백된다면 잘못된 데이터를 보게된다.

    Non-Repeatable Read

하나의 트랜잭션에서는 데이터를 여러번 읽었을 때 동일한 값을 가져와야한다.

    Phantom Read

한 트랜잭션에서 동일한 셀렉트 문을 두번 넘겼을 때 
첫번째에 없던게 두번째에도 나오게 된다.

 

DBMS는 여러 종류의 isolation level을 제공한다.

 

-Durability (영속성) commit된 transaction은 DB에 영구적으로 저장된다. 

 

Serial하지않지만 결과는 Serial한 경우 = Serializable schedules라고한다. 

- conflict serializabilty

   두 개의 다른 트랜잭션에 속해있고, 같은 데이터에 대한 operaion이며, 적어도 하나는 write이다. 

- view serializability

  스케줄 안의 트랜잭션들 중에 하나의 트랜잭션이 같은 초기값을 읽어야한다.

 ex) S1에서 T1아 T2가 write한 값을 읽는다면, S2에서도 T1이 T2가 write한 값을 읽어야한다.