제목없음

리두 로그 버퍼 내용

오라클 서버 프로세스는 리두 엔트리를 사용자의 메모리 공간으로부터 각 DML 또는 DDL 문장에 대한 리두 로그 버퍼로 복사합니다.
리두 엔트리에는 INSERT, UPDATE, DELETE, CREATE, ALTER, 또는 DROP 작업에 의해 데이터베이스에 행해지는 변경을 다시 만들거나 리두하는데 필요한 정보가 포함되어 있습니다. 이들 엔트리는 데이터베이스 복구에 사용되며, 버퍼에서 연속적인 공간을 차지합니다.

리두 엔트리와 LGWR

LGWR 프로세스는 리두 로그 버퍼를 디스크의 활동 온라인 리두 로그 파일(또는 활동 그룹의 멤버)로 기록하며, 마지막으로 기록된 이후 버퍼에 복사된 모든 리두 엔트리를 기록합니다.
리두 로그 버퍼는 순환 버퍼입니다. 따라서, 서버 프로세스는 디스크에 기록된 리두 로그 버퍼에 있는 엔트리 위에 새로운 엔트리를 복사할 수 있습니다. LGWR은 일반적으로 매우 빠르게 기록하기 때문에, 공간이 항상 새로운 엔트리에 대해 버퍼에서 이용될 수 있도록 충분히 보장할 수 있습니다.

크기

특히 트랜잭션이 길거나 많을 경우, 값이 클수록 로그 파일 I/O가 감소됩니다.
빈번한 COMMIT 문은 버퍼를 비우게 되어, 버퍼 크기가 더 작게 됩니다.

주의: LOG_BUFFER 파라미터의 값은 port-specific 값(예:UNIX 시스템에서는 512K)보다 작게 설정할 수 있으나, 더 작게 설정된 경우 port-specific 값으로 증가됩니다. 이는 각 port별 가장 최적의 값이 어떻게 될 지에 따라 플랫폼을 기반으로 변경 될 수 있습니다.

예
SQL> select ‘V$PARAMETER’ “Table name”, name, to_number(value,’9999999’) “Value”
   2  from v$parameter
   3  where name = ‘log buffer’
   4  UNION
   5  select ‘V$SGASTAT’ “Table name”, name, bytes
   6  from v$sgastat
   7  where name = ‘log_buffer’;
Table name             NAME                     VALUE
---------------------- ---------------- -------------
V$PARAMETER            log_buffer                8192
V$SGASTAT              log_buffer               65536

문제 진단
프로세서는 빠르고 디스크는 상대적으로 느린 기계에서, 프로세서는 LGWR 프로세스가 디스크로 버퍼의 일부를 이동시키는 데 걸리는 시간에 리두 로그 버퍼의 나머지를 채울 것입니다.

이러한 이유 때문에, 버퍼가 더 클 경우, 새로운 엔트리는 여전히 기록되고 있는 버퍼의 부분과 거의 충돌하지 않습니다.

서버 프로세스는 새로운 엔트리를 기록하기 위하여 리두 로그 버퍼로부터 공간을 요청하고 공간을 얻지 못할 수도 있습니다. LGWR이 버퍼를 디스크에 버리기를 기다려야 할 것입니다.

튜닝 목표

리두 로그 버퍼를 튜닝하는 것은 충분한 공간이 있어 서버 프로세스로부터의 로그 공간 요청이 만족되는 것을 보장하는 것을 의미합니다. 그러나 공간이 너무 많다면, 다른 영역에 할당될 수 있는 메모리 양이 줄어들 것입니다.

동적인 뷰

V$SESSION_WAIT뷰는 세션이 로그 버퍼에 데이터를 기록하는 것이 LGWR가 기록하는 것보다 더 빠르기 때문에 로그 버퍼의 공간을 기다린 Log Buffer Space event(로그 버퍼 공간 이벤트) 정보를 보여 줍니다.

SQL> select sid, event, seconds_in_wait, state
   2  from v$session_wait
   3  where event = ‘log buffer space%’
   SID EVENT                     SECONDS_IN_WAIT STATE
----- ------------------------- --------------- -------
     5 log buffer space                      110 WAITING

로그 버퍼 공간 이벤트의 SECONDS_IN_WAIT 값은 로그 스위치가 발생되지 않았기 때문에 리두 로그 버퍼의 공간을 기다린 시간을 보여 줍니다.
이는 LGWR가 기록하는 속도보다 버퍼가 채워지는 속도가 더 빠르다는 것을 알려 줍니다. 이것은 또한 리두 로그 파일들에 대한 경합이 있을 수도 있다는 것을 알려 줍니다.

V$SYSSTAT 뷰의 Redo Buffer Allocation Retries(로그 버퍼 할당 재시도)통계는 사용자 프로세스가 리두 로그 버퍼의 이미 디스크로 기록된 엔트리에 새로운 엔트리를 기록하기 위한 공간을 기다린 수를 보여 줍니다. 일반적으로 LGWR는 리두 로그의 접근이 과도하더라도 버퍼내에 새로운 엔트리를 기록할 수 있는 공간이 항상 있도록 충분히 빠르게 기록합니다.

