Redo 로그 파일 크기 산정
Tibero DB Redo 로그 파일 크기 산정 방법에 대해 설명합니다.
개요
Redo 로그 파일은 최소 2개 그룹을 권장하며, Archivelog 모드인 경우 최소 3개 그룹을 권장합니다. 이는 Redo 로그가 순환할 때 rewrite 방지를 위한 hangup 현상을 막기 위함이며 최소 2개의 멤버를 권장합니다. 성능을 위해 각각 다른 물리 디스크에 배치하도록 합니다.
Redo 로그 파일의 크기를 사전에 정확하게 추측하기가 어렵기 때문에 수행하는 업무의 일부를 수행한 후 Redo 로그 양을 측정하고 전체 업무를 수행했을 때의 Redo 로그 파일의 크기를 예측하는 것을 권장합니다.
고려사항
아래는 Redo 로그 파일 크기를 산정할 때 고려할 사항입니다.
트랜잭션 처리 중 Log Switch가 발생하는 경우 트랜잭션 성능 저하가 발생합니다.
OLTP 중심의 시스템에서 트랜잭션 처리의 피크 타임에 Log Switch가 빈번하게 일어나지 않도록 Redo로그 크기의 조정이 필요합니다.
Redo 로그 파일의 크기가 크면 Log Switch 발생 가능성이 낮은 반면 Recovery 시간은 길어집니다.
위 고려 사항을 참고해서 다음의 모드 중에 하나를 선택합니다.
LOGGING / NOLOGGING 모드
테이블/인덱스에 대한 모든 변경사항은 기본적으로 Redo 로그로 기록되지만 NOLOGGING 테이블/ 인덱스에 대해 Direct-Path(DP) 방식으로 데이터를 추가하는 경우 Redo 로그를 기록하지 않습니다. DP에 대한 Redo 로그가 남지 않는 경우에 Media Recovery가 수행될 때 DP로 추가한 테이블 데이터 가 복구되지 않기 때문에 DP로 데이터를 추가한 후에는 백업을 받도록 권장합니다.
아래는 LOGGING 모드에서 하나의 DML당 로그 발생량 및 확인 방법입니다.
로그의 발생량을 DML 한 건으로 측정하기가 쉽지 않기 때문에 여러 건의 DML을 수행한 후 전체 로그 발생량을 측정해서 건수로 나누는 방법을 권장합니다.
로그 발생량은 v$sysstat 테이블의 'name' 컬럼이 'Redo log size'인 항목으로 확인 가능하며 alter system clear stat 명령으로 v$sysstat 테이블의 내용을 clear할 수 있습니다.
ARCHIVELOG / NOARCHIVELOG 모드 Redo 로그 파일은 Cache Recovery될 때 더 이상 필요없는 경우에 재사용됩니다. (일반적으로 3개의 Redo 로그 파일들을 생성해서 순차적으로 돌면서 재사용하는 구조입니다.)
ARCHIVELOG 모드 Media Recovery 를 수행해야 하는 경우 DB를 백업 받은 이후 생성된 전체 Redo 로그 파일들이 필요하며 Redo 로그파일들을재사용하기전 Media Recovery에서 사용할 목적으로 Redo 로그들을 다른곳에 복사해두는 방식입니다.
NOARCHIVELOG 모드 및 LOGGING 모드 NOARCHIVELOG 모드인 경우 Media Recovery가 지원되지 않기 때문에 LOGGING 테이블인 경우 라도 성능 개선을 목적으로 DP를 수행할 때 Redo 로그를 남기지 않습니다. ARCHIVELOG/NOARCHIVELOG 모드는 Redo 로그를 재사용하기 전 백업 수행 여부에 대한 판단이 기 때문에 LOGGING/NOLOGGING과는 개념상 큰 연관성은 없습니다.
Direct-Path Loading / Direct-Path Insert (DPL/DPI) 모드
DP로 데이터를 추가하는 경우 데이터를 row 단위로 건건이 추가하는 방식이 아니라 batch 단위로 추가 하기 때문에 성능이 빠르며 Redo 로그의 양도 row 단위로 건건이 추가할 때보다 적게 생성됩니다.
용량 산정
Redo 로그에는 사용자 데이터에 가해지는 변경사항이 저장되며 DML의 종류에 따라 아래와 같은 내용이 저장됩니다.
INSERT
INSERT 하는 ROW의 내용(TABLE row 전체 + INDEX key 전체) +
INSERT에 대한 UNDO(delete할 rowid + delete할 INDEX key)UPDATE
UPDATE 내용(ROW의 내용 중 새로 변경되는 내용 + 변경되는 컬럼의 INDEX key delete/insert)
+ UPDATE에 대한 UNDO(row 변경을 되돌리는 내용 + INDEX key delete/insert)DELETE
DELETE되는 ROW에 대한 내용(rowid 정보 + INDEX key 전체)
+ DELETE에 대한 UNDO(row 전체 + INDEX key 전체)추가로 아래와 같은 내용을 포함합니다.
트랜잭션 처리(begin/commit)를 위한 Redo 로그
Segment의 공간 관리(extent add, block format, index split)에 대한 Redo 로그
Undo 블록에 대한 변경사항
블록 내 각 ROW에서 수행했던 트랜잭션의 commit 여부를 확인하고 변경하는 Redo 로그
Redo 로그 제한 사항
구분
설명
로그 파일 최대 개수
CREATE DATABASE 절의 MAXLOGFILES 파라미터
Group당 로그 파일 최대 개수
Unlimited
최소 크기
4MB
최대 크기
Tibero 5 SP1 : 4GB
Tibero 6 이상 : 2TB
Tibero 7 : 2TB
Redo 로그 크기
Redo 로그 파일에 쓰여지는 데이터량은 SQL 및 갱신 데이터량에 의해 크게 바뀌기 때문에 운영 전 사전에 정확한 추측이 불가능합니다.
시스템의 크기에 따라서 다음과 같이 사전 설정 후 실제 운영 중 REDO 발생량을 보고 조정해야 합니다.
구분
설명
소규모 시스템
4MB~100MB
중규모 시스템
100MB~1GB
대규모 시스템
1GB 이상
Last updated