리두 로그 버퍼 (by dolphhong) [2013.01.18]
리두 로그 버퍼 ( Redo Log Buffer )
리두 로그 개념
- DB에서 발생한 작업의 기록
- Redo log buffer 를 통해 Redo log file로 저장
- 장애 시 데이터 정합성 유지를 위해 필요한 정보
- 데이터 변경 발생 시, 리두로그 생성 후 실제 데이터를 변경
- 리두 로그 영역에 대한 대기 이벤트를 줄여야 한다
- 리두 로그 버퍼의 데이터가 리두 로그 파일로 신속히 기록되고 비워질 수 있어야 한다.
리두 로그 구조
- 리두로그 > 리두 레코드 > 체인지 벡터로 구성
- 체인지 벡터 (Change Vector)
- 하나의 데이터 블록에 대한 단일 변경 내역.
- 변경 블록 주소, SCN, 변경 발생 명령문 정보가 저장됨.
- PGA에서 생성되어 리두 로그 버퍼로 복사
- 리두 레코드 (Redo Record)
- 체인지 벡터의 집합
- 전체 트랜잭션을 구성하는 작은 트랜잭션의 시작과 끝을 의미
- 데이터 복구 시 전체 적용 or 아무것도 적용하지 않는 복구 보장
- 리두 레코드는 각 RBA를 갖는다
- 단일 insert 리두 레코드는 UPDATE 언두 세그만터 헤더, 언두 데이터 생성, 리두 데이터 생성, 트랜잭션 추적 로그 생성의
네가지 체인지 벡터로 구성된다
- RBA(Redo Byte Address) : 리두 로그 파일에서 리두 레코드가 물리적으로 위치한 값
( 리두 로그는 발생 순서대로 저장되므로, RBA는 리두 로그 생성 시간을 나타낸다 )
로그 시퀀스 번호가 높을수록,
같은 블록에서는 바이트 오프셋이 높을수록 나중에 생성된 리두 로그 정보이다. - RBA 구성
- 리두 로그 시퀀스 번호. 4 byte
- 리두 로그 블록 번호. 4 byte
- 리두 로그 블록 내의 위치 정보 (Bytes Offset). 2 byte
- 리두로그 생성,관리 규칙
- 물리적/논리적 로그 (Physiological Logging)
- 선 로그 기법 (Write Ahead Log)
- 페이지 고정 규칙 (Page Fix Rule)
- 논리적 리두 로그 정렬 (Logical Ordering of Redo)
- 커밋 시 리두 로그 저장 (Log Force At Commit)
- 오라클은 물리적, 논리적 방식으로 리두 로그를 생성한다.
| 논리적 로그 | 변경 전, 후 명령만 저장하여 저장 용량이 작다. 변경 블록의 주소 값을 저장하지 않으므로 롤백 소요 시간이 오래 걸린다. 여러 블록에 insert 수행 중 트랜잭션이 종료되면, 어느 블록까지 변경이 적용되는지 파악 되지 않아 insert 재수행 하여 롤백. | 물리적 로그 | 변경 전, 변경 후 데이터 블록 이미지 저장. 저장 용량이 커짐. |
| 물리적/논리적 로그 | 변경 전,후 명령, 변경 후 정보 및 변경 블록 주소값 저장. 변경 전 정보가 저장된 언두 블록의 주소 저장. 저장 용량이 작아 빠른 롤백이 보장됨. # 데이터 정합성 유지를 위해 선 로그 기법 적용 ## DML수행 시 데이터 변경 전, 리두 로그 생성. 변경 전 데이터는 언두 세그먼트에 저장. (redo log에는 변경 전,후 명령 / 변경 후 정보 / 변경된 블록 주소 값 / 언두 블록 주소 값 저장됨) ## DBWR이 더티 버퍼를 디스크에 기록 전, LGWR이 먼저 호출되어 리두 버퍼의 정보를 리두 로그 파일에 기록 ## 선 로그 기법 사용으로 DML수행 중 장애 발생 시 복구 가 # 페이지 고정 규칙 : 리두 로그 생성 시 변경하려는 데이터가 저장된 블록의 상태는, 데이터 변경 완료 시 까지 변경되면 안됨 (데이터 정합성) # 논리적 리두 로그 정렬 : SCN순서로 순차적으로 리두 로그 버퍼에 기록됨 # 커밋 시 리두 로그 저장 : 커밋 리두 레코드 생성 후 LGWR 호출하여 리두 버퍼의 내용을 리두 로그 파일에 기록 # 빠른 커밋(Fast Commit) : 커밋 시 변경된 버퍼 캐시를 데이터파일로 내려쓰지 않고, 리두 버퍼의 데이터만 리두 로그 파일로 내려쓰는 방식. |
- SCN (System Change Number)
: 트랜잭션이 커밋될 때 마다 순차적으로 증가. DB의 커밋 버전.
: 데이터베이스의 모든 컨트롤파일, 데이터파일, 리두레코드의 헤더 정보에 동일하게 저장됨
리두 로그 생성 절차
- 데이터 변경을 위해 서버 프로세스가 버퍼 캐시 내의 변경 블록에 배타적 모드로 핀 적용, 데이터 블록 점유
- PGA 공간에 변경 정보를 담고있는 체인지 벡터 생성
- 필요한 리두 사이즈 계산 후 체인지 벡터를 리두 버퍼에 복사하기 위해 redo copy 렛치 획득
- 리두로그 버퍼에 공간할당을 위해 redo allocation 렛치 획득
- 리두로그 버퍼 공간이 있다면 redo allocation 렛치 해제, 리두로그 버퍼의 프리 공간에 체인지 벡터 복사
- 완료되면 redo copy 렛치 획득 해제
- 리두 로그 버퍼에 체인지 벡터 반영 되면, 배타적 모드로 핀을 할당한 버퍼 블록에 데이터 변경 수행
- 리두로그 버퍼의 프리 공간 확보 실패 시 redo copy 렛치, redo allocation 렛치 해제 후 redo write 렛치 획득 후 LGWR호출
- LGWR은 리두 로그 버퍼의 변경된 리두 데이터들을 리두 로그 파일에 기록, 프리공간 확보
- LGWR에 의해 리두 로그 버퍼에 프리공간 확보 시 오라클은 3번부터 작업
리두 로그 버퍼 크기 선정
- 공유 풀이나 버퍼 캐시 영역에 비해 아주 작은 크기를 사용
- MAX(0.5M,(128K X CPU수))
NOLOGGING
- 대량 데이터 변경 시 nologging 기능 사용 -> 로그 발생량을 축소하여 성능 개선 효과
- 로그 발생하지 않아 추후 해당 데이터는 복구 불가
대기 이벤트
- 리두 로그 파일의 I/O 성능 최대화
