요즘에는 자동관리라 해당기능에 대해서 개념만 알고있으면 될듯



REDOLOG BUFFER CACHE TUNING
===========================



Purpose
-------

Redolog Buffer Cache이 어떻게 동작하는지 그리고
SGA와 관련된 tuning문제를 어떻게 파악하고 해결해야 하는지
에 대해 알아봅니다.

1. Redolog Buffer란 무엇인가 ?
2. Redolog Latches
- Redo Copy latch
- Redo allocation latch
- Redo writing latch
3. Redolog Latches 와 관련된 Instance Parameters
4. Tuning Redolog Buffer Performance
- Latch contention
- Request for space contention


Explanation
-----------


1. Redolog Buffer란 무엇인가 ?
database에 가해진 수정된 내용에 대한 정보를 가진 SGA에 존재하는
순환하는 buffer를 의미합니다.
이 정보는 redo entries에 저장됩니다.
redo entries는 database에 가해진 수정사항에 대해 redo나 reconstruct
하기위한 정보를 가지고 있습니다.
필요한 경우에 database recovery에 사용됩니다.
Oracle server processes가 user의 memory로 부터 SGA에 있는 redo log
buffer로 redo entries를 복사합니다.
redo entries는 연속적이고 순차적으로 buffer를 채웁니다.
background process LGWR가 redo log buffer 내용을 disk에 있는
active online redo log file(또는 group of files)에 write합니다.
initialization parameter인 LOG_BUFFER가 redo log buffer의 크기
(bytes)를 결정합니다.
일반적으로 transactions들이 길거나 많을 경우 LOG_BUFFER크기가 크면
log file I/O를 줄일 수 있습니다.
host operating system의 maximum data block크기의 4배가 default값
이 됩니다.


2. Redolog Latches

data block에 수정할 사항이 있는경우 다음처럼 redo log buffer에
redo record를 만들어야 합니다.
- 다른 processes들이 더 높으 SCN을 만들지 않는지 확인합니다.
- redo record를 쓸 공간을 찾습니다.
만일 공간이 없는 경우 LGWR가 disk에 write를 하던지 아니면 log
switch를 발생시킵니다.
- redo log buffer에 필요한 공간을 할당합니다.
- redo record를 log buffer에 복사하고 recovery를 목적으로 하는
적당한 구조에 link합니다.

이 과정을 조정하기위해 3가지 redo latches가 있습니다.
- Redo Copy latch
위에서 기술한 전과정 동안에 획득되는 latch입니다.
free space를 만들기위해 log switch가 발생할때만 release되며,
log switch가 끝나면 다시 획득됩니다.
-Redo allocation latch
redo allocation latch는 SGA의 log buffer cache에 entries를 writing
하는 것을 일렬화 합니다.
redo allocation latch는 각각의 transaction entry에 대해 log buffer
cache에 공간을 할당합니다.
transaction이 작거나 server에 단 한개의 CPU만 있는 경우
redo allocation latch는 transaction data를 log buffer cache에 복사
합니다. 만일 free space를 확보하기 위해 log switch가 필요한 경우에
이 latch는 redo copy latch와 함께 release됩니다.
-Redo writing latch
이 latch는 여러 processes들이 동시에 LGWR에게 log switch를 요청하는
것을 방지합니다.
process는 LGWR에 write나 log switch를 일으키거나 또는 그냥 대기하
는 것을 요청하기 전에 이 latch를 획득해야 합니다.


3. Redolog Latches 와 관련된 Instance Parameters

redo log buffer에서 latch할당을 수정할 수 있는 parameters로
LOG_SIMULTANEOUS_COPIES와 LOG_SMALL_ENTRY_MAX_SIZE가 있습니다.
LOG_SIMULTANEOUS_COPIES는 한개 이상의 CPU를 사용하는 경우
redo copy latches의 수를 조정합니다.
Oracle7 과 Oracle8에서 LOG_SIMULTANEOUS_COPIES가 0이 아닌 값으로
설정되고 transaction entry가 LOG_SMALL_ENTRY_MAX_SIZE의 값보다
작은 경우 redo allocation latch에 의해 transaction entry이
log buffer cache로 복사됩니다.
transaction entry가 LOG_SMALL_ENTRY_MAX_SIZE의 값보다 큰 경우
redo copy latch에 의해 transaction entry이 log buffer cache로
복사됩니다.
Oracle8i에서는 redo size에 상관없이 redo copy latch는 항상 획득되기
때문에 check할 필요가 없습니다.
LOG_SMALL_ENTRY_MAX_SIZE parameter는 더이상 사용되지 않습니다.


