About DATABASE

REDO log buffer는 SGA내에 존재하며 데이타베이스에 대한 변경에 관한 정보를 보관 유지하는 버퍼입니다. 이 정보는 REDO 엔트리에 격납됩니다. REDO 엔트리는 데이타베이스에 대해서 행해진 변경을 재실행하기 위해서 필요한 정보를 포함하고 있습니다. 필요에 따라서 개개의 REDO 엔트리는 데이타베이스의 복구에 사용됩니다.

REDO엔트리는 Oracle 서버 프로세스에 의해 유저의 메모리 영역으로부터 SGA에 있어서의 REDO log buffer에 카피됩니다. 이 때 REDO 로그 엔트리는 버퍼내의 영역에 차례로 써집니다. 백그라운드 프로세스의 LGWR는, REDO log buffer의 내용을 디스크상의 액티브한 온라인 REDO 로그 파일 (온라인 REDO 로그 파일 그룹)에 씁니다.

초기화 파라미터 LOG_BUFFER는 REDO log buffer의 사이즈를 바이트 단위로 지정한 것입니다. 1개의 트랜잭션(transaction), 혹은 다중의 트랜잭션(transaction)에서 대량의 REDO log buffer에의 기입이 발생하는 환경에서는 일반적으로는 이 값을 크게 해 로그 파일에 대한 I/O수를 줄일 수가 있습니다. LOG_BUFFER 사이즈의 설정에 관해서는 KROWN#18227을 확인해 주세요.

데이터 블록에 대한 변경이 필요할 때 이하의 순서에 의해 REDO log buffer내에 REDO 레코드가 작성됩니다.

다른 프로세스가 해당 프로세스보다 높은 COMMIT SCN(System Change Number)를 생성하고 있지 않는 것을 확인한다.

■ REDO를 쓸 수 있는 스페이스가 있는지를 확인한다. 충분한 스페이스가 없는 경우는 LGWR가

   REDO log buffer의 내용을 디스크상의 REDO 로그 파일에 쓰거나 로그 스윗치를 실시한다.
■ REDO log buffer내에 필요한 스페이스를 할당한다.
■ REDO log buffer에 REDO 레코드를 카피하고, 리커버리 시에 사용 가능하도록 관련성 실시

데이타베이스에는 이 처리를 실행하기 위해 3개의 REDO Latch가 있습니다.

・redo copy latch

redo copy latch는 상기 순서를 실행하는 동안 보관 유지되고 있습니다. 빈 공간을작성하기 위해서 로그 스윗치가 실행되었을 때에 해방되어 로그 스윗치가 종료하면 다시 취득합니다.

・redo allocation latch

SGA내의 REDO log buffer에 대한 REDO 엔트리의 기입을 직렬화하기 위해서 사용됩니다. 트랜잭션(transaction)량이 적은 혹은 1 CPU의 서버인 경우에는 redo allocation latch는 redo copy latch를 획득하지 않고  REDO를 REDO log buffer에 씁니다.빈 스페이스를 획득하기 위해서 로그 스윗치가 필요하게 되는 경우는 이 Latch는 redo copy latch와 함께 해방됩니다. 이 Latch는 데이타베이스에 1개 밖에 없습니다.

・redo writing latch

LGWR 프로세스에 대해서 동시에 복수 프로세스에 의한 로그 스윗치의 요구가 발생하는 일을 막습니다.

빈 공간이 필요한 프로세스는 LGWR에 REDO 로그 버퍼로부터 REDO 로그 파일에의 쓰거나  혹은 로그 스윗치의 실행을 요구 하거나 단지 대기할까를 판단하기 이전에 이 latch을 취득해야 합니다. 　

REDO log buffer에 있어서의 Latch 할당의 동작에 관련하는 2개의 파라미터가 있습니다.

・LOG_SIMULTANEOUS_COPIES

  시스템이 복수CPU를 가질 때 redo copy latch의 수를 제어

・LOG_SMALL_ENTRY_MAX_SIZE

  REDO log buffer에 REDO를 쓸 때 redo allocation latch를 취득할지 아닐지를 결정하는 기준

REDO log buffer에 있어서의 경합은 모든 DML 및 DDL문은 실행전에 REDO 엔트리를 작성 할 필요가 있기 때문에 퍼포먼스상 중요합니다. 경합은 Latch 경합 혹은 REDO 로그 버퍼에 대한 빈 공간의 과도의 요구가 있는 것으로 확인할 수 있습니다. 이하에 열거한 2 종류의 경합이 발생하고 있는 일을 검출하는 것이 가능합니다.

・Latch 경합

    SELECT  substr(ln.name, 1, 20) "latch type",
                  100*(misses + immediate_misses)/(gets +
                  immediate_gets + immediate_misses) "latch utilization(%)"
       FROM v$latch l, v$latchname ln
     WHERE  ln.name in ('redo allocation', 'redo copy')
   　　 and ln.latch# = l.latch#;

이 결과 latch utilization가 1%를 넘는 경우 Latch 경합이 발생하고 있다란것을 의미합니다. redo copy latch의 전에 redo allocation latch의 튜닝을 실시하는 일을 추천합니다.redo allocation latch는 인스턴스에 1개 밖에 없기 때문에 redo allocation latch의 경합은 퍼포먼스상 영향도가 높기 때문입니다.

Oracle7,8i에서는 redo alocation latch의 경합이 발생하는 경우 LOG_SMALL_ENTRY_MAX_SIZE의 값을 낮추고 redo copy latch가 획득되기 쉽게 조정하는 것이 좋다. 추천치는 평균의 REDO 사이즈이며 이하의 SQL의 결과의 'redo size'를 'redo entries'의 값으로 나눈 값이 됩니다.

    SELECT value
       FROM v$sysstat
    WHERE name in ('redo size','redo entries');

다만 이 SQL를 실행할 때는 실전 환경과 같은 조건이 아니면 적절한 결과를 얻을수 없습니다. redo copy latch 경합이 발생하고 있는 경우는 LOG_SIMULTANEOUS_COPIES 파라미터를 증가시키는 것으로 새로운 redo copy latch를 추가시킬 수가 있습니다.이 파라미터의 추천치는 CPU수*2 가 됩니다.

Oracle8i에서는 redo allocation latch 경합이 발생하고 있는 경우, 특정의 처리에 대해서는  NOLOGGING 옵션을 사용하면 생성되는 REDO를 감소시킬수  있습니다

혹은 LOG_BUFFER 파라미터를 증가시키는 것으로 latch의 부하를 낮추는 것이 가능합니다. LOG_BUFFER 파라미터의 튜닝에 관해서는 KROWN#18227 로 소개있습니다.redo copy latch 경합이 발생하고 있는 경우 Oracle8 이전과 같이 LOG_SIMULTANEOUS_COPIES를 증가 시킨다.

・영역 할당의 리퀘스트의 경합

REDO log buffer의 영역 할당을 대기한 회수는 "redo buffer allocation retries"라는 통계로 카운트 됩니다. 다음의 SQL를 사용하고, 어플리케이션이 동작중의 통계치를 감시해야 합니다. 

    SELECT name,valus
　    FROM v$sysstat
　　WHERE name = 'redo buffer allocation retries';

"redo buffer allocation retries"의 값은 0인 것이 이상적입니다.
이 값이 증가 경향에 있는 경우에는 LOG_BUFFER 파라미터의 값이 너무 작을 가능성이 있습니다.
LOG_BUFFER의 튜닝 방법에 대해서는 Krown:18227을 참조하십시오.