트랜잭션

What? 여러 개의 쿼리를 하나의 작업 단위로 묶은 것. (mysql에선 start transaction~commit까지임)

 

ACID 성질을 만족함

-Atomicity(원자성): all or nothing (아래의 why 참고)

 

-Consistency(일관성): 기본키 외래키 제약 조건 등이 어떤 커넥션에서든 조건이 동일해야 한다

 

-Isolation(독립성): 복수의 트랜잭션이 순서대로 실행되는 경우와 같은 결과를 얻을 수 있어야 한다.

ex) 방 10개 중, a와 b가 같은 화면을 보고 동시에 예약하면 2개 빼져야하는데 고립성 보장 안되면 1개만 빠짐.

직렬화 기능을 제공하여 격리수준을 더티읽기(a가 커밋 안했어도 9개로 읽음)~애매한 읽기(1회결과=?2회결과)로 조절 가능하다.

 

-Durability(지속성): 성공적으로 커밋되고 나면 하드웨어적or소프트웨어적 문제 발생해도 보존되어야 한다. 

 

 

트랜잭션 관리를 잘 해야한다!

Why? 하나의 단위인데 그 안에서 A 수정 후 B 수정인데 B가 not null 조건에 위배된다면

이미 수행된 A를 어떻게 하느냐, 이런 것을 처리하기 때문이다.

 

issue!

제약 조건 위배->사용자 요청으로 철회되는 상태

교착상태, 타임아웃->DBMS가 철회

아무 문제 없음->커밋된다

 

+교착상태: 서로 잠금을 건 자원에 잠금이 필요한 처리. 아무리 기다려도 바뀌지 않는 상태-> 트랜잭션을 자주 커밋해서 작은 단위로 쪼개서 교착상태의 가능성을 낮춰서 해결할 수도 있다.

 

+데이터베이스 시스템 구조

(질의처리기  |   (페이지버퍼) 저장시스템 )

 

DBMS는 데이터를 디스크에 저장하고, 일부는 메인 메모리에 유지한다. 저장의 단위는 페이지. 

여기서 페이지버퍼를 관리하는 버퍼관리자의 역할이 중요하다!

버퍼교체알고리즘에 의해 커밋이 완료되지 않았지만 수정된 페이지를 디스크로 보내버릴 수가 있기 때문이다.(isssue 세번째에 해당하는거지) 보내기 전에 UNDO를 해줘야한다.  

 

UNDO: 완료되지 않았지만 일부 수정된 페이지를 원상복구

대부분 RDBMS는 언제든지 디스크에 수정된 페이지를 쓸 수 있도록 허용하기 때문에 UNDO는 필연적이다.

이전의 이미지로 현재 이미지를 대체

 

REDO: 커밋한 트랜잭션의 수정을 재반영하는 복구

대부분 RDBMS는 수정한 페이지를 커밋시점에 바로 디스크에 반영하지 않기 때문에 REDO는 필연적이다.

이후 이미지를 반영

 

UNDO와 REDO를 하는 법->LOG를 이용! 

 

LOG: DBMS의 모든 변경사항을 기록하는 레코드들이다. 변경 이전의 이미지와 이후의 이미지를 모두 가지고 있다. 

복구작업에 활용되므로 매우 안전하게 보관되어야 한다. 그래서 느린 함수를 쓴다.

issue! 로그쓰기(commit operation)의 성능을 높이는 법? 

그룹 커밋 대기시간을 잘 정해서 한꺼번에 처리한다. 디스크 출력 횟수가 줄어들기 때문에 속도가 빨라진다.

 

 

결론: 어차피 DBMS가 알아서 동시에 하면 하나는 롤백해서 교착상태 처리하는데 왜 알아야하냐면,

DBMS마다 정책에 약간씩 다르고 성능이 안좋을때 그 원인과 대처(로그성능,교착횟수)를 할 수 있다.

또한, 로그보존의 중요성을 알아서 사고를 예방한다.