Latch: redo allocation

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[편집] Basic Info

체인지 벡터를 리두 버퍼에 복사하기 위해 리두 버퍼내에 공간을 확보하고자 하는 과정에서 redo allocation 래치를 획득해야 한다. 8i까지는 전체 인스턴스에서 하나의 redo allocation 래치만이 사용가능하며 이로 인해 래치 경합에 의한 성능저하현상이 발생할 확률이 높다. 오라클 9i 부터는 전체 리두 버퍼를 복수개의 Redo strands라는 공간으로 분할해서 사용할 수 있으며, 하나의 redo allocation 래치가 하나의 redo strand를 관리한다. 복수개의 redo allocation 래치를 사용 가능하기 때문에 래치 경합을 다소 줄일 수 있다. Redo strands의 개수는 LOG_PARALLELISM이라는 파라미터에 의해 결정되며, 기본값은 1이다. 오라클 10g부터는 _LOG_PARALLELISM 라는 이름의 히든 파라미터로 변경되었다. CPU 개수가 많은(가령 16개이상) 시스템의 경우에는 redo allocation 래치와 관련된 경합이 발생할 확률이 높아지기 때문에 _LOG_PARALLELISM의 값을 크게 해서 여러 개의 redo strand와 redo allocation 래치를 사용하는 것이 좋다. 오라클은 _LOG_PARALLELISM 파라미터값을(CPU 개수 / 8)만큼 변경시킬 것을 권고한다.

오라클 10g부터는 Dynamic Parallelism이라는 새로운 기능을 도입하였다. Dynamic Parallelism 기능은 _LOG_PARALLELISM_DYNAMIC 히든 파라미터의 값을 TRUE로 지정하면 활성화되며 기본값은 TRUE이다.(실제 기본값은 마이너버전마다 다를 수 있으므로 확인해보기 바란다) 이 기능을 사용하면 동적으로 redo strands의 개수를 조정하는 것으로 보인다. "보인다"라는 표현을 쓴 이유는 아직 이 기능에 대해 공식적으로 설명된 문서가 없기 때문이다. 생성 가능한 최대 redo strands의 개수는 오라클 10g R2부터는 기본적으로 18 + _LOG_PARALLELISM_MAX 이며, 이 값만큼 redo allocation 래치를 생성한다. _LOG_PARALLELISM_MAX의 기본값은 2이며 CPU 개수를 초과할 수 없다. 하지만 생성된 래치들이 항상 다 사용되는 것은 아니며 오라클에 의해서 동적으로 사용된다. 오라클 9i에서 사용 가능한 redo allocation 래치의 수로 CPU개수 / 8을 권장하는 것에 비하면 사용가능한 redo allocation 래치의 수가 크게 늘어났다는 사실 또한 주목할 만하다.

아래 테스트는 CPU 개수가 4인 시스템에서 동시에 10개의 세션에서 리두 데이터를 생성한 후 redo allocation 래치의 활동성을 조회한 결과이다.

SQL> select name, gets, misses, immediate_gets, immediate_misses
from v$latch_children
where name = 'redo allocation';

NAME                  GETS     MISSES IMMEDIATE_GETS IMMEDIATE_MISSES
--------------- ---------- ---------- -------------- ----------------
redo allocation       1264         1           7368             6
redo allocation        889          0            533              0
redo allocation        134          0             0                0
redo allocation         72          0              0                0
redo allocation         10          0              0                0
redo allocation         12          0              0                0
redo allocation         12          0              0                0
redo allocation        882         0              0                0
redo allocation        198         0              0                0
redo allocation          6          0              0                0
redo allocation          6          0              0                0
redo allocation          6          0              0                0
redo allocation        117         0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0
redo allocation          5          0              0                0

redo allocation 래치를 획득하는 과정에서 경합이 발생하면 latch: redo allocation 이벤트를 대기하게 된다.

[편집] Parameter & Wait Time

[편집] Wait Parameters

latch free 이벤트와 동일하다.

[편집] Wait Time

latch free 이벤트와 동일하다.

[편집] Check Point & Solution

latch: redo writing#Redo 관련 경합을 참조한다.

[편집] Event Tip

[편집] private redo strands

오라클 10g부터는 private redo strands라는 기능을 도입하여 다중 strands의 개념을 더욱 확장시켰다. 일반적으로 리두 데이터를 생성하려면 체인지 벡터를 PGA에 생성한 후 필요한 래치를 확보하고 리두 버퍼에 복사하는 일련의 과정을 거쳐야 하는 반면, private redo strands를 사용하면 리두 레코드가 Shared Pool내의 private strands 영역에 생성된다. Private strands 영역은 프로세스간에 공유되지 않기 때문에 리두를 생성하는 과정에서 래치를 획득할 필요가 없으며, LGWR에 의해서 리두 로그 파일로 바로 쓰여지기 때문에 PGA에서 리두 버퍼로 복사하는 과정이 불필요하다. 이것을 "zero copy redo"라고 표현하기도 한다. 히든 파라미터인 _LOG_PRIVATE_PARALLELISM 값을 TRUE로 변경하면 이 기능이 활성화된다. 이 기능에 대해서는 아직 공식적으로 알려진 바가 없다. 또한 리두 로그를 이용하는 Logminer, Logical Standby, Streams 등과 아직 호환이 되지 않는 것으로 알려져 있다. 이 기능이 널리 사용될 경우 리두 관련 래치 경합은 더 이상 문제가 되지 않을 것으로 기대한다. V$SGASTAT 뷰를 통해 Shared Pool 내에 생성된 private strands 영역을 확인할 수 있다.

[편집] Analysis Case