메뉴 건너뛰기

bysql.net

4. Redo

2010.05.23 23:45

휘휘 조회 수:11513

  • 오라클을 구성하는 주요 화일

  1. 데이터화일 : 데이터베이스에 저장되는 모든 데이터를 비롯하여 테이블, 인덱스 등의 논리구성내용을 포함한다.
  2. 제어화일 : 각종 화일배치정보 등 물리적인 구성을 지정하는 엔트리를 포함한다.
  3. Redo로그화일 : 데이터에 대해 일어나는 모든 변화를 기록한다.


그 중 데이터의 모든 변화를 기록하는 Redo로그화일에 대해서 알아본다.


  • Redo/Undo의 배경

트랜잭션을 도입하지 않으면 않되는 특성에 "ACID"라는 것이 있다.

또, 이것을 실현하기 위해 REDO(rollforward에 이용)와 UNDO(rollback에 이용)를 생각하지 않을수 없다.

먼저, ACID의 정의를 보자.


  A（Atomicity）: 원자성
     트랜잭션에 포함된 데이타갱신은 "전부 OK" 또는 "전부 NG" 여야 한다는 특성.
     계좌이체갱신 도중, 어떤 이유로 실패할 경우 도중에 갱신된 모든 데이타는 모두 롤백되어야 한다. 

  C（Consistency）: 일관성
     트랜잭션에 의해 데이타간의 정합성이 깨져서는 않된다는 특성.
     즉, 테이블의 데이타는 갱신되고 그에 따른 인덱스는 갱신되지 않는 등의 부정합이 있어선 않된다.

  I（Isolation) : 분리성
     트랜잭션끼리는 분리시켜, 서로 독립되어 있어야 한다는 특성.
     어떤 트랜잭션을 단독으로 실행시켜도, 다른 트랜잭션과 동시에 실행이 되도 결과는 같아야한다.

  D（Durability） : 지속성
     커밋된 트랜잭션은 장애가 발생해도 데이타가 복구되여야 한다는 특성.

이중, 데이타베이스의 가장중요한 특징중 하나인, "COMMIT된 데이타를 보호하는 특성(지속성)" 즉, Roll Forward의 실현에 대해 생각해보자.

간단히, 생각하면 커밋이 발생한 순간 디스크에 기록하면 된다.

하지만, 디스크 I/O의 시간은 대부분 「頭出し」(기록할 선두를 찾는 행위)에 점유당한다.

랜덤액세스방식인 디스크 I/O는 꽤 시간을 소비하게 된다.



fg3.jpg



위 그림은 클라이언트가 커밋을 요청했을 때의 움직임을 표현한 것이다.


0. 커밋전 변경데이터가 버퍼캐쉬에 존재

1. 클라이어트가 커밋 요청

2. 서버프로세스가 버퍼캐쉬의 내용(변경데이터)을 디스크로 이행

3. 디스크의 헤더가 움직이며 내용을 기록 (랜덤액세스) 

