5. Redo log Buffer

[ Redo log buffer ]

- dbms 내 모든 변경 내용(데이터의 변경, 메타데이터 변경) 기록하는 메모리 영역

- LGWR에 의해 주기적으로 redo log file에 기록됨

- 장애시 이전 데이터나 commit을 완료한 데이터를 토대로 복구를 하기 위한 영역

- redo log buffer 의 크기는 동적 변경 불가

- log_buffer 파라미터로 크기 조절 가능

 

 

[ archive log mode ]

- archive log file을 만드는 상태

- redo log file 내용이 덮어쓰여지기 전에 redo log file 내용을 복사해두는데 이를 archive log file이라고 함

 

1. 확인

SQL> archive log list;

 

** instance recovery 실패 케이스

1) DB 종료 직전 대용량 변경 작업 수행 중 (100 ~ 120번 SCN 기록)

  => dirty buffer 다량 발생

  => 변경 작업 내용이 redo log buffer에 기록

  => dirty buffer를 DBWR가 내려쓰기전에

       항상 redo log buffer의 내용을 redo log file에 LGWR가 기록

       (2개 redo log group만 존재하는 경우)

       100 ~ 108번 은 1번 redo log file에 기록됨

       109 ~ 116번 은 2번 redo log file에 기록됐다고 가정

       117 ~ 120번 은 1번 redo log file에 덮어씀 => 100 ~ 108번 변경정보 손실

 

2) DB shutdown abort

  => 100 ~ 120번을 기족하지 못하고 즉시 종료

 

3) DB startup

  => 100번 부터 복구 작업을 시작(변경된 내용을 redo log file에서 찾아 datafile에 저장)

  => 이미 1번 redo log file에 새로 117번 부터의 정보를 기록했으므로

       100 ~ 108번 정보는 더이상 redo log file에 존재하지 않기 때문에 복구 실패

          need media recovery 메시지와 함께 DB 정상 open 불가!!!

 

 

아카이브 행이 발생하는 과정

 

 

 

** redo log buffer size 작다면?

- 잦은 disk I/O 발생(LGWR 자주 동작)

- redo log buffer 기록하기 위한 병합(wait) 발생

  => log file sync wait event

 

 

** redo log file size 작다면?

- 잦은 log switch 발생

- archive hang 발생 가능성이 높아짐(redo log group 의 개수를 늘려서 해결함 )

 

 

 

2. 변경

나중에

 

 

 

[ 실습 ]

1. 할당된 redo log buffer 사이즈 확인

1) SQL prompt

SQL> show parameter log_buffer

asmm 환경임에도 최소 사이즈 지정

 

2) v$parameter

select name, value, display_value
  from v$parameter
 where name = 'log_buffer';

 

 

 

 

2. 실시간 redo log buffer 사이즈 확인

 

select name, value
  from v$sysstat
 where name in ('redo entries',           ------- redo buffer에 저장되는 단위
                   'redo size');                      ------- 현재 생성된 총 redo entries 사이즈