DBMS Transaction ( Log )

 

DBMS Transaction ( Log )

 

 

 

LOG

자체적으로 로그를 사용(Undo, Redo 등)하고, 로그를 기록하기 위해서 로그 버퍼를 사용

로그를 작성하기 위해서는 write와 fsync 함수를 호출

 

 

fsync 함수 : 호출시 매우 느린 연산이고 커밋을 위해서는 트랜잭션의 로그가 로그 파일에 써져야 하기 때문에 fsync 함수가 종료 할때 까지  대기

 

 

Commit 연산 : 연산이 사용하는 대부분의 시간은 로그 파일에 로그 레코드를 쓰고 fsync 함수를 호출하는 시간

 

 

Group Commit : 커밋 요청들을 한번에 하나씩 처리하게 되면 fsync 함수를 여러번 호출하고 로그 레코드를 로그 파일에 쓰는 시간이 길어지므로 커밋 요청을 처리하는 시간이 증가 및 성능 저하.

→ 랜잭션이 커밋 요청을 하면 즉각적으로 요청을 수행하는 것이 아니라 다른 트랜잭션들의 커밋 요청도 기다린 후 한번에 여러개의 커밋을 수행

시간을 너무 많이 증가시켜 버리면 응답 시간은 늘어나고 효율은 정체되는 현상이 발생되므로 적절한 설정이 필요

 

 

로그의 데이터 타입에 관계 없이 두 가지 큰 원칙을 따라서 작성
1. WAL(Write Ahead Logging) : 데이터베이스에 업데이트 되기 전에 기록
2. Commit 이전 로그 레코드가 기록

 

 

 

로그 레코드의 오브젝트

 

• 물리적 상태 로깅(physical state logging) : 물리적 상태 로깅에서는 상태 변화 이전의 이미지와 현재의 이미지를 모두 로그 레코드로 저장합니다. 변화된 이미지는 redo 복구시에 사용하며 변화 이전의 이미지는 undo 복구시에 사용하는 방식으로 사용 됩니다. 대부분의 DBMS가 채택하고 있는 방식 입니다. 
• 물리적 전이 로깅(physical transaction logging) :  물리적 전이 로깅에서는 상태 변화 이전과 이후의 이미지를 모두 저장하기 보다는 XOR 차이점을 기록하는 방식입니다. XOR 이미지와 레코드 이미지를 이용해서 undo, redo 복구를 수행 합니다.
• 논리적 전이 로깅(logical transaction logging) : 논리적 전이 로깅은 이미지 데이터를 저장하는 것이 아니라 연산 자체를 저장 합니다. 예를 들어서 x = x - 1 연산을 수행 했다면 연산 자체를 기록 합니다. undo 복구에서는 해당 연산의 역연산을 수행하고 redo 복구에서는 해당 연산을 다시 연산 합니다. 물리적 로깅보다 레코드의 크기가 작다는 장점이 있습니다. 하지만 더 중요한 점은 연산을 수행하면서 레코드의 페이지 내 주소값이 바뀌거나 페이지 자체가 변하는 경우에는 물리적인 복구가 쉽지 않은데 논리적인 복구를 통해서 더 간단하게 복구가 가능 하다는 점 입니다.

 

 

 

 

 

(참조) https://d2.naver.com/helloworld/407507

(참조) https://inor.tistory.com/16