4. 커밋완료 클라이어트에 통지.

  • 이때, 3.번 처리에서 상당한 I/O시간이 발생한다. 

    또한, 시스템이 다운되었을 때, 버퍼캐쉬의 데이타를 잃게되므로 미처 옮기지 못한 내용, 전부 혹은 일부를 상실하게 된다. (지속성, 원자성 파괴)

  • 이를 보완하기 위해 버퍼와 디스크 사이에 화일(Redo로그화일)을 하나 배치하여 퍼포먼스와 원자성, 지속성을 유지한다.

    즉, 비교적 시간이 많이 걸리는 디스크에 직접 기록하기 전보다 시간이 덜 걸리는 화일에 커밋내용을 기록하고 차후에 화일내용을 디스크에 반영한다.

  • 시스템이 도중 다운되었을 경우, 최초 기동시 디스크의 내용을 Redo로그화일과 동기화를 시켜 갱신함으로써 지속성을 보장하게 된다.

    ※지속성을 유지하는데는, 롤포워드와 롤백이 있다. REDO는 롤포워드를 실현하기 위함이다.

  • 또한, 디스크의 I/O횟수를 격감시킴으로써 퍼포먼스문제도 해결된다.


  • Redo로그화일의 구성


  • Redo로그화일은 아래와 같이 그룹화시켜 구성한다.
  • Redo01(그룹1)에 내용을 기재해 가다가 내용이 꽉차면 로그스위치가 발생(체크포인트완료), Redo02(그룹2)에 기록을 계속한다.
  • 이때 DBWR 프로세스는 Redo01의 내용을 디스크(데이터화일)에 이행시켜준다.
  • Redo03(그룹 3)까지 내용이 다 채워지면 순환하여 Redo01가 재상용된다. (덮어쓰기)
  • 만약, Redo01차례가 되도록, 아직도 DBWR가 Redo01의 내용을 이해중이면 어떻게 될까. (수요일에)


 fig01.gif




 일반적으로, 디스크의 물리적 장애를 대비하여 각 화일은 서로다른 영역에 각 그룹별로 2개이상의 멤버를 구성하여 운용한다.



  • 기본원리

1. 커밋신청

혹은, 3초마다 DBWR로부터 신호를 받을때 (DBWR는 LGWR가 Redo로그버퍼의 내용을 완전히 Redo로그화일로 옮긴후 작업을 한다.)    혹은, 로그버퍼가 1/3차거나, Redo레코드양이 1MB를 넘을때.


2. 백버퍼에 기록되있는 내용을 LGWR이 Redo로그화일에 이행.


3. 로그스위치가 발생하면 DBWR가 오래된 Redo로그 내용을 데이터화일에 이행한다.


4. ARC0에 의해 Redo로그화일의 내용은 아카이브로그화일로 복사된다.


  • 아카이브로그화일(Offline Redo）은 순환사용에 의해 언젠가는 없어질 Redo로그화일을 백업하는 역활을 한다.

  • Redo로그화일은 Online Redo로그화일이라고도함.



  • REDO로그의 목적

  • 1. 아카이브로그 화일을 이용한 데이타베이스리커버리가능

  • 2. Online Redo로그화일에 의한 캐쉬리커버리가능

  • 3. 커밋요청시 Redo로그화일에 커밋시키는 원리로 빠른커밋가능


이 게시물을
목록
목록
번호 제목 글쓴이 날짜 조회 수
67 Front Page file 운영자 2010.05.16 155060
66 1 장. 오라클 아키텍처 운영자 2010.05.19 18062
65 1. 기본 아키텍처 [1] file 휘휘 2010.05.22 20158
64 3. 버퍼 Lock [1] 휘휘 2010.05.23 15483
63 2. DB 버퍼 캐시 file 휘휘 2010.05.23 22108
» 4. Redo file 휘휘 2010.05.23 11513
61 9. Snapshot too old balto 2010.05.30 8313
60 10. 대기 이벤트 balto 2010.05.30 8203
59 7. Consistent vs. Current 모드 읽기 휘휘 2010.05.30 10781
58 8. 블록 클린아웃 휘휘 2010.05.30 12492
57 11. Shared Pool file 실천하자 2010.05.30 18711
56 5. Undo file 토시리 2010.05.30 18919
55 1. 트랜잭션 동시성 제어 실천하자 2010.05.30 8814
54 6. 문장수준 읽기 일관성 file 토시리 2010.05.31 10594
53 2장. 트랜잭션과 Lock 운영자 2010.06.01 7066
52 1. Explain Plan 실천하자 2010.06.06 14890
51 2. AutoTrace 실천하자 2010.06.06 8781
50 3장. 오라클 성능 관리 운영자 2010.06.06 6872
49 3. SQL 트레이스 file balto 2010.06.06 21384
48 4. DBMS_XPLAN 패키지 balto 2010.06.06 10619
쓰기
태그