SQL> SELECT name, value
   2  FROM v$sysstat
   3  WHERE name = ‘redo buffer allocation retries’;

주의: V$SYSSTAT 뷰는 Redo Log Space Request(리두 로그 공간 요청)이라는 또다른   통계를 보여 줍니다:

SQL> select name, value
   2  from v$sysstat
   3  where name = ‘redo log space requests’;

로그 버퍼 공간 이벤트의 SECONDS_IN_WAIT
V$SESSION_WAIT의 로그 버퍼 공간 이벤트의 SECONDS_IN_WAIT값은 리두 로그 버퍼 공간을 기다린 시간을 나타납니다, 다음을 고려하십시오:

만일 작다면 르그 버퍼를 크게 하십시오.
로그 파일을 스트라이프 디스크와 같은 빠른 디스크로 이동하십시오.

SQL> select sid, event, seconds_in_wait, state
   2       from v$session_wait
   3       where event = ‘log buffer space’;
    SID  EVENT                SECONDS_IN_WAIT STATE
------  ------------------ ---------------- --------
      5  log buffer space                 110 WAITING

리두 버퍼 할당 재시도(Redo Buffer Allocation Retries) 통계 비율
리두 버퍼 할당 재시도의 값은 0에 가까운 값이 되도록 해야 합니다. 리두 버퍼 할당 재시도 값이 리두 엔트리 값의 1% 보다 크지 않도록 하십시오. 만일 이 값이 지속적으로 증가한다면, 프로세스들은 버퍼 내의 공간을 기다려야만 합니다. 그것은 로그 버퍼가 너무 작거나, 체크포인트에 의해서 또는 로그 전환에 의해서 일 수 있습니다.

필요하다면 LOG_BUFFER 파라미터 값을 변경하여 리두 로그 버퍼의 크기를 증가하십시오.
또는 다른 방법으로, 체크포인트나 archiving 프로세스를 개선하십시오.

일반적으로 리두 로그 버퍼는 공유 글로벌 영역의 크기에 비해 작습니다. 약간만 증가시켜도 처리 능력을 현저하게 향상시킬 수 있습니다.

첫번째 행동
비율이 안정적일 때까지 LOG_BUFFER의 값을 증가시키십시오.
LOG_BUFFER 크기는 운영체제 락(lock) 크기의 배수이어야 합니다.

심층 조사
LGWR이 버퍼를 비우는 속도가 느린 이유를 조사하십시오.

리두 로그 파일에 디스크 I/O 경합이 있습니다. 리두 로그 파일이 별도의 빠른 장치에 저장되었는지 검사하십시오.
V$SYSTEM_EVENT에서, 로그 교체 때문에 로그 파일 교체 대기를 식별하는 “log file switch completion(로그 파일 교체 완료)” 이벤트의 발생 횟수를 검사하십시오.

SQL> select event, total_waits, time_waited, average_wait
2 from v$system_event
3 where event like ‘log file switch completion%’;

리두 로그 파일의 크기를 증가시키십시오.
LGWR이 파일을 다시 필요로 할 때, DBWR은 파일의 체크포인트 작업을 완료시키지 않기 때문에, LGWR은 기다려야 합니다.
-  alert.log 파일에서 “CHECKPOINT NOT COMPLETE” 메시지가 있나 검사하십시오.
-  V$SYSTEM_EVENT 뷰에서, 미완료 체크포인트 때문에 로그 파일 교체 대기를 식별하는 "log file switch(checkpoint incomplete)로그 파일 교체 (미완료 체크포인트)” 이벤트의 발생 횟수를 검사하십시오.

