REDO LOG BUFFER

REDO LOG BUFFER

REDO LOG BUFFER

DATA BLOCK에 변경사항 (DDL, DML) 생길경우 해당 내용 기록. 장애복구용. 

TRANSACTION 수행중 장애발생시 해당변경 사항 복구 용도 ( COMMIT된 DATA & ROLLBACK된 DATA)

COMMIT 후 CHECKPOINT 전 DB 가 정전이 되면, 해당 DATA를 ROLL FORWARD (DBC의 변경내용 저장완료후 한번 더 저장)

REDO LOG 생성 및 기록원리

  기록 두가지 규칙 :

- WRITE LOG AHEAD (선 로그 기법) : DATA 변경/ 저장 전 REDO LOG BUFFER & REDO LOG FILE 에 먼저 기록

- LOG FORCE AT COMMIT : REDO RECORD(LOG) 들을 COMMIT 요청이 들어오면 REDO LOG FILE에 먼저 저장

< REDO LOG 기록원리 >

REDO LOG 기록 원리 

1. DBC에 변경 DATA BLOCK 의 해당ROW 부분에 LOCK 설정 (PAGE FIX) 후 PGA에서 REDO LOG CHANGE VECTOR 생성

 * REDO LOG CHANGE VECTOR : 복구용 목적으로 변경되 DATA를 REDO LOG에 기록할 DATA 에 대한 모든 정보의 세트. 정보는 해당 DATA ROW에 수행하는 DML 문장의 종류에 따라 달라짐.

 * roll forward ( DBC 의 변경 완료후 commit이 되었으나 저장되지 않은 것을 저장

 * rollback ( 사용자가 rollback한 후 아직 rollback이 완료 되지 않은 것을 저장)

예) 하나의 ROW를 INSERT 하는 경우 

- change #1 = undo segment header 변경내용

- change #2 = undo block 변경 내용

- change #3 = data segment header 변경 내용

- change #4 = data block 변경 내용

2. PGA에서 Change Vector 생성 후 Redo Log Buffer에 필요한 용량 계산후 , 서버프로세스는 change vector를 Redo Log Buffer에 복사 하기 위해 Redo Copy Latch( 유한한 메모리 자원 사용시 번호 대기표 같은 개념 ) 획득

 * Redo Copy Latch 의 수는 _log_simulatneous_copies 히든 파라미터로 조정가능

조회 방법

---

SQL> col name for a13

> select name, gets, misses, immediate_gets, wait_time

2 from v$latch_children

3 where name='redo copy';

---

3. Redo Copy Latch 획득후 Redo Allocation Latch 확보

 * Redo Allocation Latch : ORACLE 8i 까지는 1 개 밖에 없었지만, 이후부터는 Shared Redo Strand ( Redo Log Buffer를 여러개의 공간으로 나우어서 각 공간별로 Redo Allocation Latch할당 ) 기능 도입

 * Strand : 여러개로 분활된 영역, 기본값은 1이고, 나누는 갯수는 log_parallelism 파라미터 값으로 설정

 10g 에서는 _log_parallelism (히든 파라미터) 변경되고 _log_parallelism_dynamic 파라미터 추가 ( 설정 값이 true일 경우 oracle이 자동으로 strand 갯수 설정), 권장값은 cpu 갯수/8 이다.

  * Private Redo Strands : Zero Copy라는 기술, 10g이후부터 추가. LATCH 확보경합이 최소화되고. 각 서버프로세스는 shared pool에 자신만의 private redo strand 공간 생성후 그곳에 change vector 생성후 필요할 경우  LGWR이 LATCH 획득하지 않고 바로 REDO LOG FILE에 기록. _log_private_parallelism=true 로 설정하면 활성화가 된다.

REDO ALLOCATION LATCH 갯수 조회 

---

SQL> select count(*) from v$latch_children

2 where name='redo allocation';

---

4. REDO LOG BUFFER에 기록된 CHANGE VECTOR 내용들은 특정상황이 되면 LGWR이라는 백그라운드 프로세스에 의해 가장 최근에 기록되어진 이후부터 현재까지 변경된 내용들을 하드디스크에 있는 REDO LOG FILE에 기록 

특정상황 :

- 3초마다 LGWR은 SLEEP상태로 있다가 한번씩 (RDBMS IPC MESSEGE 라는 대기 이벤트 TIMEOUT 되는 시점) WAKE UP해서 REDO LOG BUFFER 에 기록할 내용이 있는지 확인후 있으면 REDO LOG FILE에 기록후 기록 내용을 REDO LOG BUFFER에서 FLUSH함

- REDO LOG BUFFER의 전체 크기의 1/3 또는 (1/6) 이 찼거나 1M가 넘을경우. LOG BUFFER의 BLOCK의 수가 _LOG_IO_SIZE 값보다 많을 경우 서버프로세스는 REDO LOG BUFFER를 할당 받을때마다 현재 사용된 LOG BUFFER의 BLOCK 수 계산. REDO LOG BUFFER의 크기가 1/3이 변경된 내용으로 찼거나, 변경량이 1MB가 넘을 경우 가장 최근에 기록된 내용이후의 변경 내영을 REDO LOG FILE로 자동으로 내려쓴다.

- DBWR이 LGWR에게 요청할때. DBWR이 내려써야 하는 DATA가 아직 REDO LOG BUFFER에 있다면 LGWR 실행후 DBWR이 디스크에 해당 내용포함 LGWR의 ON-DISK RBA값보다 큰 HIGH-RBA 값을 가진 BLOCK을 DBWR이 기록해야 할때, 해당 BLOCK을 DIFFERED WRITE QUEUE에 기록후 LGWR 기록후 DBWR 기록해서 SYNC를 맞춤.

- 사용자가 COMMIT 또는 ROLLBACK을 수행 할때 SYNC WRITE 함.

 * SYNC WRITE : COMMIT 이나 ROLLBACK 수행후 가장 최근에 REDO LOG BUFFER 에 기록된 내용이후로 변경된 내용을 REDO LOG FILE에 기록후 해당내용을 지우는것

 * 예외 : DIRECT LOAD (SQL LOADER, INSERT /* + APPEND */) 나 TABLE/INDEX 생성시 NO LOGGING 옵션을 주는 경우 REDO LOG 에 기록되니 않음. 단 NO LOGGING 이어도 INSERT, UPDATE, DELETE 같은 작업은 기록됨.