[DB] DBMS의 commit과 rollback은 어떻게 처리되는가

 

들어가기 전에

서적으로 스터디를 시작했는데 첫 주 발표자로 당첨이 됐다. 스터디가 바로 시작되면서 시간이 부족해서 첫 주 분량이 조금 적었는데 그러다 보니 시간적 여유가 있어서 처음으로 ppt를 만들어서 발표를 하게 됐다. 

깊게 찾아본다기 보다는 아는 내용은 빠르게 설명하고 넘어가고 데이터 캐시와 로그 버퍼의 크기가 극단적으로 비대칭화되어 있는데 오라클 11g부터 도입된 AMM(Auto Memory Management)과 같이 리소스를 자동으로 조정하는 기능이 있다고 간략하게 소개하는 정도였다. 그러다 보니 이런 로그 버퍼들이 정확히 어떻게 쓰이는지에 대한 내용은 간과하게 되었는데 다행히도 발표가 끝난 이후에 DBMS의 커밋과 롤백의 내부 처리 과정에 대해 질문을 받아서 놓치지 않고 정리를 할 수 있게 되었다. 

 

 

질문의 바탕이 된 구문은 다음과 같다.

<SQL 레벨업> p.34
"DB가 갱신을 비동기로 하는 이상, 로그 버퍼 위에 있던 데이터가 디스크 위의 로그 파일에 반영되기 전 장애가 발생해서 사라질 여지가 있다. 이를 회피하고자 DBMS는 커밋 시점에 반드시 갱신 정보를 로그 파일에 씀으로써, 정합성을 유지할 수 있게 한다."

 

Commit 

Commit 과정에 대해서 오라클 내부 동작 과정은 다음과 같다.

1. 사용자가 DML문을 실행한 후 Commit문을 실행한다.
2. 서버 프로세스는 DML문의 처리 결과가 저장되어 있는 로그 버퍼 영역에 시스템 변경 번호(System Chance Number)를 부여한다.
3. 로그 기록기(LGWR)는 로그 버퍼 영역에 있는 변경 데이터를 영구적으로 보관하기 위해 REDO 로그 파일에 저장한다.
4. 서버 프로세스는 네트워크를 통해 사용자 프로세스에서 Committed 메시지를 전송하고 사용자 프로세스는 화면에 메시지를 출력해 준다.
5. 만약, 로그 버퍼 영역의 데이터를 하나의 REDO 로그 파일에 모두 저장하지 못하면 다음 로그 파일로 위치를 이동시키는데 이것을 로그 스위치(Log Switch)라고 한다.
6. 로그 스위치가 발생하면 CKPT(ChecK-PoinT) 프로세스는 컨트롤 파일과 데이터 파일의 헤드 영역에 시스템 변경 번호와 관련 상태 정보를 저장한다. 이것을 체크포인트 이벤트라고 한다.
7. 이 작업이 끝나면 데이터 베이스 기록기(DBWR)는 데이터 버퍼 캐시 영역에 있는 사용자의 변경 정보를 최종적으로 테이블에 저장한다.
출처 : https://dataonair.or.kr/db-tech-reference/d-story/db-tuning-service/?mod=document&uid=42397

commit 과정의 이해를 돕기 위한 Orcle 내부 구조

 

추가적인 설명을 하자면, 시스템 변경 번호는 커밋이 발생한 이후에 트랜잭션이 가지는 고유 번호를 말하고 체크포인트는 시스템 변경 번호와 비교해서 커밋된 정보를 어디까지 저장했는지 확인하기 위해서 사용한다.

 

MySQL의 트랜잭션 처리 과정에서도 비슷한 과정으로 진행이 된다(MySQL 로그 관련 포스팅). Commit이 발생했을 때 바로 테이블로 저장되는 것이 아니라 갱신 데이터를 저장하는 특정한 영역인 Buffer pool과 Log Buffer에 저장되고 각종 로그와 로그 파일에도 저장을 해서 혹시나 모를 장애 상황에 대비하여 갱신 데이터를 저장한다.

 

 

Rollback

Rollback 과정에서는 Commit 과정에서 저장된 데이터들을 활용해서 진행하는데 REDO와 UNDO 개념을 살펴보자면 다음과 같다.

• REDO : 데이터베이스 내에서 일어난 모든 변화를 기록되며 복구될 때 기록된 모든 작업을 다시 진행한다.
• UNDO : Rollback과 동의어로, 이전 데이터로 복구할 수 있도록 업데이트 전의 데이터를 기록하며 롤백할 때 작업을 원상태로 되돌린다.
  (출처 : http://wiki.gurubee.net/display/CORE/Undo)

 

시스템 장애가 발생했을 때의 순서

1. 시스템 장애 발생 시 UNDO의 데이터는 사라진다.
2. REDO 데이터를 이용해서 마지막 CKPT부터 장애까지의 buffer cache를 복구한다.
3. 복구가 완료되면 UNDO를 이용해서 Commit되지 않은 데이터를 모두 롤백한다.

즉, REDO가 UNDO를 복구하고 최종적으로 UNDO가 복구를 하게 된다.

출처 : https://brownbears.tistory.com/181

 

롤백 과정

1. Undo record chain의 head를 찾는다.

• transaction table의 transaction descriptor에서 찾을 수 있다.
• chain 내의 각각의 link는 undo record를 가리킨다.
• user undo 부분이 rollback 시 적용되어야 하는 부분이다.

2. Undo record의 user undo 부분에 기록된 데이터 변경 작업을 역순으로 수행한다.

출처 : Oracle의 Rollback Segments와 Undo Segments - 한국오라클(주) 제품지원실

 

 

정리

- DBMS는 각각 이름은 다르지만 갱신 데이터를 저장하는 영역이 따로 생성되어 있으며, commit 과정 중에 이 영역에 데이터를 저장하여 데이터 정합성을 유지한다.

- 로그 버퍼의 데이터를 로그 파일에 갱신하는 것은 영구적으로 갱신 정보를 보관하기 위함이다. 

- rollback 과정에서 UNDO에 기록된 데이터를 활용하여 업데이트 전의 데이터로 되돌릴 수 있도록 작업을 수행한다.