SQL> select event, total_waits, time_waited, average_wait
   2  from v$system_event
   3  where event like ‘log file switch (check%’;

-  체크포인트의 빈도를 검사하고 LOG_CHECKPOINT_INTERVAL과 LOG_CHECKPOINT_TIMEOUT 파라미터에 대해 적절한 값을 설정하십시오.
-  리두 로그 그룹의 크기와 수를 검사하십시오.
기록기(archiver)는 아카이브된 리두 로그 파일에 기록할 수 없거나 기록(archive) 작업을  충분히 빠르게 기록할 수 없습니다. 따라서, LGWR가 기록하는 것을 막습니다.
-  기록 장치가 완전히 채워지지 않았는지 확인하십시오.
-  리두 로그 그룹을 추가하십시오.
-  V$SYSTEM_EVENT 뷰에서, 기록 이슈 때문에 로그 파일 교체 대기를 식별하는 “log file switch(archiving needed)로그 파일 교체 (기록 필요)” 이벤트의 발생 횟수를 검사하십시오.

SQL> select event, total_waits, time_waited, average_wait
   2  from v$system_event
   3  where event like ‘log file switch (arch%’;

-  LOG_ARCHIVE_BUFFERS와 LOG_ARCHIVE_BUFFER_SIZE 파라미터를 설정해서 버퍼의 수를 증가시키고, 버퍼 크기를 감소시켜 기록(archiving)을 조정하십시오.
- LOG_BLOCK_CHECKSUM이 TRUE로 설정되어 있으면 성능 오버헤드가 발생합니다.

SQL *Loader와 NONLOGGING 모드
기존(conventional) 경로 로딩은 DML 문처럼 리두 로그 엔트리를 생성합니다. 그러나, 직접 경로를 사용할 때에는, 다음과 같은 경우 리두 로그 엔트리가 생성되지 않습니다:

데이터베이스가 NOARCHIVELOG 모드에 있을 경우
데이터베이스가 NOARCHIVELOG 모드에 있지만, 로깅이 비활성화되어 있을 경우 (로깅은 제어 파일에서 UNRECOVERABLE 절을 사용하거나 테이블에 대해 NOLOGGING 속성을 설정하여 비활성화시킬 수 있습니다.)

직접 로드 삽입과 NOLOGGING 모드
NOLOGGING 옵션:

테이블, 파티션, 테이블스페이스, 인덱스에 적용됩니다.
리두 로그 버퍼에 있는 데이터에 대한 변경내역을 기록하지 않습니다 (일부 최소 로깅은 익스텐트 할당과 같은 작업에 대해 여전히 수행됩니다.)
INSERT 문 레벨에서 속성으로 지정되어 있지 않지만, 테이블, 파티션, 인덱스, 또는 테이블스페이스에 대해 ALTER나 CREATE 명령어를 사용할 때 지정됩니다.
이 모드는 로드 이전에 설정되며 로드가 완료될 때 LOGGING으로 재설정됩니다 (백업이 수행되기 전에 매체 장애가 발생하면, 수정된 모든 테이블, 파티션, 인덱스는 손상될 것입니다.)

NOLOGGING 모드에서 사용될 수 있는 SQL 문
테이블, 인덱스, 또는 테이블스페이스에 대해 NOLOGGING 속성을 설정할 수 있지만, NOLOGGING 모드는 속성이 설정된 객체에 대한 모든 작업에 적용되지 않습니다.

CREATE TABLE … AS SELECT
CREATE INDEX
ALTER INDEX … REBUILD

그럼에도 불구하고 다음 문장들은 NOLOGGING 속성에 의하여 영향을 받지 않습니다: UPDATE, DELETE, 기존(conventional) 경로 INSERT, 위에 나열되지 않은 다양한 DDL 문장들.

주의: 이전 버전과의 호환성을 위해, UNRECOVERABLE는 여전히 Oracle8 서버 릴리즈 8.0에서 CREATE TABLE 문에서 대체 키워드로서 지원됩니다. 이 대체 키워드는 향후 릴리즈에서는 지원되지 않을 것입니다.

문맥

참조

초기화 파라미터

LOG_BUFFER
LOG_ARCHIVE_BUFFERS
LOG_ARCHIVE_BUFFER_SIZE
LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_TIMEOUT
LOG_BLOCK_CHECKSUM

동적인 성능 뷰

V$SYSSTAT
V$SESSION_WAIT
V$SYSTEM_EVENT

데이터 딕셔너리 뷰

None

명령어

None

패키지된 프로시저 및 함수

None

스크립트

None

진단 팩 애플리케이션

None

REDO LOG BUFFER TUNING 에 대한 설명 중 옳지 않은 것은?
A. V$SYSSTAT 의 'REDO BUFFER ALLOCATION RETRIES' / 'REDO ENTRIES'의 RATIO 를 1%이하로 관리
B. CHECKPOINT 와도 연관이 있다
C. ARCHIVELOG MODE에서는 LOG SWITCH 와 연관이 있다
D. NOARCHIVELOG MODE에서는 LOG SWITCH 와 연관이 있다
답
X 정답:D
Redo Log Buffer의 Wait정보를 살펴볼 수 있는 동적성능뷰는?
A. V$SESSION_WAIT
B. V$SYSTEM_EVENT
C. V$LOG
D. V$LOGFILE
답
O
Redo log buffer I/O contention을 확인하는 방법이 아닌 것은?
A. V$SYSSTAT view
B. Report.txt from utlbstat/utlestat (STATISTIC, PER TRANSACT, PER LOGON)
C. V$SYSTEM_EVENT(log file space/switch event에 대해 wait 여부 확인 가능)
D. d. v$sysstat를 조회한다
답
X 정답:D
Redo log의 크기를 결정하는 파라미터는?
A. LOG_BUFFER
B. SHARED_POOL_SIZE
C. REDO_LOG_BUFFER
D. DB_BLOCK_BUFFERS
답
X 정답:A

문맥	참조
초기화 파라미터	LOG_BUFFER LOG_ARCHIVE_BUFFERS LOG_ARCHIVE_BUFFER_SIZE LOG_CHECKPOINT_INTERVAL LOG_CHECKPOINT_TIMEOUT LOG_BLOCK_CHECKSUM
동적인 성능 뷰	V$SYSSTAT V$SESSION_WAIT V$SYSTEM_EVENT
데이터 딕셔너리 뷰	None
명령어	None
패키지된 프로시저 및 함수	None
스크립트	None
진단 팩 애플리케이션	None