4. Redolog Buffer 성능 문제 파악 및 해결

모든 DML이나 DDL 명령은 실행되기 전에 반드시 entry를 기록해야
하기때문에 redolog buffer에서 일어나는 contention은
database성능에 영향을 줍니다.
contention은 latch contention으로 보일때도 있고 log buffer에
과도하게 free space를 요구하는 것으로 보일때도 있습니다.
database는 위 두가지 경우의 contention을 다음과 같은 방법으로
보여 줍니다.

-Latch contention
다음 query는 redolog latches에 대한 miss ratio와 "immediate"
miss ratio를 보여 줍니다.

SELECT substr(ln.name, 1, 20), gets, misses, immediate_gets,
immediate_misses
FROM v$latch l, v$latchname ln
WHERE ln.name in ('redo allocation', 'redo copy')
and ln.latch# = l.latch#;

만일 GETS에 대한 MISSES의 비율이 1%를 넘거나
(IMMEDIATE_GETS + IMMEDIATE_MISSES)에 대한 IMMEDIATE_MISSES의
비율이 1%가 넘으면 latch contention이 있다는 의미입니다.

주의: Oracle에서는 redo copy latch에 대한 tuning보다 먼저
redo allocation latch를 tuning하기를 권장합니다.

Oracle7 과 Oracle8 에서
redo allocation latch에 의해서 발생된 contention이라면
LOG_SMALL_ENTRY_MAX_SIZE 값을 줄여주셔야 합니다.
권장되는 값은 V$SYSSTAT으로 부터 (redo size/redo entries)로 계산될
수 있는 평준 redo size 값입니다.

redo copy latch contention이 발견될 경우에는 LOG_SIMULTANEOUS_COPIES
값을 늘려 주어 더 많은 수의 latches가 사용가능 하도록 만들어 주실 수
있습니다. 권장되는 값은 CPU수의 두배 입니다.

Oracle8i에서
redo allocation latch에 의해 contention이 발생하는 경우 어떤 작업의
경우에는 NOLOGGING option을 사용해서 redo log entries의 양을 줄일 수
있습니다.
또는 LOG_BUFFER 값을 늘려서 latch에 대한 부하를 줄일 수 있습니다.

copy latch contention가 발견된다면 LOGSIMULTANEOUS_COPIES를 늘려서
사용가능한 latches수를 늘릴 수 있습니다.
기본값은 CPU수의 두배 입니다.

- space contention 에 대한 요청
"redo log space requests" 통계정보는 user process가 redo log buffer에서
space를 기다린 회수를 의미합니다.
이 값은 V$SYSSTAT를 조회하면 알 수 있습니다.
기본적으로 이 table은 SYS user와 SELECT ANY TABLE이라는 system권한을
부여 받은 user들(예를들어 SYSTEM user)만이 볼 수 있습니다.
application이 동작하는 동안 그 통계정보를 다음 query를 가지고 일정시간
동안 monitoring해 보시기 바랍니다.

SELECT name, value
FROM v$sysstat
WHERE name = 'redo log space requests';

"redo log space requests"값은 0에 가까워야합니다.
만일 이 값이 계속해서 증가될 경우 processes들은 buffer의 space를
얻기위해 기다려야만 합니다.
이러한 현상은 log buffer가 너무 적거나 아니면 checkpointing이나
log switching에 의해서 발생할 수 있습니다.
필요한 경우 initialization parameter인 LOG_BUFFER의 값을 바꾸어서
redo log buffer크기를 증가 시킬 수 있습니다.
이 parameter의 값은 bytes로 표시되면 DB_BLOCK_SIZE의 배수이어야
합니다. 다른 방법으로 checkpointing이나 archiving 작업을 향상
시킬 수도 있습니다.





Reference Documment
---------------------
Note.147471.1