1. 리두 로그 버퍼
- 오라클은 내부적으로 임의의 변경사항이 발생하게 되면 이러한 하나한의 변경 정보들을 '리두 로그'라는 형식으로 메모리 상에서 발생시키고 리두 로그 버퍼라는 메모리 영역에 일단 저장시킨다. 리두 로그 버퍼는 주로 DDL 또는 DML 문장에 의하여 데이터베이스에 저장된 값 또는 데이터베이스 구조에 변경이 생기는 경우 이러한 변경 정보를 놓치지 않고 저장하는 메모리 영역이다. 리두 로그 버퍼에 저장되는 이러한 정보들은 커밋이 되는 순간 로그라이터(LGWR)라는 백그라운드 프로세스에 의하여 리두 로그 파일로 물리적으로 저장된다. 이처럼 물리적으로 리두 로그 파일로 내려 적는 이유는 간단하다. 중요한 정보인데 리두 로그 버퍼라는 메모리에만 저장한다는 것은 다소 위험하기 때문이다.
2. 리두 로그 구조
- 리두 로그 파일은 파일 헤더(File header), 리두 헤더(Redo header), 리두 레코드(Redo record)로 구성되며 리두 레코드는 리두 레코드 헤더(Redo record header)와 체인지 벡터(Change vector)들로 구성된다. 결국 리두 로그는 체인지 벡터들의 총합으로 구성된 리두 레코드들로 구성된다는 의미이다.
- 체인지 벡터란 하나의 데이터 블록에 대한 단일 변경 내역으로서 변경된 블록주소, 변경된 시점에서의 SCN(System Commit Number), 변경을 발생시킨 SQL 명령문 정보를 의미하는데 일단 PGA에서 생성되어 리두 로그 버퍼에 기록된다. 이때 리두 레코드 포맷(Redo record format) 형식으로 로우 단위로 리두 로그 버퍼에 복사된다. 이러한 체인지 벡터들의 집합을 리두 레코드라고 이해하면 된다. 이후 데이터베이스 복구가 필요한 경우 바로 이들 체인지 벡터들이 복구해야 할 궁극적인 목표가 된다.
3. 로그 생성 방식
* 논리적 로그 생성 : 변경을 발생시키는 명령문과 변경 사항을 롤백시킬 수 있는 명령문만을 저장한다. 변경된 블록의 주소 값 정보가 없기 때문에 롤백 시간이 길어지는 경우가 발생할 수 있다. 예를 들어 여러 블록에 insert 문장을 수행하던 중 트랜잭션이 비정상적으로 종료되는 상황이 발생하게 되면 어느 블록은 변경이 되고 어느 블록은 변경이 미처 되지 않았는지에 대한 정보를 파악할 길이 없기 때문에 전체 insert 문장을 수행하고 모든 insert 문장에 대한 수행하는 과정을 거치게 된다.
* 물리적 로그 생성 : 변경되기 전의 블록의 전체 이미지와 변경 후의 블록의 전체 이미지를 모두 리두 로그에 기록하기 때문에 리두 로그 용량이 무척 커질 수도 있게 된다.
* 논리적/물리적 로그 생성 : 논리적 로그 정보를 포함하고 추가적으로 변경 후 값과 변경이 발새한 블록의 주소 값 그리고 변경 전 값을 저장하고 있는 언두 블록의 주소 값을 함께 저장한다. 저장 용량이 비교적 작으면서도 빠른 롤백을 보장하는 방식이다.
4. 선 로그 기법 개념(Write log ahead)
- DML 수행 시 데이터를 변경하기 앞서 리두 로그를 생성한다. DBWR가 더티 버퍼를 디스크에 기록하기 전에 LGWR가 먼저 호출되어 리두 로그 버퍼의 정보를 리두 로그 파일에 기록한다. 이러한 선 로그 기법의 적용으로 DML 수행 중 장애가 발생하는 경우 데이터 복구가 가능하다.
* 페이지 고정 규칙 개념 : 데이터 정합성 보장을 위하여 변경 전 데이터를 가지고 있는 블록(데이터 버퍼 캐시에 저장된)이미지는 리두 로그 생성 시작 시부터 데이터 변경 완료 시점까지 변경되지 않는다는 내부 관리 방식이다.
* 논리적 리두 로그 정렬 개념 : 리두 로그가 생성된 순서에 따라 순차적으로 리두 로그 버퍼에 기록된다는 의미이다. 리두 로그의 생성 순서는 SCN 번호로 정해지며 그 순서 그대로 리두 로그 버퍼에 기록된다.
* 커밋 시 리두 로그 저장 개념(Log force at commit) : 커밋 수행 시 커밋 리두 레코드를 생성한 후 LGWR를 통해 리두 로그 버퍼에 기록된 리두 레코드를 리두 로그 파일에 물리적으로 기록하는 것을 의미한다.
* 리두 로그 생성 절차
1. 데이터 버퍼 캐시 내에서 변경되는 데이터/데이터 블록 관련 트랜잭션 정보 발생, DML 문장이 시작되면 해당 로우가 저장된 데이터 버퍼를 아무도 동시에 변경할 수 없도록 해당 데이터 블록/버퍼를 Pin 모드로 전환시키고 다음을 진행한다.
2. 모든 변경 관련 정보들에 대한 체인지 벡터를 PGA 내부에 기록한다.
3. 체인지 벡터를 리두 로그 버퍼에 기록하기 위해 필요한 Redo copy latch를 획득한다.
4. 리두 로그 버퍼에 공간 할당을 받기 위한 Redo allocation latch를 획득한다.
5. 리두 로그 버퍼 공간이 있다면 Redo allocation latch를 반환하고 리두 로그 버퍼의 프리 공간에 체인지 벡터를 기록한다.
6. 기록이 완료되면 Redo copy latch를 반환한다.
7. 리두 로그 버퍼에 체인지 벡터 기록되고 나면 이미 Pin 상태로 만들어둔 데이터 버퍼 블록에 실제적인 데이터 변경을 수행하게 된다. 리두 로그 버퍼의 여유 공간 확보 실패 시에는 Redo copy latch, Redo allocation latch를 일단 반환하고 Redo write latch 획득 후 LGWR을 호출한다.
8. 호출을 받은 LGWR는 리두 로그 버퍼의 변경된 리두 데이터들을 리두 로그 파일에 기록함으로서 리두 로그 버퍼 내부의 여유 공간을 확보한다.
9. 일단 리두 로그 버퍼 내부의 여유 공간이 확보되면 오라클 서버 프로세스는 다시 3번부터 작업을 진행한다.
'Operating System > ORACLE' 카테고리의 다른 글
Windows 10에 Oracle 12c 클라이언트 설치 (0) | 2023.02.16 |
---|---|
[ORACLE] Directory 디렉토리 생성, 삭제, 변경 (0) | 2022.06.08 |
[ORACLE] LRU 알고리즘 (0) | 2022.05.30 |
[ORACLE] 데이터 사전 ( Data Dictionary ) (1) | 2022.05.12 |
[ORACLE 11g] 리눅스에서 윈도우로 DB 백업 및 복원 (expdp,impdp)-(2) (0) | 2022.04.28 |